An Approach to Secure Legacy Software Systems

Stefanie Jasser

1,2

and Jonas Kelbert

Department of Informatics, University of Hamburg, Hamburg, Germany

akquinet AG, Hamburg, Germany

Keywords:

Software Security, Code Cleansing, Security Refactoring, Vulnerability Mitigation, Flaw Prioritization.

Abstract:

When analyzing legacy software for security huge result lists may be generated. These lists may contain more

than 1,000,000 potential vulnerabilities. In this paper, we propose an approach to secure such legacy systems:

we deﬁne a process to systematically assess and process potential vulnerabilities using contextual system

knowledge. The process is complemented with tool-supported technical measures to actually mitigate the

vulnerabilities and code injection. The approach allows to efﬁciently repair vulnerabilities in legacy systems

while ensuring system availability for critical systems using a safe go-live technique. We evaluate our approach

by an industrial case study to show the applicability and ﬂexibility of our code security cleansing approach.

1 INTRODUCTION

Developing a secure software system is a challeng-

ing task. Like for other quality attributes, achieving

security in large software systems is determined by

the software architecture: Usually, code level vulner-

abilities are easier to remedy and less crucial to a sys-

tem’s security than its architectural security measures.

Several tools exist for analyzing security on the code-

level. Some work also deals with architecture level

vulnerabilities (Jasser, 2019; McGraw, 2006).

However, for legacy systems security analysis

tools on both, the architectural and the code level, of-

ten provide huge lists of potential vulnerabilities, e. g.

about 800,000 in our case study. Few work exists on

systematically ﬁxing vulnerabilities from such analy-

sis results, e. g. taking the effect on the system’s over-

all risks into account when determining measures.

Existing approaches lack consideration of the system

and vulnerability context. Instead, software vulner-

abilities are often remedied non systematically and

sub-optimally for their speciﬁc context. Based on

this, we identiﬁed three issues in existing approaches

for vulnerability mitigation in legacy systems:

RQ 1: How Can Organizations Deal with

Large Quantities of Analysis Results? Processing

huge vulnerability lists causes an enormous effort:

Not all vulnerabilities can be mitigated. To deal with

large quantities of vulnerabilities, organizations need

a systematic process to reduce the risks with reason-

able effort. In this paper, we provide a methodology

that deﬁnes a systematic process on assessing, priori-

tizing and mitigating vulnerabilities (see Section 2).

RQ 2: How Can Vulnerabilities Be Fixed Sys-

tematically? Mostly, there several mitigation strate-

gies can be used to ﬁx a vulnerability. Choosing the

best option for security and cost-beneﬁt reasons is dif-

ﬁcult. In Section 2 we present our funnel approach

that supports project teams in narrowing vulnerability

lists based on ﬁxing strategies.

RQ 3: How to Ensure System Availability Dur-

ing Mitigation? Fixing vulnerabilities in legacy sys-

tems is a complex task: unlike refactoring, ﬁxing

vulnerabilities changes the system behavior, i. e. the

modiﬁcations may also change the functionality. The

mitigation must therefore be tested before applying

them on the live system. Introducing an additional

logging phase provides further reliability. This way,

an organization can take appropriate measures to en-

sure the system availability before putting a mitiga-

tion into productive operations. For safe go-live we

use our soft cleansing approach (s. Section 3).

To address these issues, we provide a systematic

and practicable approach to deal with large lists of

potential vulnerabilities in legacy systems. This ap-

proach is a framework for individual adaptation.

2 CLEANSING APPROACH

Our approach bases on provided vulnerability analy-

sis results. It deﬁnes a systematic and safe way of

Jasser, S. and Kelbert, J.

An Approach to Secure Legacy Software Systems.

DOI: 10.5220/0008902802990309

In Proceedings of the 6th International Conference on Information Systems Security and Privacy (ICISSP 2020), pages 299-309

ISBN: 978-989-758-399-5; ISSN: 2184-4356

299

mitigating huge lists of potential vulnerabilities. The

approach may be used with vulnerability lists from

different sources, i. e. it is not limited to a speciﬁc

security analysis approach.

In the following Section, we list the requirements,

we found prior to the conceptual design of our cleans-

ing approach. Based on these requirements, we de-

signed an approach for ﬁxing software vulnerabili-

ties. The concept comprises two aspects of a secu-

rity cleansing: ﬁrst, a systematic process and, second,

adequate technological and tool support.

2.1 Requirements for a Mitigation

Process Approach

For our cleansing approaches we found the following

requirements prior to the conceptual design:

Req 1: Respect Individual Security Requirements.

Different enterprises have different security guide-

lines and requirements. They even differ between

software projects. The approach should respect and

respond to these varying security requirements.

Req 2: Minimize (Manual) Code Changes. Code

modiﬁcations often have unexpected impact on a soft-

ware system. To minimize side effects, our approach

should prefer solutions that avoid code modiﬁca-

tions.For vulnerabilities that need to be ﬁxed through

code modiﬁcations, the modiﬁcations should be done

tool-supported if possible.

Req 3: Safe Go-live (Availability of Operational

Environment). Mitigating changes may reduce the

availability of a system: even correctly implemented

changes usually restrict the accessed functionality.

Users may not be able to use functionality they used

prior to the mitigation. The approach must provide a

mechanism to avoid such availability limitations.

