CS421 Saudi Electronic University Software Security Engineering Paper

Question Description
I need to summarize the attached papers find out the Software Engineering of Security to write a full report by summarizing the 5 papers.

Instructions:

1- use only the 5 papers as resources and their references.

2- following the Academic style as APA style.

3- Plagiarism not allowed.

4- apply the report on the APA template.

5- Writte 5 to 6 pages ( the cover and recource page not including )

Tags: software security Saudi electronic university CS421 reverseengineering cryptographic data MATE attacks potential security vulnerabilities
_s2.0_s2452414x17301000_main.pdf
_s2.0_s138912861830940x_main.pdf
_s2.0_s0164121218302838_main__1_.pdf
_s2.0_s0167404818310216_main.pdf
.pdf
Unformatted Attachment Preview
Journal of Industrial Information Integration 14 (2019) 34–40 Contents lists available at ScienceDirect Journal of Industrial Information Integration journal homepage: www.elsevier.com/locate/jii A linear classifier based approach for identifying security requirements in open source software development T ⁎ Wentao Wang ,a, Kavya Reddy Mahakalaa, Arushi Guptaa, Nesrin Husseina, Yinglin Wangb a b Department of Electrical Engineering and Computer Science, University of Cincinnati, USA Department of Computer Science and Technology, Shanghai University of Finance and Economics, China A R T I C LE I N FO A B S T R A C T MSC: 00–01 99-00 Just-in-time requirements engineering Security requirements identification Linear classifier Regression model, There are several security requirements identification methods proposed by researchers in up-front requirements engineering (RE). However, in open source software (OSS) projects, developers use lightweight representation and refine requirements frequently by writing comments. They also tend to discuss security aspect in comments by providing code snippets, attachments, and external resource links. Since most security requirements identification methods in up-front RE are based on textual information retrieval techniques, these methods are not suitable for OSS projects or just-in-time RE. In this study, we proposed a linear based approach to identify security requirements. It first uses logistic regression models (RMs) to calculate feature values for requirements in OSS project. Then it uses the linear combination of all feature values to classify security and non-security requirements Our results show that compares to single RMs, our approach can achieve higher recall and precision. 1. Introduction Security refers to a class of non-functional requirements (NFRs) related to system confidentiality, integrity, and availability [1]. It is a fundamental requirement and research direction for the Internet of Things (IoT) [2,3], a key component of Industry 4.0 (I4.0) [4,5]. Experience indicates that thinking about security early in the software life cycle can help address security problems, such as reducing the defect density ratio (that is, number of bugs per thousand lines of code) [6]. Early detection of security requirements enables engineers to incorporate security into the initial architectural design [7]. However, differentiating security requirements from non-security requirements can be nebulous even to the humans, much less the automated detection methods. Additionally, the trend of agile software engineering and Just-In-Time requirements engineering (JIT RE) [8,9] increases the complexity and difficulty of this problem. A considerable number of studies have been done on detecting security requirements [10,11]. However, they are labor intensive. Cleland-Huang et al. [7] proposed NFR-classifier, an automated approach based on information retrieval methods for detecting and classifying NFRs. Mahmoud and Williams [12] proposed another automated approach which exploits the textual semantics of software functional requirements (FRs) to infer potential quality constraints enforced in the system. Their research demonstrated that those methods can achieve high accuracy in traditional or up-front RE. As a precursor to our work, we applied these methods to three open source software (OSS) projects, and the results show that none of them achieve similar performance as in up-front RE projects. Furthermore, the goal of those research is providing general methods for all NFRs, not specific for security requirements. Therefore, security specific semantic information, such as CVE (Common Vulnerabilities and Exposures)1 id are not included in their approaches. Motivated by the above observations this paper, we propose a novel and efficient approach for identifying security requirements in OSS development. In this paper, we have following contributions: (1) building models with metrics related to requirements complexity and eternal resources; and (2) finding an optimal way to integrate all models with NFR-classifier. Our results show that the enhanced approach can achieve average 92.31% recall and 62.94% precision in three OSS projects. The remainder of this paper is organized as follows. Section 2 reviews related work in security requirements identification. In Section 3, we describe the rationale of datasets and metrics selection. Section 4 introduces the linear classifier based approach and Section 5 assesses the performance of our approach. Section 6 concludes the paper and discusses prospects for future work. ⁎ Corresponding author. E-mail addresses: wang2wt@mail.uc.edu (W. Wang), mahakaky@mail.uc.edu (K.R. Mahakala), gupta2ai@mail.uc.edu (A. Gupta), husseinm@mail.uc.edu (N. Hussein), wang.yinglin@shufe.edu.cn (Y. Wang). 1 https://cve.mitre.org https://doi.org/10.1016/j.jii.2018.11.001 Received 11 November 2017; Received in revised form 17 August 2018; Accepted 1 November 2018 Available online 05 November 2018 2452-414X/ © 2018 Elsevier Inc. All rights reserved. Journal of Industrial Information Integration 14 (2019) 34–40 W. Wang et al. 2. Background and related work classifier. Like Gibiec et al. [16] pointed out, term mismatch problem is a common occurrence in software artifacts. Additionally, specific terms contained in requirements which indicate concerns like security and dependability are domain/application dependent [Anonymous,2017]. Therefore, the performance of this approach is lower than other approaches we discussed in the earlier paragraphs of this section (i.e., 70.48% recall and precision level is 67.35%). To the best of our understanding, there is no approach using features related to requirements complexity and external resources to identify security requirements. However, those features are widely applied in other research domains. Such as, software quality prediction [17], software complexity evaluation[18], and vulnerability detection [19]. Intuitively, these features could be used as metrics to train a binary security requirements classifier. Existing researches applied different machine learning algorithms to identify and classify NFRs. In this section, we introduce previous researches based on different machine learning algorithms and their performance on security requirements identification. Cleland-Huang et al. [7] described NFR classifier, an automated method based on the assumption that certain keywords can be used to distinguish different types of NFRs. A set of pre-defined requirements was used to derive different sets of weighted keywords called indicator terms for different NFRs. Indicator terms were then used as queries to retrieve NFRs from various software artifacts. An industrial case study was conducted to evaluate the proposed approach. The result showed that NFR classifier can recall 82.8% security requirements. At the same time, the result also showed a very high ratio of false positive (7.1% precision). The proposed approach benefit from the textual features of requirements, and ignore other requirements features, e.g., stakeholders information and lexical information. We conjecture that contextual and lexical features are complementary with the textual feature on indicating security requirements and thus classifiers build with contextual information may be possible to integrate with NFR classifier and improve the performance of the proposed approach. Unlike NFR classifier which derives indicator terms from a pre-labeled set of requirements, Mahmoud and Williams [12] proposed a method which discovers and assesses the query terms by using un-labeled datasets. The proposed approach first grouped terms of requirements into different clusters based on their semantic similarity. Then average pairwise similarity between clusters and NFR categories (e.g., accessibility, interoperability, and security) were calculated. A cluster was only assigned to the NFR category with highest average pairwise similarity. Requirements then were automatically classified into different NFR categories based on their semantic similarity to the clusters of terms representing individual NFRs. This approach adopts crisp clustering to ensure clearcut results, i.e., one term can belong to one NFR only. However, the same term can indicate different things. For instance, “denial-of-service” is related to both security and availability. Thus, crisp clustering may cause the in-completed set of representative terms. Furthermore, it may harm the performance of NFR identification. Kurtanović and Maalej [13] applied Support Vector Machine (SVM) with 11 different lexical features, such as text length, fractions of nouns and verbs, and sentence syntax tree height to build two classifiers. The binary classifier was used to distinguish functional requirements (FRs) and NFRs. The multi-class NFRs classifier is worked on the result of the binary classifier to identify usability, security, operational and performance NFRs. The proposed approach was applied to two datasets, and results showed that this method can find 90.1% security requirements and filter out most non-security requirements (precision 90.0%). However, unlike datasets used in this research, requirements specifications in OSS projects tend to be organized by functionality, with NFR scattered widely across multiple documents [7]. Therefore, there is no clear boundary between FRs and NFRs. Moreover, the requirements stored in issue tracking systems are unstructured and seldom obey grammar and punctuation rules [14]. Thus, this approach is not suitable for OSS projects. Munaiah et al. [15] proposed a un-supervised approach for detecting security requirements. They trained their One-Class Support Vector Machine with the Common Weakness Enumeration (CWE)2, a formal list of software weakness types intended to serve as the common language for describing software security weaknesses in architecture, design, or code. The assumption authors conjectured is that the language used to describe security requirements and that used to describe weaknesses overlap thus it could be a good candidate to train the 2 3. Datasets and metrics selection The first challenge in building security requirements identification classifier is to find candidate metrics. We manually analyzed three webbased OSS projects, we two types of metrics are suitable to distinguish security requirements from non-security requirements. In this section, we first introduce the three datasets we used to evaluate our approach and then discuss metrics selection. 3.1. Datasets and answer sets In our study, we analyzed the requirements of three OSS projects3: Apache Axis2/Java (Axis2)4, Drools5, and GeoServer6. We selected these projects as the subject systems due to three reasons. First, all of them are successful and long-lived projects. Second, all resources including requirements and source code are available. At last, all three projects are web-based systems and security is one of the core aspects of these projects, so identifying and realizing security requirements are important tasks for developers of these three projects. These projects come from different application domains, and all of them are written in Java. Axis2 is a web services engine funded by Apache Software Foundation since August 2004. The newest version of Axis2 (1.7.4) was released in December 2016. Drools is a business rule management system developed by Red Hat. The latest stable release of Drools is 6.5.0, which was published in December 2016. GeoServer is a geographic system which allows users to edit and share geospatial information. The current stable version 2.11.0 was published in March 2017. Table 1 shows some basic information about these three projects. We manually created the answer sets7 via a two-step analysis. In the first step, two pre-defined sets of security indicator terms were used to retrieve security requirements candidates in each project. One is called the “general indicator terms” [20] which is extracted from [1] and [7]. For another one which is called “project dependent indicator terms”, we manually went through the official websites of three projects, collected all security related artifacts, and then extracted project dependent indicator terms from those security related artifacts. For instance, in Axis2, developers describe their transport framework as “We have a clean and simple abstraction for integrating and using transports (i.e., senders and listeners for SOAP over various protocols such as SMTP, FTP, message-oriented middleware, etc), and the core of the engine is completely transport-independent.”. According to SOAP (simple object access protocol) definition from W3C8, it is security related. Therefore, 3 We share our collected data and analysis results in [20] for validation and replication purpose. 4 http://axis.apache.org/axis2/java/core/ 5 https://www.drools.org 6 http://geoserver.org 7 Our answer sets can also be found in [20]. 8 https://www.w3.org/TR/soap/ https://cwe.mitre.org 35 Journal of Industrial Information Integration 14 (2019) 34–40 W. Wang et al. Table 1 Data collection for the subject projects. Table 4 Statistic analysis for complexity metrics: * indicates significant difference. Project Domain # of issues # of security issues Project Metric Sec. Req.s (mean ± s.d.) Non-Sec. Req.s (mean ± s.d.) p value Axis2 Drools GeoServer Web server Business Geo information 5751 326 8172 109 33 651 Axis2 #C #N #V ALC #S #C #N #V ALC #S #C #N #V ALC #S 4.24 ± 4.67 11.23 ± 8.23 7.52 ± 6.26 33.16 ± 21.37 7.26 ± 3.21 6.23 ± 3.76 10.32 ± 11.73 7.43 ± 7.53 29.73 ± 32.61 6.33 ± 5.31 5.49 ± 7.62 11.33 ± 7.54 5.43 ± 5.29 24.52 ± 28.31 8.21 ± 4.27 3.97 ± 4.93 12.65 ± 9.72 6.71 ± 7.64 15.26 ± 22.69 4.31 ± 4.59 5.44 ± 5.24 9.72 ± 9.27 6.99 ± 6.17 17.29 ± 29.96 4.11 ± 4.23 4.24 ± 6.52 10.58 ± 3.72 6.34 ± 4.23 16.33 ± 23.42 3.62 ± 3.69 0.19 0.13 0.11 0.02 0.04 0.14 0.09 0.07 0.03 0.04 0.11 0.07 0.08 0.03 0.02 Table 2 Security indicator terms. Drools Project Project dependent indicator terms Axis2 Apache rampart, credentials, MEP (message exchange pattern), stack overflow exception, socket, SOAP (simple object access protocol), threadsafe, WS-Security, WS-Addressing ACL (access control list), security-module-admin.properties, security-policy.properties GeoServerSecurityFilterChain, GeoServerSecurityFilterChainProxy, KeyStoreProvider, OAuth2, ResourceAccessManager, SQL Drools GeoServer GeoServer 3.2. Metrics selection In this section, we classify our metrics into two categories: complexity and external resources. For each metric, we not only provide the hypotheses for the discriminative power and the predictability, but also provide the rationale for why these metrics can work for security requirements identification. Complexity: Security experts claim that complexity is the enemy of Table 3 Effectiveness of indicator terms: AS: answer set. Axis2 Drools GeoServer Effectiveness |AS| |Retrieved| Recall Precision 13 4 54 134 14 347 1.00 1.00 0.96 0.10 0.29 0.15 * * * * security [22,23]. Complexity in requirements can lead to complex code which contains subtle vulnerabilities that are difficult to test and diagnose, providing more chances for attackers to exploit [Anonymous, 2016]. From this reason, we set up the following hypothesis on complexity in requirements. HCommentsComplexity: Security requirements in OSS projects involve more discussions than non-security requirements. A requirement containing more comments has a higher chance of having interaction with other issues, leading to more code having input from the external source to modules implemented by other developers without properly understanding the security concerns or assumptions of the modules [19]. We first tested four metrics, including number of comments/requirement (# C), number of nouns in comments/requirement (# N), number of verbs in comments/requirement (# V), and average length of comments/requirements (ALC), by comparing their distribution difference between security and non-security requirements. For each dataset, we chose subsets of security and non-security requirements via simple random sampling (SRS) [24]. Then applied student t-test to test statistic difference between two sets for each metrics. Table 4 shows the testing results. Only ALC has the significant difference between security and non-security requirements. Therefore, only ALC is used to measure comments complexity. HStakeholdersComplexity: Security requirements in OSS projects involve more stakeholders than non-security requirements. We used the number of stakeholders/requirement (# S) to measure the stakeholders’ complexity. Issue tracking system used by three projects (i.e., JIRA) predefined several stakeholders: creators, assignees, comment authors, watchers, and voters. Creators, assignees, and comment authors provide their opinions and refinement of requirements via commenting on requirements. Different people have different opinion and preferences. Therefore, the more stakeholders provide their opinion, the more complicated the requirements are. In addition, human errors are the most frequent type of errors in the requirements [25] . The errors also indicate the high possibility of vulnerability. For watchers and voters, JIRA only shows how many of them, not who are they. That means they may or may not overlap with creators, assignees, and comment authors. If they do not belong to previous three types of stakeholders, that means they do not provide any opinions or refinements. Therefore, we ignore them when we calculate stakeholders complexity. The student t-test results (Table 4) shows that there is a significant difference between security and non-security requirements. External resources: Stakeholders tend to provide external resources, e.g., URLs to documents on other websites, to provide the rationale for their refinement and explain their solutions. After analyzed three OSS projects, we found that three external resources have potential to help to distinguish security and non-security requirements. From our observation, stakeholders add URLs to the requirements we added it into Axis2’s project dependent indicator terms set. Table 2 shows “project dependent indicator terms” for three projects. To evaluate the effectiveness of our indicator terms, we design a pilot study. The research question in this pilot study is “can indicator terms displayed in Table 2 retrieve all security requirements (i.e., achieve 100% recall)?”. First, from each dataset, we randomly choose 10% requirements and ask an analyst who has 1 year research experience on both these three projects and security to manually go through all of selected requirements and classify them into security or non-security requirements. After this step A keywords searching is then applied to the selected requirements. That is, if a requirement contains at least one indicator term, we mark it as security requirements. The searching results are showed in Table 3. Indicator terms can find 100%, 100%, and 96.30% security requirements. Two GeoServer security requirements that do not retrieved by the keywords searching shared words “SQL”. Therefore we add it to Table 2 as a new indicator for GeoServer project (red part). Results of pilot study demonstrated that keywords searching can retrieve all security requirements, we therefore apply it to help us to reduce manual effort. In the second step, two analysts classified all candidates as security or non-security requirements independently. If two analysts have the same decision on one issue, we mark it as security/non-security requirement directly. Otherwise, two analysts have a discussion and make the final decision together. A …
Purchase answer to see full attachment