DLR as research organization increasingly faces the task to share its self-developed software with partners or publish openly. Hence, it is very important to harden the softwares to avoid opening attack vectors. Especially since DLR software is typically not developed by software engineering or security experts. In this paper we describe the data-oriented approach of our new found secure software engineering group to improve the software development process towards more secure software. Therefore, we have a look at the automated security evaluation of software as well as the possibilities to capture information about the development process. Our aim is to use our information sources to improve software development processes to produce high quality secure software

Haupt, Carina

Krishnamurthy, Rohan

Meinel, Michael

Mäder, Patrick

Schreiber, Andreas

Institute of Transport Research:Publications

DLR Secure Software EngineeringPosition and Vision PaperRohan KrishnamurthyGerman Aerospace Center (DLR)Jena, Germanyrohan.krishnamurthy@dlr.deMichael MeinelGerman Aerospace Center (DLR)Berlin, Germanymichael.meinel@dlr.deCarina HauptGerman Aerospace Center (DLR)Berlin, Germanycarina.haupt@dlr.deAndreas SchreiberGerman Aerospace Center (DLR)Cologne, Germanyandreas.schreiber@dlr.dePatrick MäderTechnical University IlmenauIlmenau, Germanypatrick.maeder@tu-ilmenau.deABSTRACTDLR as research organization increasingly faces the task to shareits self-developed software with partners or publish openly. Hence,it is very important to harden the softwares to avoid opening attackvectors. Especially since DLR software is typically not developedby software engineering or security experts. In this paper we de-scribe the data-oriented approach of our new found secure softwareengineering group to improve the software development processtowards more secure software. Therefore, we have a look at the au-tomated security evaluation of software as well as the possibilitiesto capture information about the development process. Our aim isto use our information sources to improve software developmentprocesses to produce high quality secure software.CCS CONCEPTS• Security and privacy→ Software security engineering; Sys-tems security; • Software and its engineering→ Software devel-opment process management;KEYWORDSdata science, it security, secure software engineering, code analysis,provenanceACM Reference Format:Rohan Krishnamurthy, Michael Meinel, Carina Haupt, Andreas Schreiber,and Patrick Mäder. 2018. DLR Secure Software Engineering : Position andVision Paper. In Proceedings of First International Workshop on SecurityAwareness from Design to Deployment (SEAD’18). ACM, New York, NY, USA,Article 4, 2 pages. https://doi.org/10.1145/nnnnnnn.nnnnnnn1 INTRODUCTIONSoftware engineering has been a conventional methodology that isfollowed for the development of software. It is still not well adoptedPermission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for components of this work owned by others than theauthor(s) must be honored. Abstracting with credit is permitted. To copy otherwise, orrepublish, to post on servers or to redistribute to lists, requires prior specific permissionand/or a fee. Request permissions from permissions@acm.org.SEAD’18, May 2018, Gothenburg, Sweden© 2018 Copyright held by the owner/author(s). Publication rights licensed to Associa-tion for Computing Machinery.ACM ISBN 978-x-xxxx-xxxx-x/YY/MM. . . $15.00https://doi.org/10.1145/nnnnnnn.nnnnnnnby the scientific community so far. On top of that the topic of securesoftware is emerging without being handled appropriately.Driven by the reproducible science paradigm and ever grow-ing research networks, scientific software is made available to abroader range of users. Despite an alarming amount of vulnera-bilities has been made public over the last years, software is stillshared without being hardened with respect to security issues. Thusscientific software might introduce attack vectors to target researchinstitutes.Our goal is to come up with a collection of guidelines and toolsto apply during development to create secure software withoutin-depth knowledge of software security.At DLR we have access to a range of software repositories1 aswell as many ongoing research projects where software is devel-oped.In this paper we want to outline our research as follows:• We characterize software development at DLR to illustratethe context of our research (Sect. 2).• We describe the need to address the security issues in DLRwith better insight into secure software engineering basedon data analysis (Sect. 3).• We present our strategies to analyze software developmentprocesses and to create a catalog with tools and guidelinesthat supports secure software development (Sect. 4).2 SOFTWARE DEVELOPMENT AT DLRThe German Aerospace Center (DLR) is one of the largest researchorganizations in Germany. Over 8000 scientists are researching inthe fields of aeronautics, space, transportation and energy. In thesefields many tasks rely on computer systems. This involves individ-ual software developed by domain experts in multiple programminglanguages across different platforms.More than 2000 people at DLR are occupied with software devel-opment in part-time or full-time [1]. Most of the developers haveno training in software development, only very few have deeperknowledge about systematic development of sustainable software,the means of software engineering, or secure software. Typical1This includes but is not limited to version control systems as well as issue trackersand continuous integration systems.SEAD’18, May 2018, Gothenburg, Sweden R. Krishnamurthy et al.development team sizes range from one up to 20 persons, in aver-age being one scientist supported by interns and perhaps a Ph.D.student.The combination of being domain scientists and small team sizesmakes the amount of needed knowledge about software engineeringand security a disproportional overhead for a project.3 SOFTWARE SECURITY IN DLRAs DLR is well known for its expertise we have lots of cooper-ations with partners all over the world. Also the importance ofreproducible results has an increasing necessity to publish not onlythe data but also the software used to produce the results [2]. Con-sequently our software needs to be shared with many differentpeers.Sharing of software might open up security risks. As long as thesoftware, input data, and the execution environment is under controlof a single entity, security concerns are a minor issue. However assoon as one of these three factors gets externalized, security issuesneed to be considered. In many of our cases public interfaces tosoftware are only added after the software is already in productiveuse. Known security issues are only handled in the added interfacesand not in the software itself. Examples for issues we already facedare: Missing validation of external datasets, information leaks overhidden channels, and outdated dependencies.Unexperienced developers at DLR have seen the deploymentof software in the cloud as a solution to decouple the executionof vulnerable code from internal resources. But this is not a se-curity advantage. Hidden channels might be opened to internalDLR resources that are available to the cloud-hosted code. Leakageof information and data that was meant for internal use by thesoftware is also a possible risk.The lack of IT (security) experts leads to such problems. As aresult internal software life cycles do not pay attention to basicactivities like security updates of frameworks and libraries.4 TOWARDS SECURE SOFTWAREDEVELOPMENTOur focus is on improving processes and tools. We want to createa catalog with tools and guidelines that support secure softwaredevelopment. To accomplish this goal we apply methods from datascience to analyze software development processes and the result-ing software. As data we use the software projects of DLR.Our strategy consists of the following steps:(1) We select a number of projects with well-defined softwareengineering processes. Our position within the DLR givesus access to more than 300 projects on different versioncontrol systems and about 120 projects in issue trackersthat can be mined for information. We want to record theactual processes that are carried out and compare them tothe defines processes to identify deviations. To record theprocesses methods and technologies like repository mining,key loggers, IDE extensions and conducting surveys exist.Due to the privacy implications we refuse to use the keylogger approach.While IDE extensions are our preferred wayto capture provenance data, the variety of used IDEs at DLR,results is a high implementation overhead for a first approach.Hence in our first step we rely on the documented processand incorporate easy to adapt techniques like surveys andrepository mining to augment this data.(2) We monitor the quality of the software using manual andautomated audits. Therefore we investigate and improveexisting static and dynamic security analysis methods. Thedynamic analysis provides the most universal and versatileway of automated security auditing, however they are mostlyvery time consuming and produce rather vague results incontrast to the static analysis approach. The static analysiscan be evaluated based on manual audits, syntax tree analy-sis, and intermediate language analysis. We will focus on thelatter-most analysis approach as the existing vulnerabilitiesfrom databases like CVE2 or the exploitation frameworkscan be transferred into intermediate language. These thencan be used as examples for vulnerable or exploitable code.(3) We conduct experiments to identify process properties thathave an effect on the security of the resulting software. Fac-tors such as security-focused requirements engineering or aspecial security testing phase promise a high impact. How-ever we also want to experiment with other approaches suchas threat modeling and special trainings for developers. Toallow comparison of software quality across projects, weintroduce a software security scoring system based on auto-mated software analysis.5 CONCLUSIONIn order to improve software development processes we started anew research group. Our aim is to optimize process properties usingapproaches from data science. We include two main sources of data:the provenance of software processes and a score for the softwaresecurity of that artifact.We presented some strategies for collecting both of them:• We plan to use repository mining as a source for processinformation. This should also help to identify missing infor-mation that needs to be recorded with another approach• To augment the mined data, we plan to introduce developersurveys. In a later step we also plan to implement processrecording extensions for IDEs.• We plan to derive a common security scoring system basedon existing dynamic and static analysis techniques.• We develop a new data driven static analysis approach basedon the intermediate language representation of source code.We will apply these approaches in real projects in the environ-ment of DLR, which gives us large datasets that can be used toimprove results.REFERENCES[1] Carina Haupt and Tobias Schlauch. 2017. The Software Engineering Communityat DLR: How we got where we are, Neil Chue Hong, Stephan Druskat, RobertHaines, Caroline Jay, Daniel S. Katz, and Shoaib Sufi (Eds.). Proceedings of theWorkshop on Sustainable Software for Science: Practice and Experiences (WSSSPE5.1).http://elib.dlr.de/114050/[2] Victoria Stodden and Sheila Miguez. 2014. Best Practices for ComputationalScience: Software Infrastructure and Environments for Reproducible and Ex-tensible Research. Journal of Open Research Software 2, 1 (jul 2014). https://doi.org/10.5334/jors.ay2https://cve.mitre.org/

DLR Secure Software Engineering - Position and Vision Paper

https://elib.dlr.de/119869/1/dlr-secure-software.pdf

DLR Secure Software Engineering - Position and Vision Paper

Abstract

Similar works

Full text

Available Versions

Institute of Transport Research:Publications