Req 4: Optimize Effort-beneﬁt-ratio. To be feasi-

ble, the cleansing approach must have a reasonable

effort-beneﬁt-ratio. The workload has to be deﬁned

based on a systematic prioritization of the overall total

vulnerability list. Additionally, the approach should

automate as many solutions as possible.

Req 5: Context-sensitive Assessment of Vulnera-

bilities. Vulnerabilities exist within a software sys-

tem. The context is essential for choosing a good re-

pair solution. The vulnerability assessment must con-

sider this context of a vulnerability and the system.

Req 6: Meet Individual Quality Alignments. Be-

yond individual security requirements, enterprises

follow different quality and coding guidelines. Al-

though, the approach should be automated where pos-

sible, it must meet these quality requirements.

Req 7: Flexibility Regarding Enterprise Processes

and Heartbeat. Cleansing projects take place within

a company’s heartbeat: we need a ﬂexible approach

that ﬁt’s into company’s processes and schedules.

Req 8: Auditability of Process and Documenta-

tion. Software security cleansing is required for

the overall compliance and security of companies.

Hence, the process, decisions made and all documents

must be audit compliant including appropriate docu-

mentation.

2.2 The Process

Our approach leads to a systematic handling of huge

vulnerability lists. It aims to minimize code level mit-

igation when reducing a system’s security risks. To

achieve this, we a) identify false positives and vulner-

abilities that only cause minor risks, b) do as much

mitigation beyond code level as possible and c) min-

imize manual solutions, if code-level ﬁxing is neces-

sary. This funnel approach is presented in Figure 2.

Figure 1 shows the project method we suggest.

Step 1: Project Initialisation and Cleansing

Preparation

A code cleansing project starts with a workshop to de-

ﬁne the scope of the project: the workshop includes

sessions on speciﬁc protection objectives, a selection

of security rules to check and the speciﬁcation of an

individually acceptable risk level. Through this work-

shop we meet requirement no 1. Based on the rules in

scope, the contextual knowledge needed can be spec-

iﬁed. The contextual knowledge on the software sys-

tem is used to select the solution type for each vulner-

ability. It may be necessary to collect these data ﬁrst,

if this has not been done prior to the project.

In parallel, the tools to support mitigation should

be installed. Furthermore, the presentation of the

cleansing method to responsible persons and neces-

sary approvals should be obtained in the meantime.

Step 2: Unused Code Decommissioning

The steps 2, 3 and 4 are interchangeable: their order

can be changed or they can be executed in parallel, if

the usage data on a system are available prior to the

project. Otherwise, they have been collected in Step

1 as a part of the context data.

Unused code objects and fragments have not been

used on the live system within a certain period of time.

This may usually be 6 or 13 month. We use this usage

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

300

Figure 1: Project method.

Figure 2: The funnel approach to minimize (manual) code modiﬁcations.

statistics to get rid of inactive code and it’s vulner-

abilities Besided mitigation of its vulnerabilities, we

do not need to put maintenance effort into this code

any more. However, most developers resist to actually

delete code in the ﬁrst step: We use an easy to reverse

decommissioning approach. The decommissioning is

done by code injection and control mechanisms that

allow to deactivate the mitigation logic without fur-

ther code changes (see Section 2.3).

Step 3: Technical-organizational Mitigation

Changing source code is risky, inter alia, due to unpre-

dictable impacts on the system. We reduce the num-

ber and impact of code modiﬁcations due to their fault

proneness: Concerning vulnerabilities in active code,

we prefer technical or organizational measures that

supersede code modiﬁcations. For instance, many

frameworks provide functionality to limit the paths

a user may access from an application and, thereby,

reduce the risk of directory traversal attacks. Be-

fore making potentially unnecessary code modiﬁca-

tions, appropriate conﬁguration and customization of

the system and its building blocks should be ensured.

It depends on the software system’s context,

which technical or organizational measures can be ap-

plied. For instance, this is affected by the technolo-

gies used and the project’s basic conditions.

Step 4: Mitigation through Code Modiﬁcations

To invest no unnecessary effort in code modiﬁcations,

we ﬁrst conduct an analysis of the ﬁndings in scope to

identify false positives and ﬁndings that do not need

to be mitigated due to low risk.

Although we try to avoid code modiﬁcations, they

are necessary sometimes: in these cases, we intend

to automate the code modiﬁcations. Each vulnerabil-

ity may be caused by multiple code patterns. We use

the patterns to identify the code fragments to mod-

An Approach to Secure Legacy Software Systems

301

i f ( c u r r e n t U s e r

== ” j d o e ” ){

doSo me th in g ( ) ;

}

s w i t c h ( c u r r e n t U s e r ) {

c a s e ” j d o e ” :

c a s e ” jm o d a al ” :

c a s e ” zs a n ” :

do So me ht in g ( ) ;

break ;

d e f a u l t :

break ;

}

Figure 3: Two exemplary vulnerability pattern for hard-

coded username checks.

t r y {

A c c e s s C o n t r o l l e r . c h e c k P e r m i s s i o n (

c u r r e n t U s e r ,

new P e r m i s s i o n (

” s o me F u nc t i on ” ,

” a c c e s s ” ) ) ;

do So me th in g ( ) ;

} c a tc h ( A c c e s s C o n t r o l E x c e p t i o n e ) {

throw A c c e s s D e n i e d E x c e p t i o n (

” S u b j e c t h as no a c c e s s ” ) ;

}

