Raising Security Awareness using Cybersecurity Challenges in Embedded Programming Courses
Tiago Espinha Gasiba, Samra Hodzic, Ulrike Lechner, Maria Pinto-Albuquerque
RRaising Security Awareness usingCybersecurity Challenges in EmbeddedProgramming Courses
Tiago Espinha GasibaSamra Hodzic [email protected]@siemens.com
Siemens AGMunich, Bavaria, Germany
Ulrike Lechner
Universität der BundeswehrMünchenNeubiberg, Germany [email protected]
Maria Pinto-Albuquerque
Instituto Universitário de Lisboa(ISCTE-IUL), ISTARLisboa, Portugal [email protected]
Abstract
Security bugs are errors in code that, when exploited,can lead to serious software vulnerabilities. These bugscould allow an attacker to take over an application andsteal information. One of the ways to address this issueis by means of awareness training. The Sifu platformwas developed in the industry, for the industry, withthe aim to raise software developers’ awareness of se-cure coding. This paper extends the Sifu platform withthree challenges that specifically address embeddedprogramming courses, and describes how to implementthese challenges, while also evaluating the usefulnessof these challenges to raise security awareness in anacademic setting. Our work presents technical detailson the detection mechanisms for software vulnerabil-ities and gives practical advice on how to implementthem. The evaluation of the challenges is performedthrough two trial runs with a total of 16 participants.Our preliminary results show that the challenges aresuitable for academia, and can even potentially be in-cluded in official teaching curricula. One major findingis an indicator of the lack of awareness of secure cod-ing by undergraduates. Finally, we compare our resultswith previous work done in the industry and extractadvice for practitioners.
Keywords: secure coding, software quality, embeddedprogramming, training, cybersecurity challenge, edu-cation, security bug
Security vulnerabilities originate in programming er-rors, that, when left in code, can be exploited by ma-licious parties and lead to severe security incidents. Examples of vulnerabilities are, e.g., Shellshock, Heart-Bleed, POODLE, and DirtyCOW. The presence of theseerrors in software code is an indicator of poor codequality [34]. Consequences of security breaches include,among others, leakage of confidential information, de-nial of service, and privilege escalation [21]. Over thelast years, the number of vulnerabilities in softwarehas been steadily increasing and the corresponding fi-nancial consequences, e.g. for affected companies, isexceeding several billion dollars [2]. One reason thatmight justify this increase in vulnerabilities is the everincreasing complexity of code and systems.In an industrial context, several methods exist to ad-dress code quality, e.g. using Static Application Secu-rity Testing (SAST) Tools [24], IDE plugins, performingthreat and risk analysis, and code reviews. In [18], McIn-tosh et al. discovered that code review coverage andexpertise participation have a significant link with soft-ware quality. While these methods are typically used inthe industry, another important aspect should also beconsidered, namely students from academia, as thesewill be the next generation workforce. Furthermore,students might not have access to all of these methods,or might even lack training in cybersecurity.In this work we look at raising cybersecurity aware-ness on secure programming for students in an aca-demic setting. Our work is based on exploring and us-ing CyberSecurity Challenges (CSC) in the academia.CyberSecurity Challenges is a novel serious game [8]which aims to raise awareness on secure coding of soft-ware developers in the industry [11]. These games arewell investigated, and are showing very promising re-sults in an industrial setting. However, these gameshave, until now, not been explored in an academic set-ting. a r X i v : . [ c s . S E ] F e b . E. Gasiba, S. Hodzic, U. Lechner, and M. Pinto-Albuquerque The current research extends previous work [10]by developing C++ challenges in an industrial securecoding awareness platform (Sifu platform). Althoughother providers exist that offer programming courses,the Sifu platform targets especially industrial environ-ments. The design of the new challenges hereby pre-sented differ from challenges previously implementedin the Sifu platform since they target embedded pro-gramming courses. Furthermore, evaluation is done inan academic setting, which allows to compare indus-try and academia. In particular, this work comparesthe perceived benefits of using the awareness platformin academia and industry. The results of this compar-ison might differ due to the different background ofstudents and professional software developers. There-fore we aim to evaluate the suitability of CSC gamesin the academia, provide details on the implementationof embedded programming challenges, and aid univer-sities to adopt the platform to assist teaching secureprogramming of embedded systems. The industry alsobenefits from the latter, as these students will be betterprepared for the industry demands in terms of securesoftware development.In the following we introduce three C++ challengeswith different security vulnerabilities. In these chal-lenges, the security vulnerabilities that will be intro-duced are, according to the authors’ experiences inthe industry, likely to happen in embedded systemsprogramming. These are: side-channel vulnerability, in-valid memory access, and race condition. Along withthe challenge description, we will address the learninggoal of the challenge to raise awareness on secure cod-ing. We also give details on how the Sifu platform canassess the vulnerability in the code by means of auto-matically testing that a participant’s solution followssecure coding guidelines. The main contributions ofthis work are the following: • design of three defensive C++ programming chal-lenges in the industry which aim to raise securecoding awareness • base the challenges on security vulnerabilitiescommon in embedded systems • details on how to test that solutions from a par-ticipant follow secure coding • preliminary results on the acceptance of the chal-lenges by students in academia • insight into implementation and improvementsfor practitioners The current work’s main target is to use the Sifuplatform, which was developed in the industry, extendit, and analyze how it applies in academia. We aim toanswer the following research questions: RQ1
How can the Sifu platform be used in academia?
RQ2
How to decide whether a challenge based on side-channel, invalid memory access, and race condi-tion was correctly solved?
RQ3
How do students perceive the challenges presentedthrough the Sifu platform?In section 2, we present previous work related to ourresearch. section 3 discusses our approach to designdefensive C++ challenges. We first briefly describe theSifu platform, which is used to integrate these chal-lenges to be used for training. The main part of thissection is to introduce the implemented challenges andwhich security vulnerabilities they contain. We alsopresent our methodology for assessing the presence ofthe security vulnerabilities in the code. Additionally, wediscuss the evaluation of the developed challenges andplatform in the academia. The results are presented anddiscussed in section 5. Three groups of results are pro-vided: evaluation of the challenge assessment methods,analysis of two test runs including a survey and semi-structured interview, and comparison with our resultsto previous results for the industrial context. Finally,section 6 summarizes our work and briefly discussespossible next steps.
Previous research shows that software developers lacksecure programming awareness and skills [12, 28]. Ga-siba et al. [14] introduced CyberSecurity Challenges(CSCs) to raise secure coding awareness of softwaredevelopers in the industry. CSCs are serious games thatrefine the popular CTF format and adapt it to the in-dustry. Gasiba et al. [9] researched the constraints andrequirements for delivering a cybersecurity challengewhich can cover secure coding from an industry per-spective. One important outcome of this research isthat the challenges should focus on the defensive per-spective, and not on the offensive. In their work, theyintroduced a new platform [10], which the authors callSifu. The platform performs an automatic assessmentof challenges in terms of compliance to secure codingstandards and guidelines. It uses an artificial intelli-gence coach, which guides the participant throughoutthe challenge. Their work presents results that indicatethat the Sifu platform’s CSC events are adequate for aising Security Awareness using Cybersecurity Challenges in Embedded Programming Courses raising secure coding awareness of software develop-ers in the industry. Ruef et al. [25] designed a similartraining, however their platform is not focused on aspecific programming language, and includes offensivechallenges.Tabassum et al. [27] and Whitney et al. [30], presentthe importance of secure coding guidelines and stan-dards in the software development life-cycle. Given thelack of knowledge on secure coding, developers tendto search online resources for answers and solutions.However, Kurachi et al. [17] and Zhang et al [33] showthat these solutions are not always adequate and blindusage of these solutions can lead to additional problems.Static analysis is an evolving approach to evaluateprograms based exclusively on their source code with-out running them. Clang is a C/C++/Objective-C open-source compiler [7]. It is a continually developing ini-tiative sponsored by large companies such as Apple,Microsoft, and Google. Clang is currently a popularmethod for designing new static analyzers. Its modulararchitecture is one of Clang’s strength [5]. The Sifu plat-form makes use of this technology provided by Clangto implement security assessments of challenges.In [1, 3, 4, 6], the researchers compare different open-source static analysis tool available for C/C++. The au-thors have developed their C/C++ applications and in-troduced various vulnerabilities in the application. Theyuse these applications to check the tool’s capabilities todetect the introduced vulnerabilities. The researchershave also presented a study comparing commercialstatic code analysis tools for detecting vulnerabilitiesin a software source code.In our work, we use the semi-structured interviewsmethodology as given by Wilson et al. [31]. We also usethe definition of awareness as given by Hänsch et al.[15]. In their work, they specify awareness as havingthree components: perception, protection and behavior.Perception relates to knowledge of threats, protectionrelates to knowing available mechanisms to protectagainst these threats, and finally behavior relates toactual individual behavior, e.g. as in actively writingsecure code.
In this work, we address three different cybersecuritychallenges, targeting specific security vulnerabilities.This work’s challenges are Sorting - Time Side Channel,Complex Factory (invalid memory access), and TOC-TOU Race Condition. All challenges were implemented in the C++ programming language and integrated intothe Sifu platform. Table 1 presents these challengesalong with security vulnerabilities and guidelines con-tained in them. In subsection 3.1, we briefly introducethe Sifu Platform. Next, we describe implementationdetails of the assessment of the cybersecurity vulner-abilities of the three challenges. We also discuss theevaluation of the implementation of the challenges. Fi-nally we refer to the setup and results of the empiricalstudy performed with participants from academia. No-tice that the proposed vulnerability detection methodsrun additionally to several already existing vulnerabil-ity detection mechanisms in the Sifu platform.
Sifu is a web-based CyberSecurity Awareness Platform[11]. This platform was developed in the industry withthe aim to raise software developers’ awareness on se-cure coding. In the industry, this platform is typicallyembedded in a serious game called CyberSecurity Chal-lenges. The platform contains several exercises (chal-lenges) that are presented to participants in the formof a project, e.g. in C/C++. These challenges containone or more vulnerabilities in the code. The task of theplayer is rewrite the code such that it does not containthe vulnerability, while still performing the intendedfunctionality. All interactions between the player andthe platform takes place through the web interface.Once the player has made changes to the code, heor she can submit the code to the backend, which willanalyse the submitted codeand provide feedback tothe player. The goal of the analysis performed in thebackend is to assess the presence of cybersecurity vul-nerabilities in the code submitted by the player in termsof secure coding guidelines. The goal of the feedbackis, depending on the results of the cybersecurity assess-ment, to either indicate to the player that the challengehas been solved, or to guide the player to the correctsolution by means of hints.Figure 1 shows the main components of the Sifuplatform’s backend. The automatic assessment of chal-lenges is performed using several components: pre-processor, compilers, static and dynamic applicationsecurity tools, unit tests and run-time application secu-rity tests. An artificial intelligence component collectsthe results of these tools, performs the cybersecurity as-sessment and generates hints. The Sifu platform can bedeployed in a local intranet server or in a cloud environ-ment, enabling remote awareness workshops possible. . E. Gasiba, S. Hodzic, U. Lechner, and M. Pinto-Albuquerque
Table 1.
Secure coding guidelines disregard list
Challenge Rule Severity Likelihood Description Line number
ComplexFactory MEM31-C [19] Medium Probable Free dynamically allocated memorywhen no longer needed No destructorEXP35-CPP [19] High Probable Do not read uninitialized memory 25EXP45-CPP [19] High Probable Do not access an object outside of itslifetime 18MEM51-CPP [19] High Likely Properly deallocate dynamically allocatedresources 33CTR50-CPP [19] High Likely Guarantee that container indices anditerators are within the valid range 18, 25ARR31-C [19] High Probable Ensure size arguments for variablelength length arrays are in a valid range 6CWE-315 [20] Medium Likely Double free 33CWE-416[20] High Likely Use after free 18, 25Sorting CWE-208 [20] High Likely Observable Timing Discrepancy 7-12TOC-TOU CWE-367 [20] High Probable Time-of-check Time-of-use (TOCTOU)Race Condition 7-12
For further information and details on the platform, werefer the reader to [10].
WebBackendWebFrontend
SandboxTools
SAST UnitTests
A.I.
CollectorFeedback
Backend Project
Pre-Processing AI Engine DASTCompiler ?/.6
Figure 1.
Architecture of the Sifu Platform
The goal of this challenge is to raise awareness on theplayer on a well-known security vulnerability calledthe time side channel (TSC) [26]. A time side-channeloccurs when the execution time of an algorithm is dif-ferent for different inputs of the same size. In general,side-channels, such as time, can leak data and causesecurity problems [23]. This type of security vulnerabil-ity is critical in embedded systems and programming,since execution time is closely related with power con-sumption. Note that time side-channels can be easilyobserved and measured directly on hardware, such asin an embedded system through an oscilloscope, and measuring power-consumption profiles. This type ofvulnerability can originate in both a poor implemen-tation of hardware components, or non-constant timealgorithms implemented in software. A typical exampleof a software algorithm that is vulnerable to time side-channels, is a string comparison function which returns,i.e. stops comparing the two strings, whenever the firstdifference is found. The run time of the algorithm thusdepends on the initial number equal characters. How-ever, any algorithm that does not run in constant timecan leak information.
Listing 1. sort.cpp
The source code of the challenge that is presentedto the participant is shown in Listing 1. To solve thechallenge, the player needs to implement a constant-time sorting algorithm, i.e. a sorting algorithm wherethe execution time only depends on the number ofelements to be sorted and not on their individual valuesor positions.To address the assessment of the existence of a tim-ing side-channel vulnerability, in code submitted by aplayer in the Sifu platform, we have searched for exist-ing tools and libraries that could assist in this task. Tworequirements that this tool or library must follow is that1) it should be independent of an embedded system, and2) it should be easily run in any environment, such asin the cloud. A possible solution to this problem is toperform the evaluation by means of an embedded sys-tem simulator. This, however, is not practical since theassessment could incur a considerable delay, making apractical usage in the Sifu platform difficult. Further-more, we could not find any library that could easily beused in practice to detect this vulnerability. Therefore,we propose to use the GNU Debugger, by means of adedicated python program, as shown in Figure 2. In thissolution, GDB is used to count the number of steps thatthe entire sorting function needs to execute, i.e. fromstart to end. We assume that number of steps requiredto run the code is highly correlated with the time ittakes to execute it, and ignore any possible issues rel-ative to cache misses. One of the main advantages ofthis solution is that the measurement is no longer de-pendent on actual CPU run time, and can be deployedin any environment. While this method possibly takesmore time to perform the assessment than running thecode in bare-metal, it will take considerable less timethan running an entire embedded hardware simulator.However, the true result might be dependent on thenumber of clock-cycles of each assembly instruction.
C++ WrapperPlayer's solution get line addressLine number break ataddress GDB methoddo_count Number ofinstructionsGDB commands basedscriptdefine do_countset $count=0while ($pc != $arg0) step set $count = $count+1endprint $count
Figure 2.
Count instructions diagram Figure 2 shows an overview on how to perform thecybersecurity assessment of the participant’s code. Thecode submitted by the participant is embedded in aC/C++ project which contains a wrapper that calls thesorting function. This small project is then compiled.A python script starts a GDB session which is used todebug the compiled project. This script interacts withGDB in the following three steps: 1) create a break-point at function call, 2) execute the function step-wise,and 3) step the code until it returns from the function.During the function’s step-wise execution, the totalnumber of steps (iterations) is recorded in an internalGDB variable. To assess the TSC, the C++ wrapper callsthe sorting function with at least two different inputvectors of the same size, e.g., using a sorted array and anunsorted array. The python script measures the numberof steps that each function call takes to sort the vector.Comparing the number of steps in both cases is used toassess the presence of a time side-channel vulnerability.In our experiments, we have performed the step-wisemeasurements using the GDB step and stepi commands.The step command executes each line of code, whilethe stepi executes each assembly instruction.
The main goal of this challenge is to raise the aware-ness on invalid memory access. However, this challengecontains several additional vulnerabilities, as shown intable Table 1. The secure coding guidelines and vulner-abilities were chosen base on their likelihood [19] andadaptability to the challenge.Listing 2 shows the code that is presented to theplayer. The code implements a C++ class that storescomplex numbers in an internal buffer of a given max-imum size. The maximum size of the buffer it set atconstruction time, when an instance of the class is cre-ated. Table 1 also details the line numbers where thecode’s vulnerabilities are present, together with the cor-responding SEI-CERT secure coding guidelines [19] andvulnerabilities as defined by the Common WeaknessEnumeration (CWE) [20].
Listing 2.
ComplexFactory.cpp " FCplx .h" using namespace std ; /* Constructor allocates a container with MAX elements */ FCplx :: FCplx ( int _max ): max ( _max ) { . E. Gasiba, S. Hodzic, U. Lechner, and M. Pinto-Albuquerque pos = 0; container = new complex < int >[ max ]; } /* Stores a complex number in the container and returns a reference to it */ complex < int >& FCplx :: create ( int x , int y) { complex < int > a = complex < int >(x ,y); container [ pos ++] = a; return a; } /* Returns a reference to an element stored in the container index 1 returns first element */ complex < int >& FCplx :: get ( int index ){ return container [ index - 1]; } /* Frees the allocated array . After calling this method no further method calls are be allowed */ void FCplx :: empty () { delete container ; } To detect code that disregards the secure codingguidelines presented in Table 1, two distinct methodsare used: GCC sanitize flags and security tests. Sanitizeflags are part of dynamic application security testing,and are provided to the compiler at compile time. Theyinstruct the compiler to generate extra checks that areperformed during code execution. The following arethe sanitize flags which we use: address , leak , and unde-fined behavior . Address flag adds extra run-time checkson memory addressing, leak flag adds extra run-timechecks related to memory allocation, and undefinedbehavior flag adds extra run-time checks on undefinedbehavior, as defined by the C++ standard.The second method used to detect code vulnerabili-ties is through security testing. Security tests are usedto test specific corner cases, and they try to expose avulnerability during run-time. One example of a secu-rity test, e.g. to test CWE-315 (double free), is to deletethe class variable twice. A secure solution should catchthis problem and react accordingly; however, a poorlyimplemented solution will cause a double free error,which in turn will trigger the leak sanitizer. For eachsecure coding guideline, one or more security test is implemented which tries to trigger the correspondingvulnerability. The goal of this challenge is to raise the awarenesson race condition vulnerabilities. A race condition canoccur when two or more concurrent processes try toaccess a shared resource, whereby at least one pro-cess tries to modify the shared resource. The time be-tween the resource is read and the resource is modifiedis known as race window or critical section. Conse-quences of exploiting this types of vulnerability includedenial-of-service, and privelege escalation.While race conditions typically occur in shared mem-ory, we propose a challenge based on files. In this casethe shared resource is a file and the vulnerability iscalled a time-of-check, time-of-use (TOCTOUC). Thesecurity vulnerability is listed in the CWE database un-der CWE-367 [20]. Listing 3 shows the challenge thatis presented to the player. To solve the challenge, theplayer needs to perform two steps: check if a file ex-ists and, if it exists, modify its permissions. The racewindow occurs between the time that the existence ofthe file is checked until the attributes are modified. Theproblem is that a malicious user can change the filebetween the two operations and, therefore the codechanges the permissions of the wrong file. Previousresearch that addresses this vulnerability on real-timeembedded systems is [29, 32]. Note: one possible solu-tion to this challenge is by using the fchmod, insteadof the chmod function.
Listing 3. set_permissions.cpp /* Check if the file exists , and change the mode of the file . Return true if everything was successful */ bool setPerm ( char * fName , mode_t mode ){ // Check if the file exists FILE * f_ptr ; // Change the mode if ( chmod ( fName , mode ) == -1) { // Handle error ... return false ; } return true ; } This type of vulnerability can potentially be detectedby means of static application security testing tools.However, to the best of our knowledge, except for com-mercial solutions, there is no open-source tool that aising Security Awareness using Cybersecurity Challenges in Embedded Programming Courses can detect this type of vulnerability [22]. Furthermore,static application security testing tools are known tobe unreliable [22, 24]. In light of this, we propose a sim-ple solution based on an attack script and a wrapperfunction, as shown in Figure 3. The wrapper functioncalls the participants’ solution multiple times while, inparallel, an attacker script is running and swapping thetwo files in an endeless loop. Both the wrapper and theattacker script stop executing when one of the follow-ing conditions is met: (1) the permissions are changedin the wrong file, or (2) a maximum number of itera-tions is achieved. Condition two will occur if there isno vulnerability in the code of the player, or the racecondition could not be achieved, i.e. the vulnerabilitywas not detected after all the iterations.
Attack's file Target filePartcipant's solutionAttack script
Possible link due toattack
Figure 3.
Top-level challenge structureNote that, since the race condition is not reliablytriggered, several tries need to be performed. We expectthat the more iterations are performed, the higher theprobability to detect the the vulnerability. In section 4we present the results of evaluation on the trade-offbetween the detection probability and the total numberof iterations.Another possible solution to the detection problem isby artificially modifying the player’s code and injectinga delay in the code’s critical section. Although this solu-tion can potentially increase the reliability to detect thevulnerability, it requires, however, a modification of thesource code submitted by the participant. Furthermore,the method and implementation details to achieve thisreliably is currently an open topic.
Validation of the presented cybersecurity assessmentmethods was performed through computer experimen-tation. Additionally, the challenges were deployed in an academic environment, followed by semi-structuredinterviews and a survey. In this section we give detailson the evaluation process.
For the Time Side-Channel challenge, an evaluationtook place by means of two possible implementationsof the sorting algorithm: with and without a time sidechannel. The algorithm containing the vulnerabilitywas a standard bubble-sort algorithm, while the imple-mented solution was a bubble sort algorithm modifiedto swap elements with the same index, thus increasingrun-time and avoiding the time side-channel vulnera-bility. The input to the sorting algorithm consisted ofthree random permutations of an integer vector size of 5elements. The process was repeated 1000 times for bothalgorithms and for the step and stepi
GDB commandsrespectively. Furthermore, the total execution requiredto get an answer from the backend was measured.For the Race Condition challenge, we focus on theevaluation of the detection probability of the vulnera-bility. To compute this probability, we ran the pythonscript 1000 times, and recorded the number of iterationsrequired to detect the vulnerability. Based on these re-sults, we can compute the cumulative density functionof the detection probability 𝑐 ( 𝑛 ) by normalizing thenumber of times that the vulnerability was detected inless than n cycles.Since the Complex Factory challenge uses standarddetection mechanisms, we have not performed an eval-uation step for the security assessment.All the tests were conducted on a PC with the fol-lowing specifications: Ubuntu 18.04.4 LTS on an Inteli5-3427U CPU running at 1.80GHz with four cores and8 GB of RAM. We have deployed the challenges in the Sifu Platformand asked several students, without previous industryexperience, to evaluate them during two runs. Table 2shows details on the demographics of these runs.The participants were first given a short introductionto the platform, and were given instructions on how touse it. Next, the participants were given time to checkand familiarize with the platform, and to solve the chal-lenges. After solving the challenges, a semi-structure in-terview took place. Participation in the semi-structuredinterview was not mandatory, and the collected an-swers were anonymized. . E. Gasiba, S. Hodzic, U. Lechner, and M. Pinto-Albuquerque
The participants were also asked to answer a smallsurvey consisting of eleven questions. The questionsthat were asked in the survey are shown in Table 3.Survey feedback answers were gathered using GoogleForms. The answers to the questions were based a 5point Likert scale [16] for agreement, i.e. strongly dis-agree , disagree , neutral , agree , and strongly agree . Thequestions are adopted from [11] and extended to tar-get the academia. The adoption of the same questionsallows, in the results section, to compare the answersfrom academia to answers from the industry. Table 3.
Survey questionnaire
Survey Question
Q1 Paying attention to secure coding increases my codequalityQ2 University teaching includes awareness in secure codingQ3 I learned new techniques and principles of securesoftware developmentQ4 I know how to use the information about secure codingguidelinesQ5 I understand the importance of secure coding guidelinesQ6 Focusing on the challenges improves my practical securecoding skillsQ7 I have learned about new issues that I would like tocheck in my own codeQ8 I know where I can find more information about securecoding guidelinesQ9 The learning goals of the challenges were clearlyexplainedQ10 The help from the virtual coach was adequate
In total, six participants responded to the plannedsemi-structured interview. The semi-structured inter-view questions were based on the following questions: what is the most significant advantage in participating inthese challenges , what did not go well and you would liketo change , and do you think that secure coding awarenessincreases the code quality overall . This section show the results on the evaluation of theproposed vulnerability assessment schemes for differ-ent the challenges. This section also shows the analy-sis of the survey questions, and result from the semi-structured interviews. We also present a comparison ofour survey results with two similar surveys by Gasibaet al. which were held in an industrial context.
Figure 4 presents the results when using step (right plot)and stepi (left plot) GDB commands respectively. Bothinstructions, step and stepi, show only a line (i.e. singlevalue) when there is no time side-channel vulnerabilitypresent in the code. This result comes as a consequenceof having the same number of instructions for everyinput. Furthermore, the vertical lines show the worstand best case for no TSC. The observable difference ininstruction count comes as a consequence that the stepiinstruction needs to execute every assembly instructionof the source code.The stepi GDB command takes more iterations thanthe step GDB command to perform the assessment ofthe vulnerability. This result is expected, since the stepicommand executes the code one assembly instructionat a time, while the step command executes the codeone source code line at a time. Due to their nature, thestepi command is more precise than the step command;however this represents a trade-off between precisionand speed, since the stepi command is more than twentytwo times slower than the step command.Figure 4 also shows that, for the stepi GDB command,an increase in the number iterations between 31.8% and95.3% between code without TSC and code with TSCis observed. The same figure shows that for the stepcommand, the increase in the number of iterations isbetween 44.4% and 157% for code without TSC and codewith TSC.The second aspect to check the design is the reason-able delay after the participant has submitted a solution.
Table 2.
Participants’ information
No. Start Date End Date Participants Where Age Range Field of Study Educational Level aising Security Awareness using Cybersecurity Challenges in Embedded Programming Courses stepi with TSC stepi without TSC N u m be r o f i t e r a t i on s step with TSC step without TSC N u m be r o f i t e r a t i on s Figure 4.
Step instruction comparisonWe have measured the execution time of this imple-mentation when running it in the Sifu platform. Table 4shows the captured measurements together with 1stand 3rd quartile. Same cases were covered as in theFigure 4.
Table 4.
Execution time measurement
Test case Mean exec time [s] Q1 Q3
Step with TSC 1.81 1.76 1.86Step without TSC 2.19 2.18 2.20Stepi with TSC 3.74 3.44 3.91Stepi without TSC 5.43 5.39 5.48
In the TOC-TOU Race Condition Challenge, we eval-uated the detection probability of the attacking script.The results are shown in Figure 5. The x-axis of this fig-ure shows the number of tried, i.e. iterations, performedto detect the vulnerability, while the y-axis shows theprobability of detection.This graph shows that, to achieve a detection rate of99%, more than 3000 iterations are required. Since theexecution time for a single round of this assessmentmethod is very small (in the order of microseconds), werecommend to implement more than 10,000 iterationsin a practical scenario. Our results show that, this valueis reasonable and does not lead to considerable delayin the backend.Figure 5 can be used as a guideline by practitionerswho wish to implement this detection mechanism intheir own deployments. Since the actual running timedepends on the speed and on the CPU where the testis run, we recommend that practitioners start with thevalue 10,000 and run their own evaluation of the num-ber of iterations that are required to achieve a detectionprobability of 99% or higher.
Saved from: https://live.amcharts.com/4NmNm/edit/
Figure 5.
Success probability related to number of tries
Figure 6 shows the results of the survey which wasbased on the questions introduced in Table 3. Our pre-liminary results show, except for Q1 and Q2, an overallagreement with the survey question. The questionsthat include the highest agreement are Q6, Q7, Q9, andQ10. This means that the participants agree that theassistance provided by the virtual coach is adequate,thus providing a good indicator of the suitability of theproposed vulnerability detection methods. Participantsalso agree that focusing on secure coding challenges im-proves their security coding skills, therefore also theirawareness on the secure coding guidelines. Finally, theparticipants have learned new vulnerabilities that theywould like to check in their own code. This gives agood indicator that these types of games can motivatea positive behaviour towards secure coding.The aspects there received the lowest amount ofagreement, though still overall positive, are related withQ4 and Q8. This is not surprising since the Sifu plat-form is developed for the industry, and motivates theparticipants to find additional information on securecoding using internal resources; the same cannot besaid for the academia, where further information shouldbe searched in online forums or scientific publications.It is however surprising that the participants claim thatplaying the challenges allows them to know where tofind more information about secure coding, and howto use this information.We also observe that, in general, there is still a highlevel of neutral answers. The reason for this is not wellunderstood and further research is necessary to under-stand this issue. Also, for Q1, it is surprising that theparticipants are not entirely sure if paying attention tosecure coding increases their code quality. Althoughone possible reason for this might be the lack of specifictraining in secure coding and code quality, this aspectneeds more search. Finally, another surprising result is . E. Gasiba, S. Hodzic, U. Lechner, and M. Pinto-Albuquerque
Figure 6.
Survey Resultsthe one obtained in Q2, where the participants claimthat university teaching does not include awarenesson secure coding. This result is an indicator that thisawareness campaigns are necessary to be held in theindustry, and a specialized course that covers securecoding and secure coding guidelines might be benefi-cial. Attending this course would better prepare thestudents for a future career in the industry.
Table 5 shows a comparison of the current work, andthe work by Gasiba et al. (see [13], and [10]). The maindifference is that, in the current work, we evaluate theCyberSecurity Challenges in the academia, while previ-ous work evaluates these in an industrial context. Boththe current work as the previous work show a gen-eral agreement in relation to all the survey questions.However, one important difference is the fact that Q5has a higher agreement level for the industry as in theacademia. We think that the main reason for this dif-ference might be related with the fact that the usageof secure coding guidelines are typically mandated bysecurity policies in the industry, e.g. as a result of re-quirements from cybersecurity standards, while thisis not the case in academia. We also observe that Q4and Q8 exhibit a large amount of neutral answers forboth academia and also for the industry. The reason be-hind this is not entirely understood and requires furtherinvestigation. In terms of disagreement, we observe that Q3, Q7,and Q8 have a similar amount of disagreement in boththe academic setting and also in the industrial setting.One common positive point in all the surveys, industryand academia, is the fact that the support by the coachis seen as an important factor. The factor that has thelargest amount of difference between the academia andindustry is Q8 - knowing where to find more informa-tion; Based on our experience, we think that this mightbe related with the fact that in an industrial environ-ment, there are internal procedures related with securesoftware development life-cycle which establish wherefurther information can be obtained. This might justifythe higher value for academia and lower value for theindustry.Surprisingly there is about 8% of negative answersin relation to Q9 - the goals of the challenge are clearlystated - for the industry, while 0% for academia. Thiseffect might be related with the diversity of software de-velopers in the industry; however, further investigationis needed to understand this discrepancy.In summary, although there are some differences ob-served in the results of academia vs industry, overallthere is a large agreement for all the survey questions.This fact gives a good indication that the Sifu platformand its challenges are well suited for both academia andindustry. aising Security Awareness using Cybersecurity Challenges in Embedded Programming Courses
Table 5.
Comparison with previous work
Present work Gasiba et al. [13] Gasiba et al. [10]Question Negative Neutral Positive Question Negative Neutral Positive Question Negative Neutral Positive
Q1 25.0% 43.7% 31.3%Q2 87.6% 6.2% 6.2%Q3 6.2% 12.5% 81.3% Q1.1 12.5% 7.1% 80.4% X1 0.0% 10.0% 90.0%Q4 6.2% 18.8% 75.0% Q6.1 8.9% 28.6% 80.3%Q5 18.7% 12.5% 68.8% Q10.9 0.0% 5.3% 94.7% X9 0.0% 0.0% 100.0%Q6 0.0% 6.2% 93.8% Q7.1 3.6% 14.3% 82.1% F2 0.0% 4.0% 96.0%Q7 0.0% 12.5% 87.5% Q8.1 10.7% 5.4% 83.9%Q8 6.3% 18.7% 75.0% Q9.1 12.5% 31.2% 55.4% X8 0.0% 10.0% 90.0%Q9 0.0% 12.5% 87.5% Q11.1 8.9% 8.9% 82.2% F8 8.0% 8.0% 84.0%Q10 12.5% 0.0% 87.5% Q13.1 1.8% 12.5% 85.7% X6 0.0% 0.0% 100.0%16 participants 56 participants 25 participants
After using the Sifu platform and solving each of theproposed challenges, participants were interviewed.Analysis of the participants’ answers resulted in theirclassification into three groups:
Benefits , Application inEmbedded systems , and
Drawbacks . Table 6 shows thetop 10 quotes from participants, along with a mappingto the individual groups. The group
Benefits covers theuser experience and what the participants thought wasthe most beneficial outcome of the challenges. Group
Application in Embedded systems was related to our pri-mary goal, which was not explicitly mentioned, witha reason to see if the participants see a possible appli-cation of this platform for training secure coding inembedded systems. Finally, the group
Drawbacks , cov-ers negative aspects experienced by the participants.The feedback that we have collected allows to under-stand the strong and weak points of the platform, andalso to improve the it further.The grouping of certain answers and comments an-swered how participants perceive the platform and seea possible application in embedded programming. Themain outcome of the semi-structured interviews areas follows. For the perceived benefits of the platform,the fact that it is used as a game was positively per-ceived. Furthermore, playing the games exposes theparticipants to secure coding tasks, which is also per-ceived as being beneficial. In therms of the embeddedprogramming group, some participants suggested thatthe platform might be used in a standard course at theuniversity, which might be beneficial for those whowork on security critical systems, e.g. in critical infras-tructures.Although most of the feedback was positive, we col-lected some drawbacks. The two main negative points
Table 6.
Quotes from Participants
No Quote from Participant Group are related with the user interface, and with the preci-sion of the feedback given by the virtual coach. Relatedto quotes 9 and 10, interviewees gave a more detailedanswer in our discussion. One interviewee said thathaving a standard debugging tool would ease the chal-lenges and increase the learning factor. As well to com-pete with other online learning platforms, more detailson the design have to be applied.The collected positive and optimistic answers in-dicate that participating in these challenges can po-tentialy lead to raising secure coding awareness inacademia. The answers are also encouraging towards . E. Gasiba, S. Hodzic, U. Lechner, and M. Pinto-Albuquerque validating the suitability of the proposed vulnerabilityassessment methods.
In this work we have presented the implementationand evaluation of cybersecurity challenges for the Sifuplatform. The implementation of the challenges coveredtechnical aspects on how to evaluate the presence of agiven vulnerability in source code, while the evaluationwas performed in several ways: computer experiments,survey, semi-structured interviews and comparison toprevious work.In terms of technical implementation, we have dis-cussed a mechanism to detect time side-channel, andrace conditions. The main idea for the detection of timeside-channel is to use a standard debugger, such as GDB,together with a wrapper and a python script to controlthe debugger. By stepping through the code, we canevaluate the number of steps that the algorithm wouldrequire to run from beginning to the end. In the resultssection we present practical advice for practitionerswho want to implement this method, in particular wediscuss about the trade-off between precision and exe-cution time. Notice that we propose a simplified methodto assess the presence of a time-side channel. In practice,other effects will impact the running time of the algo-rithm, such as number of cycles per instruction, hyper-threading, cache misses, and CPU internal pipelines,and therefore the presence of time-side channels. How-ever, although the proposed method is simple, it allowsto raise awareness on time-side channels through a se-rious game. Furthermore, the reason why we observehighly correlated results between the "step" and "stepi"method is related to the fact that the implemented al-gorithm mostly uses mathematical operations and nofunction calls.For the race condition vulnerability, we propose towrite a script that attacks the function written by theparticipant. We discuss the trade-off between probabil-ity of detecting the vulnerability and execution time.The reason why execution time is crucial, is that theSifu platform is an interactive platform. The higherthe delay in the backend, the less interactive the plat-form becomes, which could lead to problems with userexperience.One major finding in our survey results is the factthat the students claimed a lack of awareness on se-cure coding during courses at the university. While thisresult cannot be generalized to every university andevery course, it does raise the need to address this topic in general, as the students of today are the workforceof the future. The survey results also indicate that theSifu platform might be suitable to address this aware-ness in secure coding at the university. In particular,we have received positive indications that the platformcould be integrated into the standard teaching curricula.A comparison with two previous surveys performedin an industrial setting was also discussed. Both thestudies performed in the academia as also in the indus-try show encouraging results on the suitability of theplatform as a means to raise awareness on secure cod-ing. However, there are small differences between thesurveys that indicate small discrepancies. We believethat a practitioner who wishes to deploy or refine thesetypes of challenges in the academia, can find valuableinformation in these studies, to guide in their decisionmaking.
Possible threats to our conclusions include: number ofparticipants, study field and experience, and partici-pant bias. Our preliminary results are mostly positive.This might be related to the relatively low number ofparticipants to the survey, since it was not mandatory.Therefore, some negative comments might not havebeen been captured. Participants have different studyfields, backgrounds, and are at different levels in theirstudies. Although the number of participants is limited,it is in line with comparable empirical studies. There-fore, some participants might find the challenges easy,while other might have more difficulties to solve them.This might lead to different answers to the survey andalso to the semi-structured interview and, therefore.A more detailed analysis and research on the answersgiven by the different groups would be required to un-derstand possible bias effects.Finally, since the participants are aware of the pur-pose of the study, a positive bias cannot be discarded.In particular, participants might respond to the surveyin a way that they think the authors expect them toanswer. Nevertheless, the results obtained in this workare in alignment with previous work that was done inan industrial environment. Therefore, we do not thinkthat considerable different conclusions from the onespresented in this work would be obtained by increasingthe number of survey participants.
Security bugs, when exploited, often can lead to seri-ous software vulnerabilities. Nowadays, secure coding aising Security Awareness using Cybersecurity Challenges in Embedded Programming Courses guidelines exist to teach software developers and makethem aware of software vulnerabilities and how to writesecure code that avoids these vulnerabilities. However,not all software developers are knowledgeable aboutthese or secure coding standards in general. This is truefor the industry and, the present study also finds outthat this might also be true in academia.To address this issue, this work extends previousresearch conducted on the Sifu platform. We introducethree challenges with security vulnerabilities commonin embedded programming that can be integrated intouniversity teaching curricula. This paper consists of twomain parts: 1) a brief description of how to implementthe challenges in terms of evaluation of the presence ofthe vulnerability in the participant’s source code, and2) an evaluation of the challenge design and evaluationof the challenges in an academia setting.In the first part, three different C++ challenges wereimplemented on Sifu’s platform. The implementationprocess and decision-making were briefly explained. Acritical part of our work is how to test particular secu-rity vulnerabilities that are presented in the challenges.We give a detailed explanation of the architecture andthe implementation of testing particular vulnerabilities.In the second part, we evaluate the design from a tech-nical view, and an empirical view. Our results indicatethat the proposed methods can be used to detect thechallenges’ vulnerabilities. Additionally we give prac-tical advice on the implementation of the challenges.Through two trial runs in academia, we collected an-swers on a survey and performed a semi-structuredinterview. Our preliminary results give a good indica-tion that the challenges are adequate to raise securecoding awareness for students. Additionally the resultsfor the semi-structured interview give a positive indi-cation on the suitability of the challenges for academia,and give good insight into future improvements, e.g.on user experience. Finally, we have performed a com-parison with previous studies, thus comparing resultsfrom industry to results from academia. While the ma-jority of the results indicate a good agreement betweenindustry and academia, the small differences betweenboth can serve as a guide to practitioners who wish todeploy the Sifu platform in an academic setting.As further steps, the authors would like to investigatethe usage of popular open-source static code analysistools, and tapping system calls to improve the plat-form’s detection mechanisms. Furthermore, the authorswould like to address these tools’ usage to improve theplatform’s hint mechanism.
Acknowledgments
The authors would like to thank the survey participantsfor their useful and insightful discussions and for theirparticipation in the test run. This work is partially fi-nanced by national funds through FCT - Fundação paraa Ciência e Tecnologia, I.P., under the projects FCTUIDB/04466/2020 and UIDP/04466/2020. Furthermore,the fourth author thanks the Instituto Universitário deLisboa and ISTAR, for their support.
References [1] Richard Amankwah, Patrick Kudjo, and Samuel Yeboah. 2017.Evaluation of Software Vulnerability Detection Methods andTools: A Review.
International Journal of Computer Ap-plications
169 (07 2017), 22–27. https://doi.org/10.5120/ijca2017914750 [2] Apextechservices. 2017. NotPetya: World’s First $10 BillionMalware. https://tinyurl.com/y6mkok57 [3] Andrei Arusoaie, Stefan Ciobâca, Vlad Craciun, Dragos Gavri-lut, and Dorel Lucanu. 2017. A Comparison of Open-SourceStatic Analysis Tools for Vulnerability Detection in C/C++Code. In . IEEE,Timisoara, Romania, 161–168.[4] A. Arusoaie, S. Ciobaca, V. Craciun, D. Gavrilut, and D. Lucanu.2018. A Comparison of Static Analysis Tools for VulnerabilityDetection in C/C++ Code. Romanian National Authority forScientific Research and Innovation.[5] Bence Babati, Gábor Horváth, Viktor Májer, and NorbertPataki. 2017. Static Analysis Toolset with Clang. In
Proceed-ings of the 10th International Conference on Applied Informatics .ACAI, Eger, Hungary, 23–29.[6] Hanmeet Kaur Brar and Puneet Jai Kaur. 2015. Article: Com-paring Detection Ratio of Three Static Analysis Tools.
Interna-tional Journal of Computer Applications https://clang.llvm.org/index.html [8] Ralf Dorner, Stefan Gobel, Wolfgang Effelsberg, and JosefWiemeyer. 2016.
Serious Games: Foundations, Concepts andPractice . Springer, Cham, Switzerland. https://doi.org/10.1007/978-3-319-40612-1 [9] Tiago Gasiba, Kristian Beckers, Santiago Suppan, and FilipRezabek. 2019. On the Requirements for Serious Games gearedtowards Software Developers in the Industry. In
Conferenceon Requirements Engineering Conference , Daniela E. Damian,Anna Perini, and Seok-Won Lee (Eds.). IEEE, Jeju, South Korea,286–296. https://doi.org/10.1109/re.2019.00038 [10] Tiago Gasiba, Ulrike Lechner, and Maria Pinto-Albuquerque.2020. Sifu - A CyberSecurity Awareness Platform with Chal-lenge Assessment and Intelligent Coach.
Special Issue of Cyber-Physical System Security of the Cybersecurity Journal
3, 1 (102020), 1–23.[11] Tiago Gasiba, Ulrike Lechner, and Maria Pinto-Albuquerque.2021. CyberSecurity Challenges for Software Developer . E. Gasiba, S. Hodzic, U. Lechner, and M. Pinto-Albuquerque
Awareness Training in Industrial Environments.
16. Inter-nationale Tagung Wirtschaftsinformatik (2021), 1–17.[12] Tiago Gasiba, Ulrike Lechner, Maria Pinto-Albuquerque, andDaniel Mendez Fernandez. 2020. Awareness of Secure CodingGuidelines in the Industry - A first data analysis. In
TrustCom2020: International Conference on Trust, Security and Privacyin Computing and Communications . IEEE, Guangzhou, China,1–8.[13] Tiago Gasiba, Ulrike Lechner, Maria Pinto-Albuquerque, andAnmoal Porwal. 2020. Cybersecurity Awareness Platformwith Virtual Coach and Automated Challenge Assessment. In . Springer, Guildford,UK, 1–16.[14] Tiago Gasiba, Ulrike Lechner, Filip Rezabek, and Maria Pinto-Albuquerque. 2020. Cybersecurity Games for Secure Pro-gramming Education in the Industry: Gameplay Analysis. In
First International Computer Programming Education Confer-ence (ICPEC 2020) (OpenAccess Series in Informatics (OASIcs),Vol. 81) , Ricardo Queirós, Filipe Portela, Mário Pinto, and Al-berto Simões (Eds.). Schloss Dagstuhl–Leibniz-Zentrum fürInformatik, Dagstuhl, Germany, 10:1–10:11.[15] Norman Hänsch and Zinaida Benenson. 2014. SpecifyingIT security awareness. In . IEEE, Munich,Germay, 326–330.[16] Ankur Joshi, Saket Kale, Satish Chandel, and D Kumar Pal.2015. Likert scale: Explored and explained.
Current Journal ofApplied Science and Technology .IEEE, Madrid, Spain, 1–8.[18] Shane McIntosh, Yasutaka Kamei, Bram Adams, and Ahmed EHassan. 2016. An empirical study of the impact of moderncode review practices on software quality.
Empirical SoftwareEngineering
21, 5 (2016), 2146–2189.[19] Carnegie Mellon. 2020. SEI CERT Coding Standards. https://wiki.sei.cmu.edu/confluence/display/seccode
Online. Ac-cessed 19 November 2020.[20] MITRE. 2020. Common Weakness Enumeration: CWE. https://cwe.mitre.org/
Online. Accessed 25 November 2020.[21] Dimitris Mitropoulos, Vassilios Karakoidas, Panos Louridas,Georgios Gousios, and Diomidis Spinellis. 2013. Dismal code:Studying the evolution of security bugs. In { LASER } { LASER } , Vol. 49. USENIX, New York, United States,37–48.[22] Jonathan Moerman, Sjaak Smetsers, and Marc Schoolderman.2018. Evaluating the performance of open source static analy-sis tools. Bachelor Thesis, Radboud University, The Netherlands
24 (2018), 1–66.[23] Reza Montasari, Amin Hosseinian-Far, Richard Hill, FarshadMontaseri, Mak Sharma, and Shahid Shabbir. 2018. Are Timing-Based Side-Channel Attacks Feasible in Shared, Modern Com-puting Hardware?
International Journal of Organizational andCollective Intelligence https://doi.org/10.4018/ IJOCI.2018040103 [24] Tosin Daniel Oyetoyan, Bisera Milosheska, Mari Grini, andDaniela Soares Cruzes. 2018. Myths and facts about staticapplication security testing tools: an action research at Te-lenor digital. In
International Conference on Agile SoftwareDevelopment . Springer, Cham, Switzerland, 86–103.[25] Andrew Ruef, Michael Hicks, James Parker, Dave Levin,Michelle L Mazurek, and Piotr Mardziel. 2016. Build it, breakit, fix it: Contesting secure development. In
Proceedings of the2016 ACM SIGSAC Conference on Computer and Communica-tions Security . ACM, New York, United States, 690–703.[26] François-Xavier Standaert. 2010. Introduction to side-channelattacks. In
Secure integrated circuits and systems . Springer,Boston, MA, 27–42.[27] Madiha Tabassum, Stacey Watson, Bill Chu, and HeatherRichter Lipford. 2018. Evaluating Two Methods for Inte-grating Secure Programming Education. In
Proceedings ofthe 49th ACM Technical Symposium on Computer Science Ed-ucation . ACM, New York, United States, 390–395. https://doi.org/10.1145/3159450.3159511 [28] Mohammad Tahaei and Kami Vaniea. 2019. A Survey onDeveloper-Centred Security. In . IEEE,Stockholm, Sweden, 129–138.[29] Yu Wang, Linzhang Wang, Tingting Yu, Jianhua Zhao, andXuandong Li. 2017. Automatic Detection and Validation ofRace Conditions in Interrupt-Driven Embedded Software. In
Proceedings of the 26th ACM SIGSOFT International Symposiumon Software Testing and Analysis (Santa Barbara, CA, USA) (ISSTA 2017) . Association for Computing Machinery, New York,NY, USA, 113–124. https://doi.org/10.1145/3092703.3092724 [30] Michael Whitney, Heather Richter Lipford, Bill Chu, and TylerThomas. 2017. Embedding Secure Coding Instruction Into theIDE: Complementing Early and Intermediate CS Courses WithESIDE.
Journal of Educational Computing Research
56 (05 2017),073563311770881. https://doi.org/10.1177/0735633117708816 [31] Chauncey Wilson. 2014.
Semi-Structured Interviews . Elsevier,Boston, 23–41. https://doi.org/10.1016/B978-0-12-410393-1.00002-8 [32] Chen Yan, Xu Xiaofeng, Li Xiaochao, and Guo Donghui. 2010.Race Condition and Its Analysis Approach of Real-time Embed-ded Systems.
Journal of Computer Research and Development
47, 7, Article 1201 (2010), 9 pages. http://crad.ict.ac.cn/EN/abstract/article_1751.shtml [33] Tianyi Zhang, Ganesha Upadhyaya, Anastasia Reinhardt,Hridesh Rajan, and Miryung Kim. 2018. Are code examples onan online Q&A forum reliable?: a study of API misuse on stackoverflow. In . IEEE, New York, United States,886–896.[34] Z. Zhioua, Y. Roudier, S. Short, and R. B. Ameur. 2016. Secu-rity Guidelines: Requirements Engineering for Verifying CodeQuality. In . IEEE, Beijing, China, 80–85.. IEEE, Beijing, China, 80–85.