Linköpings universitet
Linköping University | Department of Computer and Information Science
Master’s thesis, 30 ECTS | Computer Science
2019 | LIU-IDA/LITH-EX-A--19/047--SE
A Lightweight Secure
Develop-ment Process for Developers
En resurseffektiv säkerhetsprocess för utvecklare
Jesper Hellström
Anton Moberg
Supervisor : Suejb Memeti Examiner : Ola Leifler
Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer-ingsdatum under förutsättning att inga extraordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Över-föring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och till-gängligheten finns lösningar av teknisk och administrativ art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet än-dras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.
The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.
For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
Abstract
Following a secure development process when developing software can greatly increase the security of the software. Several secure development processes have been developed and are available for companies and organizations to adopt. However, the processes can be expensive and complex to adopt in terms of expertise, education, time, and other resources. In this thesis, a software service, developed by a small IT-consulting company, was tested with security tools and manual code review to find security vulnerabilities. These vulner-abilities showed that there was room for security improvement in the software develop-ment life cycle. Therefore, a lightweight secure developdevelop-ment process that can be used by developers, is proposed. The secure development process called Lightweight Developer-Oriented Security Process (LDOSP) is based on activities from other secure development processes and the choice of these activities were based on interviews with representatives of the IT-consulting company. The interviews showed that the process would need to be lightweight, time- and cost-efficient, and possible to be performed by a developer without extensive security experience. LDOSP contains 11 activities spread across different phases of the software development life cycle and an exemplification of the process was made to simplify the adoption of LDOSP.
The authors would like to thank the company and all their employees who helped us a lot during this thesis and made us feel welcome at their office and as a part of their organization. A special thanks to the representatives who we got to interview and our company supervisor who helped us understand the systems and always provided us with great support. Thanks to Suejb Memeti, our supervisor at Linköping University, for the academic supervision and all the feedback we received. Thanks to our examiner Ola Leifler for all the feedback and help during the thesis. Thanks to Kevin Larsson Alm and Kim Askling for reviewing the thesis and providing great feedback.
Contents
Abstract iii
Acknowledgments iv
Contents v
List of Figures vii
List of Tables viii
1 Introduction 1 1.1 Motivation . . . 1 1.2 Aim . . . 2 1.3 Research Questions . . . 2 1.4 Delimitations . . . 3 2 Background 4 2.1 Organization . . . 4 2.2 IMS . . . 4 2.3 Integration . . . 6 3 Theory 7 3.1 Related Work . . . 7 3.2 Security Testing . . . 10
3.3 Secure Development Processes . . . 15
3.4 Security Requirements . . . 20
4 Method 23 4.1 Interviews . . . 23
4.2 Security Testing . . . 24
4.3 Secure Development Process . . . 27
4.4 Exemplifying the Activities . . . 27
5 Results 30 5.1 Interviews . . . 30
5.2 Security Testing . . . 31
5.3 Secure Development Process . . . 38
5.4 Exemplifying the Activities . . . 44
6 Discussion 52 6.1 Method . . . 52
6.2 Results . . . 54
6.3 Threats to Validity . . . 56
Bibliography 60
A Interviews 63
B Security Activities 64
B.1 Attack Trees . . . 64 B.2 Attack Surface Identification and Reduction . . . 67
List of Figures
2.1 Architectural overview of the components of IMS. . . 5
3.1 The three pillars of the CIA Triad. . . 11
3.2 Overview of the different phases in the penetration testing approach described by P. Engebretson. . . 12
3.3 Overview of the different stages in FPVA. . . 14
3.4 Overview of SDL with phases and activities . . . 17
3.5 Official overview of the business functions and security practices of SAMM 1.5. . . 18
5.1 Architectural overview of IMS Web Server . . . 35
5.2 Architectural overview of the IMS Client . . . 36
5.3 Process overview of the proposed secure development process LDOSP. . . 45
B.1 Attack tree showing how the local client database can be attacked. . . 64
B.2 Attack tree showing how the client can be disrupted by an attacker. . . 65
B.3 Attack tree showing how an attacker can get data from the client. . . 65
B.4 Attack tree showing how an attacker can modify a client’s data. . . 66
B.5 Attack tree showing how arbitrary code can be executed by an attacker. . . 66
3.1 Activities in each of the security principles in the business function construction. . 18
3.2 Activities in each of the security principles in the business function verification. . . 19
3.3 Activities in each of the security principles in the business function operations. . . 19
4.1 Comparison of static analysis tools . . . 24
4.2 The mapping of which activities that will be considered for each phase of LDOSP. 27 5.1 Puma Scan results for the IMS-server. . . 31
5.2 Puma Scan results for the IMS-client . . . 32
5.3 SonarQube results for the IMS-server . . . 32
5.4 SonarQube results for the IMS-client . . . 32
5.5 ZAP-scannning results . . . 32
5.6 Arachni scanning results . . . 33
5.7 Manual Code Review results for the server. Categorized according to the CIA Triad with Confidentiality, Integrity and Availability. . . 37
5.8 Manual Code Review results for the client. Categorized according to the CIA Triad with Confidentiality, Integrity and Availability. . . 37
5.9 Ramesh & Reddy’s comparison of elicitation methodologies for security require-ments. . . 39
5.10 Activities for the secure development process LDOSP . . . 44
5.11 Security requirements elicited from attack trees. . . 45
5.12 The security requirements that were elicited from the best practices. . . 47
5.13 Checklist for configuration. . . 48
5.14 Checklist for general code. . . 48
5.15 Checklist for web server code. . . 48
5.16 Checklist for project specific code. For IMS Client in this case. . . 49
5.17 List of recommended software frameworks and libraries. . . 49
5.18 Attack surface identification and reduction for a feature gathering events from MEC’s log. . . 51
1
Introduction
Security awareness among companies and organizations is becoming increasingly important, especially when more and more company data is made available in the cloud. The average cost of a data breach has increased significantly in the last ten years and reached $3.86 million in 2018 [1]. Many companies only consider security at the end of a software development project, when the main part of the application already has been implemented. However, there are many security aspects that need to be considered in an early stage, such as security in the design and security awareness among developers [2]. The most well-known process for integrating security in the software development cycle is Microsoft Security Development Lifecycle (SDL), which requires several security activities to be fulfilled within the different phases of the software development life cycle [3]. Besides SDL, several other secure devel-opment processes exist, but a 2010 study [4] showed that only 30.4 % of the participated organizations used a formal secure development process even though many of them were aware of at least one of the processes. When asked for a reason for not adopting a secure development process, the most common answer was blank (no reason) followed by too time-consuming and not aware of methodologies.
Today, companies often have a wide range of internal software systems and databases to handle things such as enterprise resource planning, customer relations management, and supply chain management. An Enterprise Application Integration (EAI) is used to connect and integrate these different systems. EAI makes it possible to create a web interface that can exchange enterprise data with the EAI using XML protocols, and presenting them in various flexible ways that facilitate access, monitoring, and analysis for decision makers. [5]
1.1
Motivation
Making the enterprise data available for access from the web open up a wider attack surface regarding the availability of the service, integrity of the data, and confidentiality of the en-terprise data. This strengthens the need for security in the software development process [6]. Several formal secure development processes have been developed to be applied on a general software development project [7, 3]. However, some of the activities within these processes require a lot of security expertise, are costly and time-consuming [4]. These aspects are the reason why some organizations find the security processes to be too complex to implement
and requiring too many resources to be affordable [4]. Therefore, it is interesting to develop a secure development process that can be adopted by smaller organizations in need of a more lightweight process. This process will be aimed mainly for the developers and shall be designed so that it is usable without extensive security knowledge.
This thesis was conducted at a IT-consulting company that develops Microsoft based inte-gration solutions for enterprise systems and enterprise data. They have been anonymized in this report and will be referred to as the company. By interviewing company representatives, important aspects regarding security and security processes will be discovered. A web mon-itoring system called Integration Monmon-itoring System (IMS), that the company has developed will also be tested with automatic tools and manual code review to evaluate the security of the product. The results of the interviews and security testing will be used when evaluat-ing and choosevaluat-ing activities for the lightweight security process. To make the process easier to adopt, an exemplification of the process will be done while developing new integration services for IMS that integrates Infor Enterprise Collaborator (MEC), which is the integration platform of the Enterprise Resource Planning (ERP) system M31.
1.2
Aim
The aim of this thesis is to develop a lightweight secure development process. The process will be referred to as Lightweight Developer-Oriented Security Process, LDOSP. LDOSP is sup-posed to be easier to learn and use than the large secure development processes that exist today and it should not require the same amount of time. The process will be aimed toward developers and therefore, smaller companies without security expertise will be able to adopt the process.
1.3
Research Questions
In this thesis the following research questions have been defined:
1. Why does not the company in question use a formal secure development process in their software developing projects even though their software handles sensitive client data?
According to a 2010 study [4] there exist several different reasons that companies are not using secure development processes. By understanding why, it will be possible to develop a customized secure development process that fits the needs of the company. The question will be answered by interviewing employees.
2. Which security vulnerabilities can be found in IMS?
The search for vulnerabilities will be carried out by manual code review, static analysis, and dynamic analysis. The vulnerabilities found will indicate if there is a need for a secure development process at the company in question.
3. How can a cost- and time-efficient customized secure development process be defined to secure IMS, by identifying key aspects from formal secure development processes? By studying and comparing activities proposed by different secure development processes during the phases of the software development life cycle, key activities will be chosen based on the needs of the company in question. Such needs will be answered by research question 1,
1.4. Delimitations
for example, the activities may need to be resource efficient and cost efficient. The evaluated activities will be carried out when implementing the MEC services.
1.4
Delimitations
The activities included in LDOSP will be based on the activities from three different secure development process; Microsoft Security Development Lifecycle (SDL), OWASP Software Assur-ance Maturity Model (SAMM), and McGraw’s Touchpoints. The activities of LDOSP will be exemplified, but not validated, in this report.
This chapter will present the organization of the company in question and also their product, IMS, with its high level architectural components. It will also contain some background infor-mation about Enterprise Resource Planning system and Enterprise Application Integration.
2.1
Organization
The company is an IT-consultancy specialized mainly in software integration, but also in web development. There are approximately 25 employees and the structure of the organization is flat. The company is a Microsoft Partner1, therefore they are mainly using programs and services provided by Microsoft. The company mostly works on small scale projects of varying type, with only a few consultants in each project team.
2.2
IMS
IMS is a web application that visualizes data collected from integration platforms. IMS makes the information available for more users within an organization since the web application is accessible from multiple devices. The company in question offers IMS as a subscription service to their customers. Currently IMS mainly collects data from the customer’s Microsoft BizTalk Server2, but the application will be developed to support other integration platforms as well. The whole system consists of four main parts; web server, web interface, database, and clients. An overview of the system is shown in Figure 2.1.
Web Server
The web server is a middleware that handles the information flow between the client and the database and the flow between the web interface and the database. The web server is devel-oped in the open source web framework ASP.NET3. The web server and the web interface are hosted on the same domain.
1Offical Microsoft Partner site: https://partner.microsoft.com/en-US
2Official BizTalk Server site: https://www.microsoft.com/en-us/cloud-platform/biztalk 3Official ASP.NET site: https://dotnet.microsoft.com/apps/aspnet
2.2. IMS
Client
The client mainly uploads data from the integration platform through the web server to IMS’s database in the cloud, but some write operations also occur on the client’s system. The client is developed in .NET4and it is deployed at each of the customer’s site. The clients checks for updates regularly and automatically updates themself by downloading dynamic-link library (DLL) files accessible through the web server. The DLL-files contains a library of services which can be described as actions that the client can perform. It is possible to change the configuration of each client, e.g. how often it should synchronize with the IMS database and which services that should run, through the web interface. This can currently be done by IMS administrators.
Web Interface
The web interface is built in Angular5, which is a web application framework for both mobile and desktop devices. The web interface is shared among all of the users of IMS, but the views can be customized for each organization. The web application is accessible publicly on the web, but the users are required to log in to access any functionality. The user accounts are handled by the company and it is not possible to register a new account as an unauthorized user.
Database
IMS contains a Microsoft SQL Server6database that is hosted on the cloud and shared be-tween all of the different organizations that subscribe to IMS. The database contains both the customers’ data and all information that is required for the web interface to work, such as the user credentials.
Web Server
Database
Customer 1
Client
Web Interface
Customer 2
Client
Customer N
Client
Figure 2.1: Architectural overview of the components of IMS.
4Official .NET site: https://dotnet.microsoft.com 5Offical Angular site: https://angular.io/
2.3
Integration
Enterprise Resource Planning systems (ERP) automates several important activities in a company. They can handle manufacturing and supply chain planning, human resources and finance. ERPs enable information flow in real time and simplifies information access across the enterprise. [8]
D. S. Linthicum describes, in the book Enterprise Application Integration [9], that Enterprise Application Integration(EAI) has developed from the need for sharing data and simplifying the integration between different applications in an enterprise without the need to change or restructure the application. EAI has the advantage, in contrast to ERP-systems, that it makes it possible to integrate existing applications rather than replacing all of the applications within a system. EAI is, therefore, in general, a cost-effective solution from the company’s perspective. ERP and EAI systems can also be combined to make it easier to integrate an ERP system with external applications. The ERP-system M3 is an example of where an EAI-system, MEC, has been included as a module to the ERP-system.
Several types of EAI-systems are described in the book, classified by which level they inter-act with other applications. These levels are the user interface, method, application interface, and data level. In the case of the MEC client, the integration will be on the data level since this was the type of integration that the company in question preferred. D.S. Linthicum fur-ther describes that it is important, on the data level, to understand the metadata for each database to make it possible to select the data that will be moved to another database. It is also important to consider the frequency that the data should be synchronized with between the different databases.
3
Theory
This chapter contains the sections Related Work, Security Testing, Secure Development Pro-cesses, and Security Requirements.
3.1
Related Work
An article from 2010 by D. Geer [4], which analyzed the result from a survey performed by the security organization Erratasec regarding the adoption of secure development processes, showed that only 30 percent of the companies that participated were using a formal secure development process. The results from the survey further indicated that companies that had fewer than 10 developers had a higher adoption rate. 46 companies participated in the study and the error margin was 14.5 percent. The most common reasons for not adopting a secure development process was that it is too time-consuming and that the companies are not aware of the methodologies. D. Geer also interviewed a project manager at Erratasec, who claimed that "The root cause of software vulnerabilities is found in the early stages of the software development life cycle. The majority of vulnerabilities could easily be taken out at this stage". The project manager also criticized existing secure development processes for being too expensive and complex to implement.
H. Mouratidis, P. Giorgini, and G. Manson [10] describe the lack of security awareness among developers and how the security requirements tend to be considered too late in the project after the system has been defined. The cost to mitigate security risks that are found late in the project is high, and it might even require a rebuild of some system components. C. Blanco et al. [2] also addresses this issue when they develop a secure architecture for online analytical processing applications and suggest that security should be considered from the beginning in software development projects to reduce time and cost. They also highlight the importance of security in systems that handle sensitive business data. In a survey from 2008, I. A Tøndel, M.G Jaatun, and P.H Meland [11] further elaborate on the lack of security awareness among developers and they suggest a lightweight approach aimed to help developers to identify security requirements. The approach is based on what has been considered as good practice in requirement engineering and the techniques chosen are supposed to be applicable for the average software developer. I. A Tøndel et al. [11] also criticize some of the existing formal models that are used to gather security requirements for being too complicated for its
in-tended audience. I. A Tøndel and M.G Jaatun followed up their work with a published paper in 2008 [12], in which they suggest a method to identify and prioritize assets in software development projects. In 2008, I. A. Tøndel, M. G. Jaatun, and J. Jensen [13] published a paper regarding how an organization can use an intra-organisational repository that contains previously discovered vulnerabilities. The aim of using the repository is to close the feedback loop and, by that, learn from the previous mistakes.
The 2011 paper "A survey on security issues in service delivery models of cloud computing" by S. Subashini and V. Kavitha [6], highlights security issues in different cloud computing services and also states that it is important for the provider to address these security chal-lenges, thus it is the provider who is responsible for them. The following security areas are a selection of the areas addressed regarding software as a service (SaaS) in the survey:
• Data security - Enterprise data on the cloud does not have the physical security that it traditionally had. This requires the provider to use proper encryption and authorization in the service they provide.
• Network security - Since the network activity increases and the sensitive enterprise data flow on the network, network encryption such as Transport Layer Security (TLS) and strong session management needs to be in place.
• Data segregation - Multiple tenants storing their data on the same database and ac-cessing them from the same interface open up the risk of one tenant getting access to another tenant’s data either by flaws in the application or by code injection. There-fore, the service must be tested and secured against SQL injections, data validation, and insecure storage.
• Data access - The authors explain that the service provider needs to take into account that the clients may have different security policies within their organizations, where some users may have limited access to the enterprise data. This requires the cloud service to be flexible so that clients can use their different access policies on the service. • Authentication and authorization - Companies often have to copy their user creden-tials to the database of the SaaS provider. If a company use several different SaaS ser-vices, there is a risk that they forget to remove access for employees that left the com-pany. To mitigate this risk, SaaS providers can forward the authentication process to the clients’ internal systems.
• Web application security - Security vulnerabilities of a web interface can impact the security of the underlying SaaS system. The authors list the ten most important web security threat as proposed by The Open Web Application Security Project1(OWASP). The authors also highlight several other important areas such as data integrity, data confi-dentiality issues, data breaches, availability, and backup. They continue with an overview of security solutions that are available for the cloud, some proposed by security organizations, and some by researchers. For example, there is The Cloud Security Alliance2 (CSA) who specialize in cloud security practices and OWASP, who published a list of the most important cloud security vulnerabilities.
In 2009, B. De Win et al. [14] compared three of the most recognized secure development processes available, SDL, OWASP’s Comprehesive, Lightweight Application Security Pro-cess (CLASP), and Touchpoints. To be able to compare them phase-by-phase, they mapped different activities of the processes to phases that represent a software development life cycle.
1OWASP: https://www.owasp.org/index.php/Main_Page 2The Cloud Security Alliance: https://cloudsecurityalliance.org/
3.1. Related Work
The authors then explain which activities each process proposes for each phase and discuss them, their effect, and stakeholders involved. Sometimes, the authors give suggestions about activities that they think are missing or activities that should be conducted differently. The authors also performed a case study for the three processes to verify their claims and discus-sions in the theoretical comparison. In the case study, the authors let three different pairs of developers use one of the processes each when developing software for an ATM machine. Some of the phases and activities were skipped since no implementation was included in the ATM case study. After analyzing the result of the case study, the authors found strengths and weaknesses in all of the three processes. CLASP was the most time-consuming followed by SDL. One criticism that the authors have is that some of the activities, especially in CLASP and SDL, are more like guidelines rather than activities. They also mention that SDL and CLASP do not focus on how to do the work in the activities. Instead, they focus on what has to be done, but a business process should provide a methodology on how to do what is pro-posed. Touchpoints is better at providing a methodology on how to do things but does not do it in all cases. The authors also discuss how easy it is to integrate the different processes for companies that already use well-defined development processes and state that CLASP may be difficult to integrate into an agile environment. The trade-off between security and organization dependent constraints such as costs is also discussed. Both CLASP and Touch-points provide information on such constraints and guidelines for activity prioritization, which could be useful for organizations with limited resources. The authors conclude that it is difficult to know which secure development process is suitable for a given organization and that it is valuable to know the strengths and weaknesses of different processes.
A more recent comparison of these three secure development processes was made in 2017 by M. Abushariah, J. Alqatawna, and A. Mohammad [15]. They found strengths and weak-nesses in all three of the processes. They considered the strengths of Touchpoints to be that it is lightweight, contains both constructive and destructive activities and that it is easy to adapt. Constructive activities are related to design, defense, and functionality. Destruc-tive activities are instead focused on attacks, exploits, and how to break the software. The weaknesses of Touchpoints were the lack of education activity and that it did not contain guidance nor which resources that are required to complete the activities. CLASP was also easy to adapt but also included rich guidance and resources. The weaknesses were lack of destructive activities and a requirement for an experienced security team. The strengths of SDL was that it provided tools and resources and the biggest weakness was that it was too heavyweight and difficult to adapt. All in all, the authors concluded that there is a problem with security processes since too few companies use them. They state that there is a need for a new security process which should be time-efficient, easy to adapt and that this process should rely a lot on automatic tools. All the activities should be doable without expertise in security.
In 2018, I. Becker et al. [16] highlighted the problem that developers seldom adopt security processes and they do not consider security to be their responsibility. To see if security awareness could be improved among developers, they performed a study where they held interventions with a number of developers from two teams. The interventions consisted of workshops led by one of the authors. The authors first interviewed the developers to get a baseline of the developers’ current security awareness and the quality of their code in terms of security. Similar interviews were conducted during the interventions so that they could compare the results with the first set of interviews. All activities in the study were performed in a way to keep the developers motivated since the authors argue that developers generally do not like to follow formal methods or being told exactly what to do. They were also formed to be inexpensive, as easy as possible and not too time-consuming. One activity that they thought was too expensive and ineffective was penetration testing. The authors concluded that their method improved the security of the development teams and that the
understand-ing of consequences, of security issues, improved for the participants. At the same time, the method is inexpensive and does not require much previous skills and knowledge from the team.
Most of the existing secure development processes are described, in the article by D. Geer [4], as too time-consuming or too complex according to the project manager interviewed by D. Geer. The study by M. Abushariah et al. also reached similar conclusions about the current state of secure development processes [15], but they also concluded that the activities should not be dependant on expertise in security. There is a lack of security awareness among developers [10, 11, 16]. This indicates that there is a need to aid developers in their work and to help them increase their security awareness.
To summarize, this shows that there is a need for a secure development process that targets the developers in an organization. A process that contains a lightweight approach which is applicable for developers that lacks expertise in security.
3.2
Security Testing
In a 2004 article by B. Potter and G. McGraw [17] it is described how software vulnerabilities can be divided into two main categories; implementation level bugs and design level flaws. The flaws at the design level are the hardest to handle since it might be necessary to redesign the system, these flaws are generally the most critical. The design level flaws are both harder and require more expertise to find, which makes it difficult to automate the process of finding them. The authors describe how it is common among developers to have the mindset that adding security features such as SSL, firewalls or other forms of cryptography will secure an application by itself. The authors claim that the root of the problem is bad software with insufficient error handling rather than a question about which ports that are allowed in the firewall.
The CIA Triad
The CIA Triad stands for Confidentiality, Integrity, and Availability as seen in Figure 3.1. It is a widely used model for classifying security. Confidentiality is the concept of protecting data from being read by people who are not authorized to view it. It is closely related to the concept of privacy. Integrity is the concept of protecting data from being altered or deleted by unauthorized users but also protecting data from undesirably being changed or deleted by authorized people. Availability is the concept of always being able to access data when needed. The availability of data can rely on several systems such as the electrical grid, the network connection, operating system, and database. If one of the systems stopped working the availability would be gone. [18]
Security vulnerabilities can be mapped to the three different concepts of the CIA Triad de-pending on what happens with the data if the vulnerability is exploited. Each vulnerability can be mapped to one or more of the concepts. After classifying a vulnerability according to the CIA triad it will facilitate the estimation of severity. [18]
Penetration Testing
G. McGraw, B. Arkin, and S. Stender [19] describes how penetration testing tends to be used at a late stage during the development process and that it is then often too late to fix the vulnerabilities found. One of the other issues with this approach is that the bugs found dur-ing the penetration testdur-ing are interpreted as a complete list of security-related bugs rather than a representation of the types of bugs that exists in the code base. A root cause analysis
3.2. Security Testing
Confidentiality
Availability Integrity
Figure 3.1: The three pillars of the CIA Triad.
should be performed by the developers in order to find similar bugs and to increase security awareness within the organization. G. McGraw et al. also claims that it is not enough to only use penetration testing and that it is important to follow best practice throughout a secure development process in order to develop secure software. In articles from 2005 and 2006, G. McGraw [20, 21] further criticize penetration testing for being based on patching insecure software rather than having security in mind during the whole development process. G. McGraw even refers to the approach to only use penetration testing as a badness-ometer since penetration testing only can prove that a system is not secure, but not the opposite [21]. P. Engebretson [22] suggest a network penetration testing approach that is divided into four different phases; reconnaissance, scanning, exploitation, and post-exploitation. These phases are visualized in Figure 3.2.
• Reconnaissance phase - The reconnaissance phase, also known as the information gath-ering phase, is when the penetration tester gathers information about the targeted sys-tem. There are two types of reconnaissance; passive and active. Active reconnaissance is based on interacting directly with the target and the target may, therefore, log the IP-address and activity. Passive reconnaissance is instead based on finding informa-tion about the target without interacting directly with the targeted system. Informainforma-tion of interest is, for example, IP-addresses to system components, hardware setup, and software setup.
• Scanning phase - The IP-addresses from the reconnaissance phase are used in the scan-ning phase to identify services that run on the targeted system and also potential vul-nerabilities. The scanning phase should start with port scanning and then be followed up by a vulnerability scan that is based on the list of IP addresses, open ports, and services on each of the targeted machines.
• Exploitation phase - In this phase, the results from the scanning phase should be used to target attacks towards potential vulnerabilities discovered in the system. The process to gain access to the system is called the exploitation phase.
• Post-exploitation phase - The post-exploitation phase is about maintaining access to the exploited system without having to exploit it again. This can be achieved by adding a backdoor to the targeted system after it has been exploited.
Reconnaissance
phase Scanning phase Exploitation phase
Post-exploitation phase
Figure 3.2: Overview of the different phases in the penetration testing approach described by P. Engebretson.
P. Engebretson [22] mentions that there are three different activities that are important to perform during web-based penetration testing. It is important to be able to intercept requests and to be able to edit values after the request has been sent from the web browser, this can be achieved by using a proxy. The website that is being targeted should also be crawled in order to get an understanding of the attack surface of the web application. Lastly, the responses from the targeted web application should be analyzed in order to find potential vulnerabilities.
Static Analysis
Static analysis tools analyze the code base without executing the program. Since the program is not executed, static analysis is applicable in the implementation phase. There exist several different types of static analysis tools ranging from basic lexical analysis tools to tools that create an abstract syntax tree from the source code in order to analyze linguistics of the program. [23]
Symbolic execution is a form of static analysis, that was first proposed by J.C. King [24] in 1976. The idea behind symbolic execution is to use symbolic values instead of concrete val-ues to analyze the control flow of the program. Symbolic execution can represent a number of concrete executions and since it is based on the control flow of the program it is possi-ble to perform symbolic execution without compiling the code. During static analysis, the constraints in an execution path are gathered and the resulting equation is then checked for satisfiability using a constraint solver. C. Cadar and K. Sen [25] mentions, in an article from 2013, that one of the challenges that still remain with symbolic execution is that the paths of the program grow exponentially with the size of the program and that it eventually will be unfeasible to test all of the paths with symbolic execution, this problem is commonly referred to as the path explosion problem of symbolic execution.
Dynamic Analysis
G. McGraw [26] states in his book from 2006 that static analysis and dynamic analysis should be performed uniformly since they complement each other. Dynamic analysis is performed when the program is running, in contrast to static analysis which is performed on the source code. Dynamic analysis is able to detect errors that occur during run-time while static analy-sis can detect implementation-level bugs.
3.2. Security Testing
OWASP lists several different Dynamic Application Security Testing (DAST) tools on their official website. D. Sagar et. al [27] compared three different open-source DAST tools in a paper from 2018; w3af3, Skipfish4, and OWASP Zed Attack Proxy5 (ZAP). The tools were tested on a web application that contained known vulnerabilities. The authors concluded that ZAP performed better than Skipfish and w3af, but that none of the tools in the study could detect all of the OWASP, 2013, top 10 vulnerabilities.
B. Mburano and W. Si [28] evaluated the web application security scanners ZAP and Arachni6 in a paper published 2019. ZAP is an open-source web application security scanner that is maintained by OWASP [29]. Other than scanning web applications for vulnerabilities, the tool’s proxy feature can be used during manual penetration testing to be able to intercept the requests in order to analyze or manipulate requests. ZAP is designed to be easy to use and it also supports multiple platforms [29]. Arachni is an open-source web application security scanner framework implemented in Ruby [30]. Arachni is created to help penetration testers and administrators to evaluate the security of web applications. Similar to ZAP, Arachni supports multiple platforms [30]. ZAP and Arachni were chosen since the authors considered them to be regularly updated by a number of contributors and because of their popularity. Both of the tools were tested according to the OWASP benchmark metodology7. The results were then compared to results from the Web Application Vulnerability Scanner Evaluation Project (WAWSEP) benchmark8. The results from the benchmarks showed that the scanners performed differently in detecting vulnerabilities and the authors concluded that neither of the tools is better than the other overall, but that they each have their strengths. Since this is the case, the authors suggest that the scanners could be used on the same web application to improve vulnerability detection.
Manual Code Review
Systematically reviewing the code is important to ensure that the code is free from bugs and vulnerabilities. The best approach is to have an independent person or team, that is not part of the development team, perform the assessment. This person or team should have expertise and knowledge of software security and known vulnerabilities. One methodology for man-ual code review is First Principles Vulnerability Assessment (FPVA) where the analyst tries to identify components with a high risk and where valuable assets are at stake. Then, the analyst tries to identify which vulnerabilities are associated with those specific components. Typical places and components in the code that classifies as high risks are for example configuration files, code that is run with high privilege, code that handles authentication or code that han-dles security certificates. FPVA consists of four stages, shown in Figure 3.3 where only the last stage is the actual code review. The first three stages are there to help the analyzer to understand the system.
1. The first stage is called architectural analysis and is used to understand the overall architecture and key components of the system.
2. The second stage is resource analysis which means that the analyzer identifies which resources are used and accessed by the different components. A resource is typically the main target of an attack or exploit and can be a device, database, file or similar. The value of each identified resource should be described.
3Official w3af site: http://w3af.org/
4Official Skipfish project site: https://code.google.com/archive/p/skipfish/
5OWASP Zed Attack Proxy: https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project 6Official Arachni site: http://www.arachni-scanner.com/
7OWASP benchmark: https://www.owasp.org/index.php/Benchmark
8WAWVSEP DAST benchmark:
3. The third stage is called trust and privilege analysis where the analyst identifies who has access to each component and who can modify each component as well as identifying the privilege level that the component runs on.
4. Finally, the fourth stage is the code review. Since many systems are extensive and large, it could possibly be too time-consuming to review each line in the whole code base. That is why stage one to three in FPVA results in a prioritization list. When reviewing the code, the analyzer should look for two types of vulnerabilities; There can be design flaws that are the cause of bad system architecture, or there can be implementation bugs that are more local and the cause of a coding error. [31]
Architectural
Analysis ResourceAnalysis
Trust and Privilege Analysis
Code Review
Figure 3.3: Overview of the different stages in FPVA.
Manual code reviews has proven to be more efficient in finding vulnerabilities compared to using automatic tools with the downside being that manual code reviews require more knowledge by the analyzer and are also more time-consuming. [31]
OWASP Top 10 Web Application Security Risks
In web application security there exists a number of common attacks. By understanding how these attacks work it becomes possible to mitigate them. OWASP have summarized the 10 most critical web application security risks in a report [32] published in 2017.
1. Injection - Several different forms of injection exist, such as SQL-, NoSQL-, OS-injection. An application is vulnerable when data from an untrusted source are used without proper validation, filtering, nor sanitation.
2. Broken Authentication - According to OWASP it is common that functions related to authentication and session management are implemented in an insecure way. Broken authentication may lead to attacks such as session hijacking and brute forcing.
3. Sensitive Data Exposure (SDE) Sensitive data that is not properly protected can be stolen or modified by an attacker. Data that are transferred over HTTP, SMTP and FTP are vulnerable since the data are sent in clear text and the data should therefore not contain any sensitive information. SDE can be mitigated by e.g. encrypting all data in transit and encrypting all sensitive data at rest.
4. XML External Entities (XXE) - Vulnerable XML processors can be exploited if it is pos-sible to upload XML-documents or insert data from untrusted sources. XXE can be mitigated by e.g. sanitizing inputs and updating XML-processors to the latest version. 5. Broken Access Control (BAC) - A BAC flaw is when a user can access information
or functionality that should not be allowed with the privileges that the user has been granted. An example of this would be an unauthorized user that can view information that only logged in users should be able to view. The risks of BAC can be mitigated by e.g. reusing access control mechanism throughout the application.
6. Security Misconfiguration - It is common for attackers to try to find vulnerabilities in the applications that run on a server. The risk of security misconfigurations can be mitigated by e.g. not having unnecessary applications and features enabled and keeping the software on the server up to date.
3.3. Secure Development Processes
7. Cross-Site Scripting (XSS) - XSS flaws exist if a web application includes data from untrusted sources on the web application without filtering or sanitizing the data. XSS makes it possible for the attacker to execute JavaScript in a victim’s web browser. There are three different forms of XSS; reflected, stored, and DOM XSS. Reflected XSS requires the victim to click on a link which includes malicious code in the URL that gets injected to a website that is vulnerable to XSS. Stored XSS is when the application or API stores unsanitized input, from untrusted sources, that later executes when a user views the data in the browser. DOM XSS is when malicious code is injected into a vulnerable API call that will not get executed until the API is used on the web application. XSS can be mitigated by e.g. enabling a Content Security Policy (CSP), using secure frameworks, and by sanitizing data from untrusted sources.
8. Insecure Deserialization - A web application is vulnerable if it deserializes data from untrusted sources. Consider to not deserialize data at all from untrusted sources or only allow mediums that contain primitive data types. If deserialization of untrusted data is required, the risks can be mitigated by e.g. using integrity checks, running deserializa-tion in a low-privilege environment, and logging the deserializadeserializa-tion process to detect potential errors.
9. Using Components with Known Vulnerabilities - Software components run with the same privileges as the application. Vulnerable components might make it possible for an attacker to get privileged access to the system if an unsafe component can be ex-ploited. To mitigate this type of attack it is important to e.g. keep the components up to date and to only obtain the components from official resources.
10. Insufficient Logging & Monitoring - Insufficient logging & monitoring may lead to breaches not being detected early. The attacker can then further attack the system and extract data continuously. By logging & monitoring the system it is possible to react as soon as an intrusion is detected.
In the OWASP top 10 most critical web application security risks from 2013 [33] cross-site re-quest forgery(CSRF) was included, but it was removed in the updated report from 2017 due to that many frameworks includes CSRF defenses. During a CSRF attack, the attacker man-ages to send a request from the victim’s browser to a vulnerable web application. If the victim is authenticated on that web application the server will not be able to distinguish the attacker-generated request from a real user-attacker-generated request since authentication information such as session cookies will automatically be included in the request by the web browser. CSRF can be mitigated by including an unpredictable, unique, and temporary token. The token should be generated by the server and included in each request.
3.3
Secure Development Processes
Secure development processes introduce security in the software development life cycle. Be-fore they were introduced, developers used to address security after the implementation was finished or not at all [4]. This section present the secure development processes SDL, SAMM and Touchpoints.
SDL
SDL was the first secure development process [4]. The security activities in SDL as proposed by S. Lipner in 2004 [3], are divided into different phases that correspond to phases of a general software development life cycle as seen in Figure 3.4. According to the SDL, it is important that all activities of a phase are completed before moving to the next phase. The SDL is divided into the following phases:
1. Training - This stage is not really a phase but more of a prerequisite for the participants. The authors say that different kinds of education can be used depending on the size of the organization.
2. Requirements - In this phase, the development team needs to establish security require-ments for the software that they are developing by identifying what is needed in terms of security. They also appoint a security advisor that will assist the team throughout the project.
3. Design - The team should work on the design and architecture from a security perspec-tive where the critical security components are identified so that secure design patterns and other security techniques can be applied on these components. They should also analyze the attack surface to give them an overview of where the software is sensitive to attacks. Another important activity in the design phase is threat modeling. By using a methodology for threat modeling, the team can detect threats and study the risks before coming up with a mitigation plan.
4. Implementation - During this phase, the team state which standards and tools they are going to use during implementation. The list of these tools and standards should be reviewed and approved by the security advisor. All unsafe functions should also be deprecated to avoid security flaws in the software. Unsafe functions are old functions in C/C++ that have been deemed unsafe by Microsoft, often because they can lead to buffer overflows [34]. At the end of the implementation phase, the team should perform static analysis with automatic tools. These tools can detect various flaws such as buffer overflows and variables that have not been initialized. The team should also review the code manually since the experienced developers may find flaws in the code that was not detected by automatic tools.
5. Verification - A tool that should be used in the verification phase is fuzzing. Fuzzing puts invalid inputs to the software which can be analyzed to find vulnerabilities. In the verification phase, the software should be monitored to detect memory leaks and other flaws while performing dynamic analysis. It is also important to update the attack surface and threats to detect if any new threats have emerged since the last time those activities were performed.
6. Release - The final software should be reviewed from a security perspective so that all the security requirements that were set in the requirements phase are fulfilled. There should also be an incident response plan which states what should be done and who should be contacted in case of emergency. This plan should also include servicing plans for inter-organizational code and third-party code.
During the years, SDL has been updated with various updates containing new recommenda-tions of tools and new security mechanisms. The most recent version of SDL is 5.2 which was released in 2012 [35].
Software Assurance Maturity Model
OWASP were responsible for the development of the secure development life cycle called CLASP. However, OWASP realized that there was a need for a new model. The Software Assurance Maturity Model (SAMM) [36] aims to help organizations to formulate and imple-ment a strategy for software security. SAMM is a software security framework that is not tied to a specific type of development process nor targeted to a specific organization size. One of the most important characteristics of SAMM is that it is flexible. The OWASP organization aimed to develop a model that was usable for both small and large organizations and compa-nies. It is also flexible in means of being applicable organization-wide or for single projects. SAMM was built with three main principles in mind:
3.3. Secure Development Processes
Requirements Design Implementation Verification Release
Microsoft SDL
Establish SecurityRequirements
Create Quality Gates and Bug Bars
Security & Privacy Risk Assessment
Establish Design Requirements
Analyze Attack Surface
Threat Modeling
Use Approved Tools
Deprecate Unsafe Functions
Static Analysis
Dynamic Analysis
Fuzz Testing
Attack Surface Review
Incident Response Plan
Final Security Review
Release Archive
Figure 3.4: Overview of SDL with phases and activities
• The organization’s behavior changes over time - The process should stay updated according to the changes in the organization, but over time it should contribute towards the organization’s long term goals.
• No strategy works for all organizations - The strategy should take into account the risks that are prevalent for the organization, and it, therefore, needs to be tailored to the organization.
• Security related activities should be well defined - It shall be possible for people with-out expertise in security to understand the activities.
SAMM is divided into four business functions; governance, construction, verification, and deployment. Each of the business functions is further divided into three security practices. An overview of the business functions and security practices is shown in Figure 3.5. Each security practice has three different maturity levels that each contains an objective, activities, assessment, and results. SAMM is structured in such a way that it is possible to improve the security practices independently from each other. The business functions construction, verification, and to some extent operations, includes activities that can be performed by de-velopers. Overviews of the activities in the business functions construction, verification, and operations are shown in Tables 3.1, 3.2, and 3.3. The activities are described in more detail in the official documentation [7], which is available for download at the official site9.
Figure 3.5: Official overview [7] of the business functions and security practices of SAMM 1.5.
Activity Threat Assessment Security Requirements Secure Architecture
1.1 Build and maintain application specific threat models Derive security requirements from business functionality Maintain list of recommended software frameworks
1.2 Develop attacker profile from software
architecture
Evaluate security and compliance guidance for requirements
Explicitly apply security principles to design
2.1 Build and maintain abuse case models per project
Build an access control matrix for resources and capabilities
Identify and promote security services and infrastructure 2.2 Adopt a weighting system for measurement of threats Specify security requirements based on known risks
Identify security design patterns from
architecture 3.1 Explicitly evaluate risk
from third-party components Build security requirements into supplier agreements Establish formal reference architectures and platforms
3.2 Elaborate threat models with compensating controls
Expand audit program for security
requirements
Validate usage of frameworks, patterns, and platforms
3.3. Secure Development Processes
Activity Design Review Implementation
Review
Security Testing
1.1 Identify software attack surface
Create review checklists from known security requirements
Derive test cases from known security requirements 1.2 Analyze design against
known security requirements Perform point-review of high-risk code Conduct penetration testing on software releases
2.1 Inspect for complete provision of security mechanisms
Utilize automated code analysis tools
Utilize automated security testing tools 2.2 Deploy design review
service for project teams
Integrate code analysis into development process Integrate security testing into development process 3.1 Develop data-flow
diagrams for sensitive resources Customize code analysis for application-specific concerns Employ application-specific security testing automation 3.2 Establish release gates
for design review
Establish release gates for implementation review
Establish release gates for security testing
Table 3.2: Activities in each of the security principles in the business function verification [7].
Activity Issue Management Environment
Hardening
Operation Enablement
1.1 Identify point of contact for security issues
Maintain operational environment
specification
Capture critical security information for
deployment 1.2 Create informal security
response team(s)
Identify and install critical security upgrades and patches
Document procedures for typical application alerts
2.1 Establish consistent issue response process
Establish routine patch management process
Create per-release change management procedures
2.2 Adopt a security issue disclosure process Monitor baseline environment configuration status Maintain formal operational security guides
3.1 Conduct root cause analysis for for issues
Identify and deploy relevant operations protection tools
Expand audit program for operational
information 3.2 Collect per-issue
metrics
Expand audit program for environment configuration
Perform code signing for application components
Table 3.3: Activities in each of the security principles in the business function operations [7].
McGraw’s Touchpoints
Touchpoints is a model presented by G. McGraw in his book Software Security - Building Secu-rity In [26] that was published in 2006. The model is based on seven secuSecu-rity activities called touchpoints. The author clearly states the touchpoints in an order of the most effective to the least effective according to him. However, he also states that for some organizations, the order
can be different. The touchpoints, in that order, are; code review, architectural risk analysis, penetration testing, risk-based security tests, abuse cases, security requirements, and security operations. The whole model is based on the experience of G. McGraw, who is well known in the software security community. G. McGraw also states that there could have been more touchpoints but that it has been limited to seven so that a broader amount of people can adapt and use them. The author highlights the importance of security in all phases of software de-velopment and also that all people in an organization should be security aware. The model includes some example of bad code and explains how the flaws could be detected with, for example, code review. In the book, G. McGraw also proposes a risk management framework that is supposed to be integrable with the seven touchpoints. The following activities are part of Touchpoints:
1. Code Review - The model explains very thoroughly how tools can be used to review the code and states that it is one of the most important activities to perform to find vulnerabilities. Touchpoints lists a few example tools that can be used and has a guide on how to use one of them.
2. Architectural Risk Analysis - As in the code review touchpoint, several helpful tools are listed that can help the architectural risk analysis. There are also process diagrams that can help the reader to understand and perform architectural risk analysis. The au-thor explains that one must get an overview and understanding of the software system before continuing with risk identification.
3. Penetration Testing - Touchpoints gives an introduction to penetration testing, how it is used and what limitations it has. Touchpoints then introduce several tools that can be used when performing penetration testing. Some important aspects are brought up, such as how to handle the vulnerabilities that were found. It is not just a list of issues that should be fixed. Instead, the root cause of the problem should be identified and mitigated so that both that specific vulnerability and similar vulnerabilities will be avoided in the future.
4. Risk-based Security Tests - The author explains security tests and how they differ from penetration tests. The main difference is that security tests can be conducted at the unit level, in a testing environment, and while the software is still under development. It is highlighted that previously identified risks and threats should be tested specifically as well as standardized functional testing. Both strategies are important. When explaining how to conduct the testing, the author uses a case example, some example code, and also refer to other books specifically about security testing.
5. Abuse Cases - Abuse cases and why they are necessary are explained. The author states that brainstorming is the most effective way of creating abuse cases and explain how to write abuse cases with examples.
6. Security Requirements - The area security requirements is only briefly mentioned and is instead embodied within the chapters of risk-based security tests and abuse cases. 7. Security Operations - In this touchpoint, the author addresses the problem that
soft-ware developers often are separated from the information security department in orga-nizations.
3.4
Security Requirements
Security requirements are important in the development process and addressed by the pre-viously mentioned secure development processes SDL, SAMM, and Touchpoints. There is a
3.4. Security Requirements
range of different security aspects that need to be considered when stating the security re-quirements. Some of these aspects are authentication, authorization, integrity, privacy, and intrusion detection. When describing security requirements it is essential to have a common view of what is important, within the internal team, and with other stakeholders. It is also important that the requirement engineer has some knowledge of the surroundings of the system, possible threats and known attacks. [37]
Elicitation Methodologies
Two common methodologies that can be used to elicit security requirements; misuse cases and attack trees, were compared by A. Opdahl and G. Sindre in an experimental study 2009 [38]. The study showed that the participants found more threats while using attack trees than using misuse cases. It was especially threats related to authorization and confidentiality that were discovered with attack trees. When the authors studied the threats in detail they found that the two techniques complement each other.
Another comparison between different techniques for elicitation of security requirements was conducted in 2016 by M. R. Ramesh and C. S. Reddy [39]. Their study focused on applicability and compared 15 different techniques. These 15 techniques were divided into different groups. The groups were use case modeling, tree modeling, pattern technique, and agile and risk analysis based techniques. The study showed that none of the techniques was superior, they all had pros and cons. However, abuse cases, fault trees, attack trees, security patterns, CLASP, and abuser stories were all suitable for small scale projects, easy to learn, and easy to use.
When using abuse cases, the requirement engineer first identifies actors that are going to interact with the system. Then he defines the abuse cases, which are ways that the actor communicates with the system in a malicious way. Fault trees are trees where the require-ment engineer uses a set of mathematical tools to identify critical areas. It often leads to large trees and can take a lot of time and effort to complete. Attack trees is another technique in the group of tree modeling where the roots of the trees are goals that an attacker wants to achieve. The upside of attack trees is that the technique follows a systematic procedure and it can be reusable. The downside is that their focus is on knowledge of an attacker and that they are difficult to apply on large scale projects. Security patterns are derived from design patterns. When using security patterns, the requirement engineer identifies security-related resources, factors, and the relation between them, which security requirements are elicited from. [39]
As mentioned in the related work chapter I.A Tøndel et al. [11] compared security require-ment techniques and came up with a lightweight approach suitable for the average developer. In their approach, they recommend that elicitation should be based on the viewpoints of the client, the system owner, and the attacker and that valuable assets should be identified for these actors. They suggest that security requirements can be elicited from functional require-ments with the aid of brainstorming. When it comes to eliciting requirerequire-ments by looking at the attacker’s viewpoint, they suggest attack trees to be used.
Attack Trees
Attack trees is a well known and widely used technique for security requirements elicita-tion [40]. Attack trees are graphical models where attacks on a system are shown in a tree structure, which makes it easy to get an overview of them. The root of the tree is the final objective of an eventual attacker and is produced by brainstorming. After the root is in place, the tree is then built with each node representing an attack that can fulfill the objective of its
parent. Each child node can represent different ways of achieving the objective of its parent node and they are then called OR-nodes. There are also AND-nodes, where several child nodes and therefore attacks, are needed to reach the objective of their parent node. For each software system, there will typically exist several attack trees since the goal of the root node can be several different things. An attack tree can be further developed with different values and estimations. Examples of these values can be the cost of an attack, if the attack requires tools, if the attack is legal to perform, or an estimation of the difficulty to perform the attack. These values can be either boolean or continuous and will help the analyst to get an overview of which attacks are more critical within a tree and which trees are more critical in comparison to other trees. [41]
4
Method
This chapter describes the methods used to answer the research questions. Methods for the following are described in detail:
• Interviews with company representatives • Security testing of IMS
• Development of LDOSP • Exemplification of LDOSP
The first step of the overall process was to get an understanding of the subject company, their knowledge, and thoughts on software security as well as their prioritization when it comes to software development. The answers from the interviews were used as a foundation when choosing activities for the development of the customized secure development process. After the interviews, a process began of choosing tools for testing the current code base. Two main testing phases were conducted; automatic code testing and manual code review.
After the first two activities, interviews and security testing, the implementation phase was conducted. The purpose of implementing the MEC services was to have a foundation to apply and test security activities. By testing and analyzing certain key activities from several different formal security processes, a new customized security process could be formed by identifying which activities could suit the company without conflicting with the concerns and limitations that were noted during the interviews with management. The implementation project was a software project similar to what has been done previously when the company implemented the BizTalk services. It was important to conduct the security activities on a project that resembles the type of software development projects that are usually conducted at the company.
4.1
Interviews
Interviews were conducted early during the project in order to understand the company’s current situation and also what aspects that are important to them when it comes to adopt-ing a secure development process. Three company representatives were chosen, based on