Figure 4: Mitigating code modiﬁcations for both examples.

ify. Based on the vulnerability type and the identiﬁed

code pattern, the necessary actions are determined,

e. g. code injections or the creation of table entries.

Figure 3 shows two exemplary code patterns of

hard-coded username checks: an if and a switch

case example that check the current username against

hard-coded values. The result inﬂuences the control

ﬂow and, thereby, the system behavior. In this exam-

ple, the code would be modiﬁed as showed in Figure

4: the hard-coded username checks would be replaced

by checking the user’s authorization. The hard-coded

users must be granted the permissions.

If a vulnerability’s code pattern can be mitigated

using well-deﬁned actions, these actions can be done

with tool-support. However, the mitigation should not

be done in batch mode but with a control mechanism:

each modiﬁcation should be checked by a developer.

Thus, the mitigation is more efﬁcient and less fault-

prone, because the developer does not need to change

the code manually. Hence, the developer will mitigate

more ﬁndings per day in this semi-automated mode

as in a completely manual mode. Additionally, the

solutions will probably cause less faults.

Some vulnerabilities have to be mitigated manu-

ally due to their complexity or severity: such vulner-

abilities can only be ﬁxed by changing the fundamen-

tal logic of the program. For instance, this is the case

if code is uploaded and executed dynamically. Such

functionality often exists to repair incoming data dur-

ing run-time. However, an attacker may use this func-

tionality, to upload and execute malicious code.

Step 5: Safe Go-live

Applying the safe go-live approach to the cleansing

project is optional. We recommend it for software

systems that require high availability.

The approach makes the go-live safe by setting the

mitigation live gradually: It adds one transition phase

at the least. During this transition phase, the previ-

ous and the new mitigation logic are executed. If the

results diverge, this divergence is logged using an au-

ditable log. As the mitigation will usually narrow the

access to or generality of a functionality, most diver-

gences are about a user who could access a function-

ality prior to the mitigation and cannot access it any

more using the new logic. Finally, the original logic

is executed that applied prior to the mitigation.

Dependent on the vulnerability or chosen solu-

tion, there may be additional transition phases im-

plemented. The safe go-live approach is described in

more detail in Section 3.

Step 6: Project Completion

To complete the project, the documentation must be

ﬁnalized in an auditable way. Ideally, all major steps

and decisions have been aligned with the auditor di-

rectly throughout the project.

Partly, the auditable documentation has been cre-

ated throughout the project such as logs during the

transition phase or the methods and techniques used

for mitigation. However, the ﬁnal result must be doc-

umented and presented at the project end. This in-

cludes assessing the remaining risks that have been

accepted due to effort-beneﬁt ratio.

Beyond auditable documentation, measures for

staying clean must be deﬁned: these may be technical

as well as organizational measures. Usually, the mea-

sures include a security awareness and secure code

training and an adapted software development pro-

cess. The process stipulates frequent tool-based se-

curity analysis or secure code reviews.

2.3 Tool-supported Mitigation

The tool we developed intends to support and partially

automate the mitigation of vulnerabilities. It is in-

tended to be used by developers.

2.3.1 Guided Code Vulnerability Mitigation

Recurring vulnerability patterns are often remedied

with identical solutions. We developed a tool that uses

code injection techniques to repair such vulnerabili-

ties. For tool-supported ﬁxing, there are pre-deﬁned

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

302

vulnerability patterns. Unknown vulnerability pat-

terns cannot be ﬁxed using the tool. This applies to

unknown variants of known vulnerabilities, too. If the

tool ﬁnds a known vulnerability pattern near to the

line in code at which the vulnerability occurs, it se-

lects the assigned solution for mitigation. The tool re-

pairs the vulnerability by code injection. Usually, the

code injection is not done in a batch but in a guided

mode: In the guided mode, the workload is processed

step by step. An editor shows the suggested solution

that would be applied. If the tool inserts or modiﬁes

table entries, this is displayed, too. For instance, ta-

ble entries are inserted into the safe go-live control

tables, if the safe go-live approach is used. The devel-

oper may accept, reject and skip or manually modify

a solution. The safe go-live approach should be used

for all code injections by the tool.

All modiﬁcations that are made by the tool have to

be logged in an auditable way: not only the original

and the modiﬁed code but also the executing user is

logged. Additionally, every manual adaptation of the

suggested solution is logged.

2.3.2 Unused Code Decommissioning

Unused code usually contains as many vulnerabili-

ties as used code. By decommissioning unused code,

these vulnerabilities are remedied with little effort.

Decommissioning is done by injecting code into the

inactive code objects or fragments and creating con-

trol table entries on the database. The table entries de-

termine the ﬁxing status, the message to be shown and

the mitigation code’s actual behavior for each miti-

gated vulnerability. It is used to apply the safe go-live

approach. These information are queried by the in-

jected code. E. g., the ﬁxing status may be ”logging”.

In this case, the previous and the modiﬁed logic are

executed on trial. If the results differ, the difference is

logged. However, the previous logic is actually exe-

cuted in the end.

Beyond mitigating the vulnerabilities in unused

code, the decommissioning improves the system’s

maintainability and portability. This is due to the code

must no longer be considered during maintenance or

porting.

3 SAFE GO-LIVE: SOFT

CLEANSING

Availability is an essential requirement for many soft-

