Extrapolating Security Requirements to an Established Software Process: Version 1.0 Galoh Rashidah Haron
Ng Kang Siong
Information System Security Laboratory MIMOS Berhad Kuala Lumpur, Malaysia
[email protected] Abstract — This paper presents the mechanisms on integrating security related activities to an established software process in an organization. The main challenge is to attain a security model that is fit to the organization’s security objectives and environment. We quest for an adapted security model that is lightweight yet provides an optimized security impacts in delivering software products. Implementation of the adapted security model must also comprehend the limiting factor of people resources. We share experiences and lesson learned in transforming the adapted security model into secure software process. Keywords - security requirement; software process; secure software development process
I.
INTRODUCTION
Secure software process facilitates organizations to reduce security risk in software and system. In order to meet security requirements, organizations have several security models to follow. There are Microsoft’s Security Development Lifecycle (SDL), OWASP’s Comprehensive, Lightweight Application Security Process (CLASP) and Fortify’s Building Security in Maturity Model (BSIMM) [1]. The common philosophy of these security models is to integrate specific security activities in each phase of software life cycle and enable the construction of secure software. This paper describes a case of an organization, which has already achieved significant maturity level in the software development process [2] and required to merge the security specific activities with the existing software development process. The challenge is to identify a security model that is customized to the organization and aligned to the organization’s security objectives and risks prioritization. It was reported that the SDL is more suitable for large and policy oriented organization and CLASP is for small organizations with less security demand [7]. For BSIMM, it is practiced by varied size of organizations [8]. These formal security models have its own excels. The preferred security model shall be based on combining strong features prevailed by these security models. The organization has set the security objective as to assure security for software products. The objective received a full support from management. The organization has also set a
Information System Security Laboratory MIMOS Berhad Kuala Lumpur, Malaysia
[email protected] priority in accommodating security in web based application context. The ideal security model shall include processes to minimize security vulnerabilities and risks in the software. It must be capable in balancing security assurance and software on time delivery factors. It must also consider the limitation of people factor. The organization has limited security personnel and resources to drive force the security process. In a way, it must able to delegate the security responsibilities to every team members who involved in the software project. Thus, the organization’s vision is to have a lightweight secure software process that is able to optimize security for all software releases. The mission is to develop awareness that security is everyone’s responsibility. The approaches to set a new security process include the following: 1. 2. 3. 4.
define a suitable security model, adapt it to align with organization objectives and environment extrapolate the security requirements based on top web application risk and vulnerabilities define security related activities in an established software process extend security sense and awareness to all team members
The above discussion is organized as follows. Section II will describe the challenges in developing the security process. Section III will discuss on extrapolation of security requirements based on common web attack. Section IV will define the security activities and its flows dictates by each software phase. This section will also outline the distribution of security activities in the team members. Finally, we share the lesson learned based on several successful security-filtered software projects and the ideas to move forward. II. THE CHALLENGES Introducing a new security process into an established software process creates internal debates. The first challenge is to mitigate the impact of the overall software development in terms of performance and software time delivery. Every team member sees secure software process is a step forward. However, there is a request that it should be used as a guide or recommendation process flow rather than a compulsory process to meet the security requirements. The worry is that,
these additional security efforts will have an impact to the current software process. Rather than the normal circle of communication, software leader, developers, testers, quality and system administrator, it introduces a new role, a security domain expertise personnel. The team will have difficulties in digesting security knowledge in a short term. It requires times and trainings to built such team. To minimize the impact, the security process implementation is required to be introduced in phases. In sampling the security process, the deployment phase is the first phase being prototyped as secure software process. The idea is to engage the software team members and system administrator, to understand the process of deploying software and system in a secure manner. Next, we target the security requirement and test phase. Later, we embark security in the design and code phase, where developer’s skills to instill secure codes in the software is focused. When all the phases are intact with realistic security activities, only then security process is made compulsory. There is a request that the security expertise personnel play a bigger role than merely a security advisor for a project. For example, they are should provide guidelines on how to secure the application inside out. Practically, they are required to provide direct, hands-on security skills to the project. For example, configure servers with security controls, handle hash and encryption for several different application frameworks. This idea is best suited to the organization that has a high number of resources in security. In our case, the security group resource is limited. The work around is to instill the security ownership as everyone’s responsibility in the teams. There is another request the security process shall only be applied to specific software projects. The determining factor is based on customer; meaning if customer preferred functional and performance over security features, than the specific software project shall not be committed to secure software process. However, we stand on a principle that all software risk should be notified and understood by all stakeholders. Thus, all web projects must not evade the security process and several expected documentation concentrates on security risk analysis should be created. III.
THE SECURITY REQUIREMENTS
To execute the security process, we create a standard security requirements document that act as a security reference point for all team members. The documentation covered ten key areas, design to protect web application software project. This is adapted from BSIMM and CLASP, where creating an accessible security standard as a foundational knowledge for everyone is recommended [8] and it shall acts as a baseline for security requirements if software projects [7]. The key areas are built based on the most common and critical web application security risk driven from Microsoft [4] and Open Web Application Security Project (OWASP) [3]. Each of the key area is initialized with SR, indicates Security Requirement. The key areas are explained as follows:
A. Authentication “SR1: Shall the application and system involve in authentication, it will specify the authentication mechanism in the design document and implement it accordingly. It should provide strong authentication mechanism(s) and uniquely identify individual users. Adoption of Unified Authentication Platform, an internal proprietary technology as authentication component is recommended.” The first security requirement is about authentication, a process of user identification in a web system. Improvising security on authentication will eliminate vulnerabilities such as transmitting user name and password in plaintext and cookie replay attack [4]. The security requirement has no preference as to which authentication mechanism should be used but recommends on adopting internal authentication technology per software project basis. B. Authorization “SR2: Shall the application and system involve in authorization, it will specify the authorization mechanism in the design document and implement accordingly.” Authorization is a process of granting user to access the web system. Similar to the SR1, the authorization mechanism is required to be stated in the design document. The software lab team has a full control in designing a suitable authorization mechanism. The security requirement has no preference as to which authorization mechanism should be used. It can be either simple or complex depending on the requirements of the project, as long as it is documented. C. Data Input Validation “SR3: Shall the application and system require data input from user or another system, input validation shall be done on the server side.” The purpose of strengthening data input validation is to combat attack such as buffer overflow, cross-site scripting and SQL injection through application and system input. Data input validation is a process to check the true value and integrity of data, which are the inputs to the system. Awareness of such requirement will eliminate 2 out of 10, the top application security risks [3]. To minimize data input validation vulnerabilities can be seen as a huge effort. It is highly dependent to the software language or framework used, in building the web application. The validation methods vary as well [5]. However, at this level, it is expected ‘data length’, ‘data check type’ and ‘allowed character checks’ validation methods are covered. D. Database Security “SR4: Shall the application and system involve in database service, it will adhere to rules of securely manage the database” The above requirement demands a good practice in coding and deploying secure database from software lab team. Among the expected activities are to partition data store as public which is read mode only and private allows to read and write mode and to apply hash mechanism in storing the password.
E. Classification Information “SR5: Shall the application and system involve in classified information storage and exchange as per defined by the customer, it shall adhere to the process of information classification and ensure information privacy and integrity by cryptographic means.” This requirement is about how to handle sensitive data in storage. In case where cryptographic method is preferred, security personnel will be responsible in detecting any poor key generation or weak custom encryption algorithm applied in the system. The requirement set no preference in which cryptology technology for any system, but recommends adoption of internal hard disk encryption technology whenever possible. F. Log “SR6: Shall the application and system involve in network environment, it will specify activities to be captured in logs.” Logging activity is a known requirement in the current software process. In the current software process, software lab teams document the software features as its requirements. Now, they are required to extend the coverage of the requirement to security features. In security, the purpose of logging is to trace any suspicious activities. In the security process, logging to have at least information on log level, consistency in log formulation, defines access privileges to log and log roll-back mechanism. It is up to the developer to specify what information is to be logged in the design document. However, it is recommended that log is performed at the critical function of the application, without risking the system’s performance. G. Open/Close of Port “SR7: Shall the application and system involve in network environment, it will ensure only required ports and network services are opened, otherwise is should be closed and the corresponding all unnecessary applications or background services shall be disabled.” The good rule of thumb to implement such requirement is to close all ports and open only dedicated port required to run application system. H. Third Party Scanning “SR8: Shall the application and system required to be as a release product, it shall go through vulnerabilities scanning by in house or third party application and eliminated all the major and severity prior to release the package system accordingly.” This requirement will elevate the risk where all web applications developed by the organization is subjected to such test. I. Eliminating threat “SR9: All the following threats shall be mandatorily mitigated by the web application. These threats are classified by Web Application Security Consortium (WASC). http://www.webappsec.org/” This requirement is for software lab team, tester and security to improvise their effort to strengthen the system and
update to the current trends of threats. The WASC reference is vital not only due to abundance of security knowledge, but to improve communication, as everyone will be using common security language in combating the threats. J. Administrative account “SR10: Design document shall document roles and privileges assigned to application administrative accounts. Role separation between administrative accounts and user accounts shall be documented and implemented accordingly.” The requirement objective is to ensure limited access to administration procedures and avoid unnecessary elevation of privilege. The distinctive operations between administrative, user, its roles and privileges required to be documented in the design document. For security personnel the main question to ask is how does the system will react when administrator and user is the same person. IV.
THE CHANGES
Figure 1 emphasizes on the security add on process required to support the new secure software process. The people resources involved are software manager and developers (lab team), security personnel and testers. One security personnel will be involved for one software project from the project kickoff till the end. This is adapted from SDL’s features where it maps security activities directly to standard software development process [7]. The following are the descriptions of the changes made in each phase of software life cycle: A. Requirement Phase In the current software process, the sources of the software requirements are elicited based on the inputs either from software teams or stakeholders. Then, these security requirements which considered as critical determinants in software quality, will be evaluated by all team members, documented and reviewed. For secure software process, the task and activities are following the identical requirement flow, except teams are urged to add on security value in the current software process as its software requirements. In order to guide teams to form security as part of software requirements, we have created a template of Security Requirement document. The content of the document is discussed in section III. A new role, security personnel is created to review and analyze the security requirements for the project. B. Design Phase Based on the elicited software requirements, design phase will ensure the generated code is as per design requirements. The security personnel is responsible to review the security design document with all teams. Security Design Template document act as a reference or guide for all the teams in order to provide security information in detailed. For example, if the software project involved in authentication for its requirement, in the design documentation we required the module diagram and properties of authentication system.
Figure 1: A High-Level Overview of Secure Software Process - Copyright © 2011 MIMOS Berhad C. Code Phase In coding phase, developers will develop the software based on these security requirements and design documents. The tester will test the software based on these security requirements. There is no new formal activities introduces in coding phase. At this phase, developers are recommended to build security inside codes. A peer security code review is recommended at this stage. We believe developers whose codes with security reflects the overall maturity of the adopted security model. Software testers required to design test cases that deal with security issues. We have dedicated testers on performing security test. They are partly responsible in determining if the security requirements are met and detect if any security risk or vulnerabilities exist in the system. They are assisted with software tools to detect security vulnerabilities, i.e. IBM AppScan tool. As feedback of security test given to the developers, they need to prioritize on the removal of the vulnerabilities. They need to eliminate all critical and major vulnerabilities. The focuses are to secure code and to manage error handling and exception. This phase is the pinnacle of the secure software process and the most challenging activities in security process, in terms of cost, people resources, effort and time required to fulfill this security requirement. D. Test Phase In the test phase, the security and functions testers execute the test cases. As this stage all the test cases are drawn up based on security requirement and design documents. No new security flow being introduced at this phase. Any software bugs found, the lab team will be responsible to fix it. This process is a continuous until the software is ready to be released. It is expected that any application dependent vulnerabilities would have been screen off at this stage before the software release.
E. Deployment Phase The increase of web server attacks in government sector leads towards the quest of who is the owner of the server, how the password being manage, what port and web services being opened to the internet, any HTTPS connection applied and so on. All these basic securities related information required to be documented in case of any security breach occurred. Therefore, this security related information is expected to be documented before any software release. The expected artifact is System Deployment Security Risk Analysis document. The document will provide information of logical and physical network diagram, application features including deployment configuration. Security personnel is required to analyze the risk based on architecture diagram and any related software documentation for the dedicated software project and expected to make a report based on security findings. All team member need to fill in the Security Risk Analysis document. V.
PEOPLE RESOURCES
Table 1 describes the distribution of the secure software process activities among people resources in the organization. This is suggested from SDL, where it emphasizes on relation of team’s roles and interactions into security process [7]. Software lab team will create artifacts of secure requirement and design specification documentation. Tester team will generate the secure test cases documentation. The new artifact that is produced by the secure software process is security risk analysis document. It requires input from the software lab team to update the logical and deployment diagram. Another section for security personnel defines the overall risk for the system and for system administrator to update the deployment configuration.
Table 1: Distribution of security activities for team members SOFTWARE LAB TEAM TESTER SECURITY SR1
• decide the authentication mechanism for the system • document the authentication properties and methods
• perform authentication test • document the test result
SR2
• decide the authorization mechanism for the system • document the authorization properties and methods
• perform authorization test • document the test result
SR3
• determine which modules or functions required data input validation. • provide functions to validate the data input • document the data input validation • develop secure database design • update database design description to the design document.
• perform security test on data input validation via black box testing. • document the test cases of data input validation
SR4
SR5
SR6
• evaluate and analyse the risk of the authentication • verify the authentication information is updated in the design documentation • document the risk findings • evaluate and analyse the risk of the authorization • verify the authorization information is updated in the design documentation • document the risk findings • audit and validate the requirement, design and testing document.
• evaluate the secure database design • identify any required confidential data • validate any implementation of access control for the data • evaluate the intended data classification
• determine data that required classification • document the description on handling data classification • implement log mechanism on the critical security flows
• identify critical application to have log for audit trail mechanism.
SR7
• inform port required for the dedicated services
• validate the open port is the required port to run the system
SR8
• update relevant security risk document before security scanning is performed • update the logical design and the deployment diagram of the system • improve coding to eliminate the treats
• validate the security risk information is updated • perform automatic scanning to the system • document the result of scanning
SR9 SR10
ADMINISTRATOR
• improve testing to eliminate the treats
• close all port and open only necessary port • document port information • verify the security risk information is updated
• document the effort made to eliminate the treats • validate administrator information in the security risk documentation
• document the administrator password information
VI.
LESSON LEARNED
The new security process has been modeled to several software projects. These are few observations and improvements made towards optimizing the secure process. A. Nope, I did not open that port. In SR7, it suggested that the administrator or software lab team should identify which port numbers required in the system. However, in the midst of secure scanning process, we encountered cases of poor ports management such as unnecessary ports are opened and necessary port is closed. Some of these cases appeared to be intermittent in behavior as per scan cycle goes. These cases are frequently occurred in the software project that grows in complexity or highly dependent to the third party software. In order to solve this issue, we add additional rule that all ports are required to be closed unless it is being specified to be opened in the Security Risk Analysis document. B. Again, how to draw the deployment architecture diagram? To security personnel, the deployment architecture diagram is the first assistant tool in depicting any security vulnerabilities, exist in a system. Throughout the implementation of secure software process in multiple projects, there are cases such as: incomplete deployment diagram i.e. missing connection information, missing modules and inconsistent deployment diagram information as per requirement document. As this issue arises, we add guidelines in the Security Risk Analysis documentation on what is the basic information expected in the deployment architecture diagram. There are list of modules integrated, connection between the modules and port number. C. Too dependent on automated scanning application. Generally, in security world we agree the best method of web security testing is to apply both methods between automated scanning testing and manual penetration testing. However, due to limited security resources in terms of people numbers and skills, the software security process adopt automated scanning using Acunetix and Nessus applications. The best approach is that the automated scanning test is in parallel with the manual penetration test. D. Low absoprtion of secure code At the current moment, the tendency of practicing secure codes is low. It would seem as the practice is more towards the willingness of the developers to indulge with secure codes practice. The best is for the developer to bullet proof the codes before performing any software security test. At the moment the change in secure code culture evoke in a reverse way; it is based on the feedback from the automatic scanning tool at the testing phase, counted as a software bug, only than the secure code is developed. Based on the discussion among developers, they are all aware of the secure codes practice. But somehow the motivation to code for software features is outweighing the security, which is considered as rigid in a way. The complaints include the readiness of the programming language framework. For example, secure code should be automatically suggested to
developer as such less expert developer can quickly adopt the secure code. We believe more efforts from the developers will increase the maturity level in security process. In case where developer put effort in secure code; i.e. uses static analyzer code tool, design and develop the software via threat model, creates security unit test, it shall elevate the security process to a next level. VII. CONCLUSION Software security process demands coexistence of effort from all team members. Security models, theories and best practices are widespread information. The challenge is to extort this information and develop a new security process that is aligned to the security objective of the organization and have a balance between security activities to the people resources in the organization. We construct ten key areas to support the security process as the organization standard security requirements. It will guide team members in integrating security to their software project and most importantly it evolves a sense of security awareness in every team members. We highlight the security activities and roles of the team members in each of the phase in software lifecycle. We manage to run the secure software process on several software projects and avoiding an ad hoc process. Then, we share the lesson learned and the disputes occurred in transforming the teams to the security process. At this moment, this security process is adequate model for our organization. With maturity of all team members in security knowledge and skills, we will be ready to move forward, to the next level of secure software process where it will be heavily focused on analyse source code, peer code reviews and manual penetration testing. ACKNOWLEDGMENT We acknowledge with gratitude to the top management for granting security as a fundamental requisite for each of software product release. The assembly of aforementioned security process is a collaboration effort from Software Process Group and Information Security System Laboratory. REFERENCES [1] [2] [3] [4] [5] [6] [7]
[8]
Geer, David; , "Are Companies Actually Using Secure Development Life Cycles?," Computer , vol.43, no.6, pp.12-16, June 2010 Published Appraisal Results. Available: http://sas.sei.cmu.edu/pars/pars_detail.aspx?a=13276, August 2011 Top 10 2010-Main – OWASP. Available: https://www.owasp.org/index.php/Top_10_2010-Main, May 2011 Microsoft Corporation, “Improving Web Application Security: Threats and Countermeasures”, August 2003. Data validation Wikipedia, the free encyclopedia, http://en.wikipedia.org/wiki/Data_validation, August 2011 WASC Threat Classification, Web Application Security Consortium. Available: http://projects.webappsec.org/f/WASC-TC-v2_0.pdf, August 2010 Gregoire, J.; Buyens, K.; De Win, B.; Scandariato, R.; Joosen, W.; , "On the Secure Software Development Process: CLASP and SDL Compared," Software Engineering for Secure Systems, 2007. SESS '07: ICSE Workshops 2007. Third International Workshop on , vol., no., pp.1, 20-26 May 2007 Chess, B.; Arkin, B.; , "Software Security in Practice," Security & Privacy, IEEE , vol.9, no.2, pp.89-92, March-April 2011