ware systems. There are several ways to unintention-

ally limit the availability through the cleansing ac-

tivities: Code modiﬁcations have the inherent risk

to cause faults in the system. This may be due

to wrongly implemented security ﬁxes and modiﬁed

functionality or due to unexpected impacts on the sys-

tem. Yet, correct modiﬁcations may limit the avail-

ability, too: For instance, in case of a missing autho-

rization check, the straightforward ﬁx is the introduc-

tion of a reasonable authorization check. This prob-

ably limits the availability as users may not be able

to access the functionality any more. However, some

of these users may be justiﬁed to access the function-

ality. Such users may not have the permissions be-

cause the missing permissions did never attract atten-

tion due to the lack of authorization checks.

For software systems that are required to be highly

available we developed a safe go live approach for

our cleansing projects: the soft cleansing approach.

The soft cleansing approach puts the mitigating code

changes into productive operations step-by-step.

As Figure 5 shows, the mitigating code is imple-

mented in the ﬁrst step. The code is extended with

a control logic that enables the gradual go-live. The

implementation may be done using automated code

injection or by hand. Referring to the example pre-

sented in Figure 4, the code would be extended as

in Figure 6: The control logic queries the underly-

ing control tables that hold the soft cleansing sta-

tus. If the cleansing is in transition phase, the in-

jected authorization check is performed. If the ac-

cess is denied, the program executes the prior logic

indicated by doSomething() and logs the discrep-

ancy between prior and mitigation logic. The opposite

case – a user had no access before mitigation and can

now access the functionality – can not happen as we

had a missing authority check before. When the mit-

igation is set live ﬁnally (cleansing status ACTIVE),

the new logic actually refuses access and throws an

AccessDeniedException.

Soft cleansing is optional. If it is applied to a

project depends on the trade-off decisions regarding

availability and other protection goals.

4 FIELD STUDY

4.1 Initial Situation

We conducted our evaluation project with an indus-

trial partner in the technology sector. The project was

part of a security initiative. Initially, our industrial

partner conducted a vulnerability analysis on their

software systems. The analysis resulted in more than

800,000 ﬁndings, i. e. potential vulnerabilities. Find-

ings may be architecture-level or code-level vulner-

abilities. Analogously to security architecture viola-

An Approach to Secure Legacy Software Systems

303

Figure 5: Safe go-live process.

1 Long f i x I d = 1 2 ;

2 C l e a n s i n g S t a t u s s t a t u s = A c c e s s M i t i g a t i o n C o n t r o l l e r

3 . g e t F i x I n f o r m a t i o n ( f i x I d )

4 . g e t C l e a n s i n g S t a t u s ( ) ;

5 I L o g D e t a i l l o g I n f o = new M i t i g a t i o n L o g D e t a i l ( f i x I d ) ;

6 bo o lea n p e r f o r m L o g i c = f a l s e ;

7 t r y {

8 A c c e s s C o n t r o l l e r . c h e c k P e r m i s s i o n ( c u r r e n t U s e r ,

9 new P e r m i s s i o n ( ” so m e F un c t i on ” ,

10 ” a c c e s s ” ) ) ;

11 pe r f or m L o g i c = t r u e ;

12 } c a t ch ( A c c e s s C o n t r o l E x c e p t i o n e ) {

13 i f ( s t a t u s == C l e a n s i n g S t a t u s . ACTIVE) {

14 thro w A c c e s s D e n i e d E x c e p t i o n (

15 ” S u b j e c t h a s no a c c e s s ” ) ;

16 } e l s e {

17 p e r f o r m L o g i c = t r u e ;

18 l o g I n f o . s e t M i t i g a t i o n L o g i c R e s u l t ( e ) ;

19 }

20 } f i n a l l y {

21 i f ( p e r f o r m L o g i c ) {

22 d oSom e t hin g ( ) ;

23 }

24 i f ( l o g I n f o . c o n t a i n s D i v e r g e n c i e s ( )

25 && s t a t u s != C l e a n s i n g S t a t u s . NO LOGGING) {

26 l o g g e r . l o g A c c e s s D e c l i n e d ( l o g I n f o ) ;

27 }

28 }

Figure 6: Mitigating code modiﬁcations including soft

cleansing logic.

tions, ﬁndings indicate vulnerabilities but may also be

false positives. The partner estimated that an experi-

enced software engineer may ﬁx 4 vulnerabilities per

hour at average. This results in an overall effort of

about 25,000 man-days.

Our industrial partner aimed to minimize cyber se-

curity risk. To achieve this goal, we applied our code

security cleansing approach to the system. Due to

company guidelines, we had to ﬁt our approach in an

agile project method that was similar to SCRUM.

4.2 Prototype

We implemented a prototype to apply our approach

to the industrial project. Its essential part is the semi-

automatic vulnerabiltiy ﬁxing that is realized through

a ﬁxing wizard: besides other information, it proposes

a solution by code injection that is highlighted in the

editor. The developer is responsible for reviewing the

solution. If the developer assesses the solution inap-

propriate, he can either edit it or skip the vulnerabil-

ity . Every modiﬁcation is logged auditably: i. e. The

logs are protected from modiﬁcation or data loss and

are in a readable and machinable format.

As the executing user of the tool takes responsi-

bility and it needs software and security engineering

knowledge to assess the proposed solutions, the user

should always be a software developer. The devel-

oper must have security knowledge to enable well-

grounded assessment.

4.3 Applying the Cleansing Approach

We applied the cleansing approach to our partner’s

most important software system. It controls crucial

production lines. At the beginning, we had about

800,000 potential vulnerabilities, which resulted from

a tool-supported code security analysis. The ﬁrst step

in coping with this huge task list is to deﬁne the poten-

tial vulnerabilities to be considered in the project: We

held a workshop to deﬁne the project scope, i. e. to

prioritize and determine the subset of ﬁndings to ﬁx.

Since the concerned software system controls produc-

tion lines, high availability is mission critical. Hence,

availability is the most important protection objective

to achieve. However, the considered software sys-

tem contains sensitive information such as informa-

tion on products, innovations and internal processes

of the technology company. The conﬁdentiality of

these sensitive information’s must be protected. This

is the second most important protection objective as

agreed in the workshop.

Based on the protection goal priorities, we as-

sessed the vulnerability types from the analysis tool’s

documentation: e. g., the upload and execution of

code fragments may have an enormous negative im-

pact on the system’s availability and conﬁdentiality.

Hence, this vulnerability type is assessed highly criti-

cal. Other vulnerabilities may have write or only read

access, such as SQL injection vulnerabilities. Usu-

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

304

ally, we evaluate write access more critical than read

access. To further narrow the scope we only consider

ﬁndings that are likely to have an adverse effect on

the software system. This assessment is done by the

analyzing tool based on different parameters such as

if the vulnerability can be affected by user input.

In parallel, we gathered usage data from the live

systems to identify unused code objects. Through de-

commissioning of unused code we mitigated about

70 % of all ﬁndings (ca. 570,000 ﬁndings).

We split the remaining list of potential vulnerabil-

ities based on their ﬁxing strategies, i. e. if they may

be ﬁxed by technical-organizational measures beyond

code and within the source code. For instance, there

were existing mechanisms to restrict the access of un-

derlying system paths via authorizations. The system

automatically checks these authorizations for every

system path access. To mitigate directory traversal

vulnerabilities, we redesigned and customized the au-

thorization concept considering this aspect in collab-

oration with our industrial partner.

Subsequently, the developers analyzed all ﬁndings

that were not ﬁxed before. They all had knowledge

and experience in software security. All potential

vulnerabilities were assessed regarding their damage

potential: they identiﬁed false positives and ﬁndings

with minor risk. The remaining vulnerabilities were

critical and must be mitigated by code modiﬁcations.

Most code-level mitigation was done automati-

cally: using the guided mode described above the tool

proposes a solution to the developer. The developer

reviewed the solution before it is ﬁnally applied. The

tool logs each code injection in an auditable way. In

our project the proposed solutions have rarely been

modiﬁed but have mostly been injected as proposed.

However, we had some vulnerabilities that had to be

mitigated individually. Mostly, these vulnerabilities

or their context are complex. Therefore, the logic has

to be rebuilt in a secure way to ﬁx such vulnerabilities.

Concluding, we conducted code security reviews

on all manual mitigations. Vulnerabilities that have

been ﬁxed by injecting a default solution or that have

been decommissioned are reviewed at random. Our

partner did the functional test.

We discussed the process and decisions with the

auditor throughout the project to obtain their ap-

proval. Due to their consent, the project and system

successfully passed the subsequent audit. On demand

of the auditor we deﬁned an overall risk metric that is

calculated from the vulnerabilities’ criticality and the

probability of exploiting them: We deﬁned the crit-

icality of the vulnerability types in relation to each

other while the analysis tool provides an estimation if

it is very likely, less likely or unlikely that a vulnera-

bility may be exploited. We translated this estimation

into a factor that is multiplied with the criticality value

per ﬁnding. To calculate the system’s risk level and

it’s relative changes over time, we added all ﬁnding

values within the system. Thus, we were able to show

the mitigation effect that our project had on the sys-

tem. The metric was deﬁned in a joint workshop with

representatives of the project team, the risk manage-

ment, the information security ofﬁcer, the software

development department and the auditor.

4.4 Measures to Stay Clean

We trained a selected group of developers in code

vulnerabilities and their mitigation in legacy sys-

tems. These developers build multipliers of knowl-

edge within the company: they transfer the knowl-

edge they gained to the whole development team.

Additionally, we introduced technical measures:

before functional testing the code is checked for po-

tential vulnerabilities using the analysis tool. There

must not be any ﬁndings that match the project scope

deﬁnition. Such ﬁndings must be mitigated before

functional testing and release of the functionality.

5 DISCUSSION

Based on the application of our approach to an indus-

trial case, we discuss the beneﬁts and potential im-

provements of our approach in the following. First,

we discuss if our approach meets the requirements we

speciﬁed for it (see Section 2.1). Subsequently, the is-

sues mentioned in the introduction are discussed.

5.1 Field Study Results

Respect Individual Security Requirements (Req

1). Our approach stipulates an introductory work-

shop. An essential part of this workshop is the scope

deﬁnition: in our ﬁeld study, we prioritized the com-

pany’s individual protection goals. Based on that, we

evaluated the criticality of the identiﬁed vulnerabil-

ity types. The mitigation scope can be narrowed or

broadened dependent on the stakeholder’s needs. An-

other tailored measure is the safe go-live option: The

team may apply it to the project if availability is im-

portant or may skip it if an immediate mitigation of

vulnerabilities is required instead. By the individual

prioritization and scope deﬁnition, the approach ex-

actly considers the individual security requirements.

Minimize (Manual) Code Changes (Req 2). Our

approach aims to mitigate as many vulnerabilities as

An Approach to Secure Legacy Software Systems

305

possible beyond code: in our ﬁeld study, we could

mitigate more than 75 % of the overall vulnerabil-

ities and more than 90 % of the vulnerabilities in

scope by decommissioning unused code, technical-

organizational measures and tool-supported mitiga-

tion through code injection. In numbers, this means

more than 10,000 critical vulnerabilities in scope and

about 605,000 vulnerabilities overall have been ﬁxed

without manual code modiﬁcations. Despite these re-

sults are excellent, they are highly dependent on the

concrete system. However, we expect a major effects

of these steps in most legacy systems. Subsequently,

we conducted the false positive analysis on the re-

maining vulnerabilities in scope. Due to the initial

scope deﬁnition, 779 ﬁndings had to be analyzed in

this step, i. e. 779 vulnerabilities. 371 of these vul-

nerabilities had to be mitigated manually in the end.

However, through automation of the mitigation,

developers may not be sensitized as if they had to mit-

igate the vulnerabilities manually. Due to the cost-

effectiveness, we consider the tool-support valuable.

Yet, taking measures to build the developers’ aware-

ness is a reasonable supplement.

Safe Go-live (Availability of Operational Environ-

ment) (Req 3). We enable the safe go-live by adding

another optional phase to our approach. During this

phase, divergences in the result of previous and modi-

ﬁed logic after mitigation are logged. In this case, the

previous logic is executed ﬁnally.

As the approach can be controlled using control

tables that have each mitigation’s safe go-live sta-

tus, modiﬁcations can be reverted easily in case of an

emergency situation. There is only a minimal risk to

the live system as a result. However, the vulnerabil-

ities are not actually mitigated until the safe go-live

status is set to active. This is due to the original code

is executed ﬁnally during transition phase.

Optimize Effort-beneﬁt Ratio (Req 4). As de-

scribed above for Req 2, the effort-beneﬁt ratio is op-

timized by narrowing the project scope and automated

mitigation. The cost-effectiveness further increases

due to additional steps in the project like conducting

a false positive analysis. Due to this methodology, we

only put effort into critical vulnerabilities that cause

high or very high risks for the system and organiza-

tion.

As mentioned in Section 4.1, our partner esti-

mated about 25,000 man-days for a straightforward

manual mitigation. We were able to reduce the major

risks of the system in about 460 man-days.

Context-sensitive Assessment of Vulnerabilities

(Req 5). We assessed the vulnerabilities using their

runtime context: we gathered information on the us-

age of code objects from the live systems. Our tool

proposes code objects for decommissioning if they

were inactive for a speciﬁed period of time. As our

industrial partner already gathered usage data prior to

the code cleansing project, we used the usage data of

15 months in our ﬁeld study. It includes exceptional

usage at year end/beginning or quarter end/beginning.

Additionally, developers consider a vulnerability’s

context when conducting a false positive analysis:

they use the actual context to assess if a vulnerabil-

ity may be exploited or not.

Meet Individual Quality Alignments (Req 6). Con-

trolling the adherence to organization speciﬁc quality

guidelines are part of our security code review check-

list. Additionally, our ﬁxing suite provides many

common security solutions like the introduction of au-

thorization checks or whitelisting mechanisms. By in-

jecting code that uses these components, we enforce

common design principles such as component reuse.

However, during our ﬁeld study we found that our

prototype may be improved in following organization

speciﬁc developer guidelines such as naming conven-

tions: the tool should allow to adapt the mitigating

code templates that are injected. Otherwise, the in-

jections either do not follow the developer guidelines

or they have to be corrected manually.

Flexibility Regarding Enterprise Processes and

Heartbeat (Req 7). In our ﬁeld study, we had to ap-

ply our approach to an agile project method. This

worked well for the code cleansing approach: The

vulnerabilities usually are well-deﬁned and manage-

able tasks to perform within a sprint. This facili-

tates reliable estimations after a few sprints. Addi-

tionally, agile project methods require short feedback

cycles. As our project team worked in parallel to the

actual development team, these short feedback cycles

proved useful.

Auditability of Process and Documentation (Req

8). To ensure the auditability of the code cleansing

project, our prototype wrote logs for each modiﬁca-

tion. These logs were designed for auditability: they

were protected from modiﬁcations and data loss.

Additionally, we aligned with the auditors from

the beginning. During the ﬁrst project phase, we

presented the project method to the auditors to get

their approval. As agreed, we further discussed the

intended mitigation measures per vulnerability type

with them, before starting the actual mitigation.

However, the documentation of risk reduction had

to be done manually throughout the project. We cre-

ated the overview of mitigated and accepted risks as

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

306

well as the risk metric mentioned in Section 4.3 man-

ually. There should be future work on creating a more

lightweight, tool-supported documentation.

5.2 Code Cleansing Issues

In the introduction, we mentioned three issues that we

identiﬁed when dealing with huge lists of vulnerabil-

ities. These issues mainly refer to the lack of system-

atic methodology and reasonable tool-support for the

mitigation of large quantities of vulnerabilities.

How Can Organizations Deal with Large

Quantities of Analysis Results? (RQ 1)

This issue is covered by the systematic process and

the tool-supported mitigation of vulnerabilities which

minimizes manual effort: Through the scope deﬁ-

nition we were able to exclude non-critical ﬁndings

from the project which had an enormous effect in the

amount of work. Through measures beyond code and

tool-supported code injection, we enabled developers

to mitigate more than 90 % of the remaining ﬁndings

within a few days. It is affected by the requirements

Req 1, 2 and 4 or their fulﬁllment, respectively.

How Can Vulnerabilities Be Fixed

Systematically? (RQ 2)

The systematic mitigation is looked at in the require-

ments Req 1, 2 and 5: Similarly to RQ 1, we met this

issue with our methodology which deﬁnes a system-

atic process for the mitigation of vulnerabilities. Ad-

ditionally the code injection functionality leads to a

consistent use of mitigation measures throughout the

code. This only excepts for a few vulnerabilities that

had a particular context or that were too complex for

these solutions.

How to Ensure System Availability During

Mitigation? (RQ 3)

The system’s availability may be ensured by apply-

ing the safe go-live approach presented in Section 3.

Req 3 considers the safe go-live approach. The ben-

eﬁts and drawbacks mentioned for this requirement

also hold true for RQ 3. Additionally, Req 6 treats the

code modiﬁcations’ quality assurance. Through code

reviews we enforce the four eyes principle. Review-

ers should pay attention to modiﬁcations’ unexpected

effects on the system availability.

6 RELATED WORK

In the ﬁeld of software security, a lot of work has been

done recently. However, we didn’t ﬁnd any approach

that handles huge vulnerability lists systematically as

ours that combines assessment, prioritization, auto-

matic repair and availability assurance.

Security Analysis. (Li et al., 2013) present a dy-

namic approach to detect vulnerabilities: They an-

alyze backwards traces to identify abnormal results.

(Almorsy et al., 2012) performs security scans on

OCL deﬁnitions for web applications and interfaces

(Almorsy et al., 2012). Other works deal with se-

curity conformance checking to identify fundamental

vulnerabilities in software systems (Jasser, 2019; Abi-

Antoun and Barnes, 2010). (Sametinger, 2013) gives

a short discussion on the increasing security aware-

ness and points out security ﬂaws in the software ar-

chitecture as one major source of vulnerability risks.

Systematic Vulnerability Mitigation. Systematic

refactoring processes that do not affect the code be-

havior are proposed in (Mortensen et al., 2012; Rizvi

and Khanam, 2011). Both approaches use aspect ori-

ented programming (AOP) techniques. May authors

discuss the need of prioritization and ﬁxing strategy

knowledge to handle a large quantity of ﬂaws (Torn-

hill, 2018; Li et al., 2017; Mair et al., 2014; Herold

and Mair, 2014; Mair and Herold, 2013).

Tool-supported approaches aim to reduce the ef-

fort of software vulnerability mitigation: several

work has been done on automatic code modiﬁcations

(Xing and Maruyama, 2019; Anand and Ryoo, 2017;

Durieux and Monperrus, 2016; Hansson, 2015; Qi

et al., 2012; Le Goues et al., 2012). (Gazzola et al.,

2019) give an overview of generate-and-validate and

semantic driven mitigation approaches. In (Tang and

Huang, 2016) the authors present a soft-error mitiga-

tion by considering a combination between functional

unit conﬁguration and instruction ﬂow. Several au-

thors provide results on mitigation strategies that are

based on semi-automatic analysis of vulnerabilities

(Brunil et al., 2009) or API speciﬁc patterns (Niele-

bock, 2017). None of the approaches try to minimize

fault prone code changes, e. g. by considering coun-

termeasures beyond code or unused code.

Security Engineering. There is a wide range of dis-

cussions, papers and publications related to secure

software (Gazzola et al., 2019; Xu and Peng, 2016;

Gao et al., 2016). Due to the fast development of soft-

ware automatic detection and ﬁxing becomes more

and more important. The ﬁxing can also be supported

by machine learning (Tommy et al., 2017).

An Approach to Secure Legacy Software Systems

307

7 CONCLUSION AND FUTURE

WORK

In this paper, we presented an approach for systemati-

cally dealing with huge vulnerability lists that may re-

sult from security analyses. Therefore, our approach

deﬁnes both a methodology and a technical approach.

While the methodology speciﬁes how to execute a

code cleansing project, the technical approach pro-

vides support in mitigating the vulnerabilities beyond

code or at least with minimal manual effort. The ap-

proach has been applied to an industrial ﬁeld study

for evaluation. Therefore, the technical approach has

been implemented prototypically.

Currently, we conduct additional ﬁeld studies for a

more reliable evaluation of our approach. We intend

to iteratively optimize our tool-supported mitigation

through code injection based on the ﬁeld studies. One

issue we want to improve is the adaptation to individ-

ual development guidelines such as naming conven-

tions. Therefore, we need to provide a possibility to

edit the code to inject for mitigation.

REFERENCES

Abi-Antoun, M. and Barnes, J. M. (2010). Analyzing se-

curity architectures. In Pecheur, C., Andrews, J., and

Di Nitto, E., editors, Int. Conf. on Automated Software

Engineering, pages 3–12. ACM.

Almorsy, M., Grundy, J., and Ibrahim, A. S. (2012). Sup-

porting automated vulnerability analysis using for-

malized vulnerability signatures. In 27th IEEE/ACM

Int. Conf. on Automated Software Engineering, pages

100–109.

Anand, P. and Ryoo, J. (2017). Security patterns as architec-

tural solution - mitigating cross-site scripting attacks

in web applications. In Int. Conf. on Software Security

and Assurance, pages 25–31.

Brunil, D., Haddad, H. M., and Romero, M. (2009). Secu-

rity vulnerabilities and mitigation strategies for appli-

cation development. In 6th Int. Conf. on Information

Technology: New Generations, pages 235–240.

Durieux, T. and Monperrus, M. (2016). Dynamoth: Dy-

namic code synthesis for automatic program repair. In

IEEE/ACM 11th Int. Workshop in Automation of Soft-

ware Test, pages 85–91.

Gao, F., Wang, L., and Li, X. (2016). Bovinspector: Auto-

matic inspection and repair of buffer overﬂow vulner-

abilities. In 31st IEEE/ACM Int. Conf. on Automated

Software Engineering, pages 786–791.

Gazzola, L., Micucci, D., and Mariani, L. (2019). Auto-

matic software repair: A survey. IEEE Transactions

on Software Engineering, 45(1):34–67.

Hansson, D. (2015). Automatic bug ﬁxing. In 16th Int.

Workshop on Microprocessor and SOC Test and Veri-

ﬁcation, pages 26–31.

Herold, S. and Mair, M. (2014). Recommending refactor-

ings to re-establish architectural consistency. In Avge-

riou, P. and Zdun, U., editors, 8th Europ. Conf. on

Software Architecture, volume 8627 of Lecture Notes

in Computer Science, pages 390–397. Springer.

Jasser, S. (2019). Constraining the implementation through

architectural security rules: An expert study. In 20th

Int. Conf. on Product-Focused Software Process Im-

provement.

Le Goues, C., Nguyen, T., Forrest, S., and Weimer, W.

(2012). Genprog: A generic method for automatic

software repair. IEEE Transactions on Software Engi-

neering, 38(1):54–72.

Li, H., Kim, T., Bat-Erdene, M., and Lee, H. (2013).

Software vulnerability detection using backward trace

analysis and symbolic execution. In Int. Conf. on

Availability, Reliability and Security, pages 446–454.

Li, X., Chang, X., Board, J. A., and Trivedi, K. S. (2017).

A novel approach for software vulnerability classiﬁca-

tion. In Annual Reliability and Maintainability Sym-

posium, pages 1–7.

Mair, M. and Herold, S. (2013). Towards extensive software

architecture erosion repairs. In Drira, K., editor, 7th

Europ. Conf. on Software Architecture, volume 7957

of Lecture Notes in Computer Science, pages 299–

306. Springer.

Mair, M., Herold, S., and Rausch, A. (2014). Towards ﬂexi-

ble automated software architecture erosion diagnosis

and treatment. In Working Int. Conf. on Software Ar-

chitecture Companion Volume, WICSA ’14 Compan-

ion, pages 9:1–9:6, New York, NY, USA. ACM.

McGraw, G. (2006). Software security: Building security

in. In 17th Int. Symposium on Software Reliability En-

gineering, pages 6–6.

Mortensen, M., Ghosh, S., and Bieman, J. (2012). Aspect-

oriented refactoring of legacy applications: An eval-

uation. IEEE Transactions on Software Engineering,

38(1):118–140.

Nielebock, S. (2017). Towards api-speciﬁc automatic pro-

gram repair. In 32nd IEEE/ACM Int. Conf. on Auto-

mated Software Engineering, pages 1010–1013.

Qi, Y., Mao, X., and Lei, Y. (2012). Making automatic

repair for large-scale programs more efﬁcient using

weak recompilation. In 28th IEEE Int. Conf. on Soft-

ware Maintenance, pages 254–263.

Rizvi, S. A. M. and Khanam, Z. (2011). A methodology for

refactoring legacy code. In 3rd Int. Conf. on Electron-

ics Computer Technology, volume 6, pages 198–200.

Sametinger, J. (2013). Software security. In 20th IEEE

Int. Conf. and Workshops on Engineering of Computer

Based Systems, pages 216–216.

Tang, L. and Huang, Z. (2016). A method for issue queue

soft error vulnerability mitigation. In 17th IEEE/ACIS

Int. Conf. on Software Engineering, Artiﬁcial Intelli-

gence, Networking and Parallel/Distributed Comput-

ing, pages 443–450.

Tommy, R., Sundeep, G., and Jose, H. (2017). Automatic

detection and correction of vulnerabilities using ma-

chine learning. In Int. Conf. on Current Trends in

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

308

Computer, Electrical, Electronics and Communica-

tion, pages 1062–1065.

Tornhill, A. (2018). Prioritize technical debt in large-scale

systems using codescene. In IEEE/ACM Int. Conf. on

Technical Debt, pages 59–60.

Xing, X. and Maruyama, K. (2019). Automatic software

merging using automated program repair. In IEEE 1st

Int. Workshop on Intelligent Bug Fixing, pages 11–16.

Xu, D. and Peng, S. (2016). Towards automatic repair of

access control policies. In 14th Annual Conference on

Privacy, Security and Trust, pages 485–492.

An Approach to Secure Legacy Software Systems

309