Zequn Huang

Chien-Chung Shen

Sheetal Doshi

Nimmi Thomas

Ha Duong

Cognitive Task Analysis Based Training for Cyber Situation Awareness

Keywords: Cognitive Task Analysis, Cyber Situation Awareness, Cyber Situation Awareness Training Scenario

Cyber attacks have been increasing significantly in both number and complexity, prompting the need for better training of cyber defense analysts. To conduct effective training for cyber situation awareness, it becomes essential to design realistic training scenarios. In this paper, we present a Cognitive Task Analysis based approach to address this training need. The technique of Cognitive Task Analysis is to capture and represent knowledge used by experts to perform complex tasks. Accurate characterization of cyber security experts' cognitive processes can be incorporated into training materials to teach novice cyber analysts how to think and act like experts. After performing Cognitive Task Analysis of cyber situation awareness, we identify the steps necessary for designing training scenarios and training workflows. In order to address the challenge of information overload confronting the cyber analysts, we identify and design attack-specific watch list items. During training, cyber analysts can tailor their own watch list items and triggering thresholds in order to detect cyber attacks faster. As the time it takes for cyber analysts to recognize, analyze, and respond to attacks is critical, we evaluate cyber analysts' performance based on their response time compared with the ideal attack timeline.

Introduction

Cyber attacks, which refers to any computer-to-computer attacks that undermine the confidentiality, integrity, or availability of computer or information resident on it, have increased significantly in number and in complexity in recent years. Typically, a cyber attacker first exploits a system's vulnerabilities and infiltrates its network and/or hosts. Once the attacker gained entrance into the system, he may use it to monitor communications, steal critical data, discover new avenues of attack in related systems, take control of assets managed by the system or disable vulnerable networks, computers, and associated systems. Harmful outcomes of a successful attack include the attacker's ability to access sensitive data on the network and to control the hosts and network resources.

Situation awareness involves perception of evolving status and attributes of elements, comprehension of combined observations to evaluate the current situation in order to make predictions of possible future outcomes based on past experience and knowledge. Specifically, situation awareness in the cyberspace (Cyber Situation Awareness [START_REF] Jajodia | Cyber Situational Aware-ness: Issues and Research[END_REF][START_REF] Kott | Cyber Defense and Situational Awareness[END_REF], or CSA for short) is an immensely cognitive task which is embedded in a large multi-layered sociotechnical system of cyber analysts, computers, and networks. In CSA, cyber analysts have to collect data and seek cues that form attack tracks, estimate impact of observed attack tracks, and anticipate moves (actions, targets, time) of attackers. Presently, effective performance in CSA is hampered by the enormous size and complexity of the network, by the adaptive nature of intelligent adversaries, by the high number of false alarms generated by intrusion detection systems, by the lack of ground truth to assess defense performance, by organizational stove-pipes thwarting collaboration, and by technologies that lack an adequate understanding of the human needs.

In particular, in contrast to environments that are bounded by physical constraints and/or geographical features, cyberspace possesses the following unique features which further impose extraordinary cognitive challenges on cyber analysts. First, while a cyber analyst is fully aware of the boundaries of his/her managed networks, the external cyberspace is boundless with minimal geographical features. As a result, the environment from which a cyber analyst has to perceive salient cues is vastly larger and more difficult to comprehend. Comprehending even a small segment of cyberspace is challenging. Second, the speed at which the cyberspace changes is much faster, where new vulnerabilities and their corresponding exploits are continuously emerging, and new offensive technologies are constantly being developed. Furthermore, modern exploits are either employed via misdirection (e.g., a DDoS attack is conducted by a Botnet of compromised computers) or delivered passively via embedded malware. Third, everything a cyber analyst knows about the environment is a virtual representation of the cyberspace in terms of digital information (e.g., intrusion alerts and firewall logs). In addition, the cyber analyst only sees the information that his/her (software) sensors are capable of detecting in a form that can be rendered on monitor screen. Because perception and comprehension of cyberspace is inherently constrained by technology artifacts, cyber analysts' ability to develop situation awareness is greatly limited by the degree to which the network's sensors are correctly configured and capturing data. Furthermore, cyber analysts are faced with extraordinary amounts of information (such as various IDS and audit logs) to sift through, and CSA demands that various pieces of information be connected in both space and time. This connection necessitates team collaboration among cyber analysts working at different levels and on different parts of the system. It is anticipated that team CSA can be carried out to systematize information coordination and team collaboration for CSA effectiveness and resilience. As cyber attacks are becoming more frequent and more complex, the need for more effective training of cyber ana-lysts and their collaborative efforts to protect critical assets and ensure system security is also elevated.

Cognitive Task Analysis (CTA [START_REF] Mahoney | A Cognitive Task Analysis for Cyber Situational Awareness[END_REF]) is the extension of traditional task analysis techniques to yield information about the knowledge, thought processes and goal structures that underlie observable task performance. The outcome of CTA describes the performance objectives, equipment, conceptual knowledge, procedural knowledge and performance standards used by experts as they perform a task. Accurate identification of cyber security experts' cognitive processes can be adapted into training materials to teach novices how to perform like experts. In this paper, we present a solution for cyber training which uses a CTA based approach to gain insight into the cognitive demands and workflow of cyber analysts and design cyber security training scenario and training workflow. Then, we evaluate cyber analysts' performance based on their response time of detecting cyber attacks comparing with estimated attack ideal timeline.

The remainder of the paper is organized as follows: Section 2 describes related work and background. Section 3 introduces the Cyber security training and assessment framework infrastructure. In Section 4, we identified the steps necessary for designing cyber security training scenarios and training workflow after performing Cognitive Task Analysis. Section 5 describes two cyber security training scenarios. The scoring algorithm to evaluate the performance of cyber defense analysts is presented in Section 6. To evaluate the usability of the training system, Section 7 presents the questionnaire that cyber analysts are asked to answer in order to evaluate the cognitive validity of training. Finally, Section 8 concludes the paper.

Related Work and Background

General reviews of current simulation-based cyber security training systems are given in [START_REF] Pastor | State-of-the-art simulation systems for information security education, training and awareness[END_REF]. CyberCog [START_REF] Rajivan | CyberCog:A Synthetic Task Environment for Measuring Cyber Situation[END_REF] is a synthetic task environment for understanding and measuring individual and team situation awareness, and for evaluating algorithms and visualization intended to improve cyber situation awareness. Cy-berCog provides an interactive environment for conducting human-in-the-loop experiment in which the participants of the experiment perform the tasks of a cyber analyst in response to a cyber attack scenario. CyberCog generates performance measures and interaction logs for measuring individual and team performance. CyberCog has been used to evaluate team-based situation awareness. CyberCog utilizes a collection of known cyber defense incidents and analysis data to build a synthetic task environment. Alerts and cues are generated based on emulation of real-world analyst knowledge. From the mix of alerts and cues, trainees will react to identify threats (and vulnerabilities) individually or as a team. The identification of attacks are based on knowledge about the attack alert patterns.

Designed for better understanding of the human in a cyber-analysis task, id-sNETS [START_REF] Giacobe | Capturing human cognition in cyber-security simulations with NETS[END_REF], built upon the NeoCITIES Experimental Task Simulator (NETS), is a human-in-the-loop platform to study situation awareness for intrusion detec-tion analysts. Similar to CyberCog, NETS is also a synthetic task environment. The realistic scenarios are compressed and written into scaled world definitions and the simulation engine is capable of interpreting the scaled world definitions into a simulated environment, running the simulation, and responding to user interaction. In [START_REF] Giacobe | Capturing human cognition in cyber-security simulations with NETS[END_REF], several human subjects experiments have been performed using the NETS simulation engine, to explore human cognition in simulated cyber-security environments. The study indicates that the teams who had more similar skill sets displayed a more cohesive collaboration via frequent communication and information sharing. The main difference between CyberCog/IdsNETS and LVC framework ( Live-Virtual-Constructive [START_REF] Varshney | A Live-Virtual-Constructive (LVC) framework for cyber operations test, evaluation and training[END_REF]) is that while CyberCog and IdsNETS are synthetic task environments, the LVC framework is an actual simulator/emulator. A synthetic task environment may rely on previous incidents to generate the sequence of alerts and cues corresponding to those incidents, The LVC framework is able to simulate previous incidents as well as generate new simulated or emulated incidents on the fly. The LVC framework supports a hybrid network of actual and virtual machines so that attacks can be launched from an actual or a virtual host, targeting an actual or a virtual host. Figure 1 illustrate the usage examples of the LVC framework that combines physical machines and virtual network environment to perform cyber attacks and defense.

Cyber Situation Awareness Training and Assessment Framework Infrastructure

The system infrastructure for the proposed Cyber Situation Awareness training and assessment framework is shown in Figure 2. As shown in the figure, lesson database contains different kinds of cyber attack scenarios with different difficulty levels. We apply Cognitive Task Analysis on a set of tasks and use the information to generate scenarios for training purposes. For each task, we identify major events and watch list items needed for decision making. The trainees are able to to tailor their watch list and triggering threshold conditions. With the proceeding of training scenario, data such as IDS log, network flow, and trainee specified trigger alerts will be reported to the trainee. After analyzing these data, the trainee should think whether it is an attack or false alarm based on prior knowledge and decide the type of attack through attack model matching. Interactions and team discussions can be conducted through the Shared Events Viewer and team communication module. If the team members still cannot achieve agreement, the fuzzy logic based team consensus decision making module can help chose the most acceptable solution for the entire team.

The assessment metrics will include trainee response time with respect to critical cues and evaluate the actions taken or decisions made to determine potential attacks. By comparing trainees' response time and estimated attack ground truth timeline, we can identify if the response is fast or slow. The performance evaluation module can provide performance score and feedback to trainees, as well as adjust the next training lesson's difficulty level based on trainees' performance. Furthermore, Situation Awareness Global Assessment Technique (SAGAT) is used to get feedback from trainees in order to evaluate training system usability and effectiveness.

Cyber Situation Awareness Training Scenarios Design

We propose realistic training scenarios for Cyber Situation Awareness training and assessment based on the LVC framework, which enables cyber analysts to experience cyber attacks and to learn how to detect ongoing cyber attacks. Designing cyber security lessons to involve cyber analysts in activate learning requires careful planning. Cognitive Task Analysis technique [START_REF] Cooke | Perspectives on the Role of Cognition in Cyber Security[END_REF] is a prominent approach that captures knowledge representation used by experts to perform complex tasks. We utilized a combination of three knowledge capture techniques: observing cyber security competitions, examining critical incidents, and reviewing relevant papers of structured interviews with cyber security experts and information assurance analysts [START_REF] D'amico | Achieving Cyber Defense Situational Awareness: A Cognitive Task Analysis of Information Assurance Analysts[END_REF]. We elicit the knowledge about how, when, where, and why when performing cyber defense task. This knowledge can be applied into design consideration for cyber security training scenarios.

Notice that human cyber analysts have to check thousands of events each day from many sources such as system logs, configurations, traffic logs, IDS log, and audit logs in order to determine whether there are real attacks or false positives; Based on the design steps, the training workflow is shown in Figure 3, which contains the following steps:

Step 1 : Instructor creates a training scenario for the cyber security training that includes a cheat sheet for the cyber attack/defense aspect based on the lesson objective. The Cheat Sheet includes the watch list items critical to the cyber attack and the attack ideal timeline denoting the attack start and success time. Cyber analyst should react to the cyber events in simulation and perform certain actions that demonstrate his/her understanding of cyber attacks.

Fig. 3: Workflow for training system

Step 2 : Instructor sets up training scenario with the tool providing the widgets to enable the instructor to enter in the information from the cheat sheet.

Step 3 : When training scenario begins, the specified trigger alert and other log data specified by cyber analyst will be sent to cyber analyst side. After analyzing these data, cyber analyst should think whether it is an attack or false alarm based on prior knowledge and decide the type of attack through attack model matching.

Step 4 : During the training, with cyber analyst's actions being logged continuously, the training system can determine whether the response actions of cyber analyst are following the ideal timeline enumerated by instructor in the cheat sheet.

Step 5 : Based on cyber analyst's response and the ideal timeline, the score for cyber analyst will be computed using devised scoring mechanisms, and provided to cyber analyst as part of after action review.

Step 6 : After obtaining performance assessment report, cyber analysts should think about selecting different watch list items or improving analysis capability for the next lesson.

Based on the tailored lesson scenario, cyber analyst will learn the knowledge required to monitor network conditions and identify ongoing attacks. After completing the cyber security training, cyber analysts will be able to do the following with respect to a given set of known attacks:

-List the relevant parameters to monitor and know the characteristics of these parameters under normal and abnormal operations. -Recognize symptoms of network attacks. Specifically, cyber analyst will be able to isolate common characteristics of network under attack and be able to distinguish the characteristics that are particular to each attack.

-Given a particular set of current conditions (monitored parameters), be able to analyze what kind of attack is occurring and how the attack was launched. -Demonstrate proper procedure of remedial actions, including selection of countermeasures to apply and where in the network to apply them.

Cyber Situation Awareness Training Scenarios

Guided by the lesson design steps and goals of cyber security training, we propose port/network scan and denial of service cyber security training scenarios for the Cyber Situation Awareness training and assessment system.

Port/Network scan Training Scenario

Usually an attacker first attempts to obtain information concerning a network in order to choose the following malicious actions. Specifically, after network scan, an attacker is able to discover the number of hosts, the IP addresses and the network topology. The next step an attacker may take is to perform a port scan [START_REF] Panjwani | An Experimental Evaluation to Determine if Port Scans Are Precursors to an Attack[END_REF] to discover which hosts are critical and what services are running on the various hosts. The obtained information can be used by an attacker to plan attack attempts targeting various vulnerabilities. An example of lesson scenario on how to perform network and port scan is illustrated in Figure 4. Initially, the core gateway router is configured without firewall. Before performing a network scan, the "inside" network is not visible to the outside world. The attacker then attempts to obtain information on the internal network by launching a network scan. Without firewall protection at the router, the network scan is able to discover the number of hosts, IP addresses and the network topology by sending a bunch of probe packets. Once an attacker learns the IP addresses of hosts and network connectivity, he/she can launch port scan to discover applications such as web server, FTP server running on the hosts and other devices connected to the hosts.

For the purpose of facilitating cyber analysts' analysis, we define network scan as a procedure for identifying active hosts on a network. After observing the network traffic that contains certain numbers of distinct probes within a short period of time from a single anomalous source, it might be a potential network scan attack. The port scan is defined as an attack that sends requests to a range of server port addresses on a host with the goal of finding open ports and corresponding services running on the ports. By observing several requests to a range of port addresses, it might be a potential port scan attack.

Denial of Service Training Scenario

Denial of Service (DoS [START_REF] Sekar | LADS: Largescale Automated DDOS Detection System[END_REF]) attacks aim at stopping the target system from working properly through recruiting a large number of "zombie" machines to send high volumes of ordinary traffic. The DoS lesson objective is to train cyber analysts to understand DoS attacks and their detection methods. In this lesson, we will study three types of DoS attacks:

-Basic DoS attack: the attackers send large volume of UDP traffic to the victim host or network. Such traffic consumes network bandwidth, buffer memory as well as CPU resources. -TCP SYN DoS attack: the attackers send TCP SYN packets to the victim host. Each TCP SYN packet opens a new TCP connection at the victim computer; thus, consuming transport-layer resource. -IP Fragmentation DoS attack: the attackers send partially fragmented IP packets to the victim host. The victim computer buffers these fragmented packets and wait for remaining segments.

To identify DoS attacks, cyber analysts first need to differentiate attacks from normal bursts of network requests in order to reduce the rate of false alarms. Therefore, we need to compare burst requests with behavior of normal requests. In general, requests from DoS attacks share the same target, such as tens of thousands requests are trying to access a specific address. Once cyber analysts identify the incoming requests are indeed DoS attacks, the next information cyber analysts need to acquire is what kind of DoS attack it is and what attack techniques it is employing. Since cyber analysts already know about the details of the requests from the system logs, cyber analysts can determine the type of DoS attacks and then take corresponding defending actions.

As introduced previously, cyber analysts should consider three DoS attack scenarios: basic DoS attack, TCP SYN DoS attack, and IP Fragmentation DoS attack. Basic DoS attacks involve sending a large volume of traffic to the host, exhausting the host's processing and memory resources and making unable to serve more normal traffic. As a result of sharp increasing in the size of memory and CPU usage of server hosts. TCP SYN attack happens when attackers send a flood of TCP/SYN packets with faked sender addresses. Each packet is treated as a connection request and the server maintains a half-open connection for each request. The server send TCP/SYN ACK packets back to the faked senders and waits for the responses. Since the sender addresses are faked, the responses will never come. And the number of half-open connections quickly saturate the buffer resources of the server, rendering it unable to serve future legitimate requests. Another technique of DoS attack is via IP fragmentation. Observing larger IP fragments in the IP buffer indicate the potential IP Fragmentation DoS attack. Fig. 5: DoS lesson scenario Figure 5 shows an example DoS exercise scenario, which includes nine "zombie" machines that can send high volumes of ordinary traffic to the target victim machine. An attack targeting at the HTTP server typically involves sending a large number of requests, each of which consumes significant resources. This then limits the ability of the server to respond to requests from other users. Besides, HTTP requests may make database queries. When costly queries are constructed, a large number of requests could severely overload the server and limit its ability to respond to legitimate requests. The attackers can start either one of the three types of DoS attacks. The magnitude and difficulty level of the exercise scenario can be controlled by the number of "zombie" machines as well as traffic volume.

To perform DoS attack detection, traffic flow monitoring is the key. Example watch list items about system information and traffic flow include CPU and memory resource usage, number of incoming flows, and aggregated traffic rate as shown in Table 1.

Performance Metrics and Scoring Algorithms

To monitor the activities of and provide feedback to a cyber analyst during training sessions, we adapt the method of timeline analysis for performance assessment. The ideal timeline of a training exercise is gauged based on the specific attack scenario and its configuration. After a training exercise starts, all of an cyber analyst's actions are continuously logged so that the training system can determine whether actions taken by the cyber analyst follow the ideal timeline and match the expected activities. This evaluation can be provided as feedback to the cyber analyst during training. For instance, if a cyber analyst fails to identify attacks in time, the system can proactively provide hints to the analyst, or share the views of other cyber analysts. A cyber analyst may also ask for hints from the instructor. The performance of a cyber analyst is evaluated based on the response time of correctly identifying specific cyber attacks. Fig. 6: Use memory usage metric to gauge ideal timeline for a DoS attack Figure 6 depicts how the measurement of memory usage can be used to characterize the ideal timeline for a DoS attack. The time period is divided by two memory usage thresholds into three phases: before attack, during attack, and after successful DoS attack. Based on the pre-defined memory usage thresholds and the DoS training lesson's configuration (such as the number of packets to be sent, the frequency of sending packets, the start and end times), a DoS attack's start time and its time of successful attack can be determined. Similarly, the method can be applied to other DoS metrics such as CPU usage, number of incoming flows, and aggregated traffic rate to generate their corresponding timelines. By combining these timelines together, an ideal timeline for the DoS attack can be generated.

Based on the response of cyber analysts and the ideal timeline, scores for the performance of cyber analysts can be computed using the devised scoring mechanisms, and provided to the cyber analysts as one component of their after action review. By comparing cyber analysts' response time against the ideal timeline, we can determine whether a cyber analyst responds in a timely manner. For instance in Figure 6, assuming a DoS attack starts at time 10 second and sustains for 35 seconds, and the victim host shuts down at time 45 second due to DoS attack, cyber analyst has a time window of 35 seconds to identify the ongoing DoS attack. If cyber analyst identifies this DoS attack at time 20 second, cyber analyst's response is considered fast enough to score a higher point. In contrast, if cyber analyst does not identify the DoS attack until the victim host shuts down, no point will be given.

To evaluate the performance of cyber analysts, a set of performance metrics has been adopted:

-Lesson magnitude and difficulty levels (W D ): stands for the severity of attacks or the difficulty level of achieving an attack goal. A scenario's difficulty level is specified in one of three categories: high, medium, or low. -Response time (W T ): measures cyber analysts' responsiveness to correctly recognizing cyber attacks. -Correct detection of attacks (W C ): identifies the existence of a real attack and its type. -Damage impact (W I ): measures attacks' impact on victim's confidentiality, integrity, and/or availability.

Based on the performance metrics, the performance score of cyber analysts can be calculated by the following formula:

Score = W D * ( k∈{T,C,I} W k * K k )
where K k , k ∈ {T, C, I} is the weight factor for each performance metric. Notice that the lesson difficulty level W D is separated from other performance metric during score calculation. This is because the more difficult of the lesson, the higher score is given since cyber analysts have to spent more time and effort to perform the defense task. For the purpose of consistent computation, each weight factor is normalized to the value between 0 and 1. Take difficulty level W D as an example, training lesson labeled with "Low" difficulty has weight factor value 0.4 and "Medium" difficulty training lesson is given weight value 0.7.

Evaluate Cognitive Validity of Training

In order to evaluate the usability of the training system and the effectiveness of training, Situation Awareness Global Assessment Technique (SAGAT [START_REF] Endsley | Situation awareness analysis and measurement[END_REF]) is used. SAGAT covers the three levels of CSA including Level 1 (perception of data), Level 2 (comprehension of meaning), and Level 3(projection of the near future). Typically, a set of CSA queries regarding the current situation is asked and participants are required to answer each query based upon their knowledge and understanding of the situation at that point. The questions to be asked are as follows:

Conclusion and Future Work

Accurate characterization of cyber security experts' cognitive processes can be adapted into training materials. In this paper, we described two cyber security training scenarios: port/network scanning and denial of service after performing Cognitive Task Analysis. We also defined the metrics for performance evaluation and the corresponding scoring algorithm. For a comprehensive CSA training system, it is more than just an abstract notion of how well people respond to attacks, but also, evaluates on the basis of how damaging certain attacks are, how long it takes for those attacks to manifest themselves, and how quickly recovery needs to take place in order to restore service to acceptable levels.

Fig. 1 :

 1 Fig. 1: Usage example of Live-Virtual-Constructive (LVC) framework

Fig. 2 :

 2 Fig. 2: CSA Training and Assessment System Infrastructure

Fig. 4 :

 4 Fig. 4: Port/network scan lesson scenario

1 .

 1 CSA related queries (a) An IDS alert based on traffic from 192.168.2.42 destined to 192.168.1.252 is best classified as? (b) Which watch list item is abnormal? (c) Is it an attack or false alarm? (d) What is the impact for the current attack? Any confidentiality, integrity, or availability loss? (e) What actions should be performed to stop this attack? 2. Participant satisfaction (a) Is the training tool easy to use? (b) Is the information displayed in a way that is easy to comprehend? (c) Does the tool provide information needed to achieve lesson goals? (d) Are the lesson contents at the appropriate difficulty level for the cyber analysts? (e) Are the hints useful? 3. Knowledge acquisition (a) Does the cyber analysts grasp the main objectives of the lesson? (b) Does the lesson learned lead to intended decision-making skills? 4. Behavior changes (a) How does the acquired knowledge affect the cyber analysts in future operations? (b) Will the cyber analysts be able to detect and identify DoS attacks faster?

Table 1 :

 1 DoS exercise watching list

	CPU Utilization	CPU utilization is calculated by CPU load as a percentage of the CPU capacity
	Memory Usage Memory consumed during certain period
		-Network-FIFO,Total packets queued
		-Network-FIFO,Average queue length
		-Network-FIFO,Longest time in queue
		-IP,Number of IP Fragments received
		-IP,Number of IP Fragments dropped
	Network Traffic	-IP,Buffer Size -UDP, Number of packets received
		-UDP, Number of bytes received
		-TCP, Number of packets received
		-TCP, Number of bytes received
		-TCP, Number of SYN packets received
		-TCP, Number of SYN ACK packets sent

Acknowledgements

This material is based upon work supported by US Army Research Office under contract W911NF-14-C-0140. Any opinions, findings and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the US Army Research Office.


Audun Jøsang
email: josang@ifi.uio.no

Marte Ødegaard
email: marte.odegaard@bekk.no3nsense

Erlend Oftedal
email: erlend@oftedal.no

Cybersecurity Through Secure Software Development

Keywords: Cybersecurity, Security education, Waterfall model, Agile model, Secure agile, Secure software development

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Digitization of business processes and services entails huge savings and increased efficiency. To be sustainable, this development must not at the same time introduce serious security vulnerabilities, but unfortunately it often does. The exposure surface to criminals and other malicious players increases by several orders of magnitude when business processes migrate completely or partially to online platforms. This global exposure to security threats makes it natural to use the term cybersecurity in the sense of protecting assets (information, systems and business processes) that directly or indirectly are connected to the Internet. Robust cybersecurity at all levels is necessary for maintaining a balanced risk profile in a digital economy.

Achieving a secure ICT infrastructure obviously requires that it is designed, built and operated by people who understand the threats, know the security requirements and have the skills to build and operate secure systems in general.

Security vulnerabilities in software are typically caused by programmers or teams with inadequate skills in secure software development. Unfortunately, thousands of IT designers and experts around the world are lacking security skills precisely because cybersecurity was not part of the study program they followed at the university. The expanding ICT infrastructure worldwide is being built by IT experts with IT degrees from universities and colleges, but unfortunately many IT experts still have insufficient security understanding and expertise. This is an unacceptable situation.

As an analogy, it would of course be irresponsible and even unthinkable to educate building architects and civilly engineers without giving them adequate knowledge about fire safety, otherwise the buildings in which we work and live would be full of firetraps. Likewise it is irresponsible to offer IT programs at universities without compulsory modules in information security. Unfortunately, still today many IT graduates leave university and go into industry without any competence in information security. Despite their great skills in programming and IT design, without skills in security these IT graduates will necessarily build vulnerable IT solutions.

This paper discusses how cybersecurity can be strengthened, not by investing in more sophisticated attack detection and malware filtering tools, but by ensuring that the very foundation of the ICT infrastructure is designed and built for strong security and robustness. This can only be achieved by by ensuring that secure system design becomes a natural element in all development projects, and by encouraging, stimulating and maybe forcing technical colleges and universities to integrate mandatory security modules in the curriculum of their IT education programs.

Patterns of Cybersecurity

There are currently available on the market a large number of tools and services for strengthening cybersecurity. Vendors range from large and highly profiled companies to small and relatively unknown companies. Some security products are promoted to stop APTs (Advanced Persistent Threats). Other products are promoted to detect and stop singular zero-day attacks or to filter out malware. Intrusion detection and prevention can be bought as a system or as a service. Security governance frameworks such as COBIT 4 , ITIL 5 , ISO 27001 [6] and NIST SP-800-53 [8] can be adopted and applied by in-house security management staff or by external consultants to ensure that the organisation is managed according to best practice with regard to security. However, none of these tools, services and frameworks -neither in isolation, nor in combination -are sufficient to avoid serious cyber-vulnerabilities of the kind that e.g. Heartbleed, Shellshock and BadUSB represent.

There seems to be no approach that can provide the level of security assurance that governments and corporate managers aim for. In a recent article it is argued that the cybersecurity product market is different from other markets where a few players typically dominate the market [START_REF] Ross | Whiz Bang[END_REF]. However, for cybersecurity there is no single vendor -not even a set of major vendors -who dominate the cybersecurity market, and from which general cybersecurity solutions can be bought. This simple analysis indicates that cybersecurity does not lend itself to a packaged solution [START_REF] Ross | Whiz Bang[END_REF].

It is up to the CISO (Chief Information Security Officer) or a similar executive in organisations to set up and run the cybersecurity program as they see appropriate, but since there is no commonly approved product, service or program that can provide waterproof cybersecurity, this task is particularly challenging. Even when following industry best practice there will be vulnerabilities that attackers can exploit to mount successful attacks. In this situation, when a serious security incident occurs, although there often is little the CISO could have done to prevent the incident, the CISO is the obvious target of blame anyway [START_REF] Perlroth | A Tough Corporate Job Asks One Question: Can You Hack It?[END_REF]. In a study by the Ponemon Institute focusing on the role of the security manager within companies, many of the CISOs who took part in the study rated their position as the most difficult in the organization. Most of CISOs questioned said their job was a bad one, or the worst job they had ever had [START_REF]Understaffed and at Risk: Today[END_REF].

Vulnerability management is an important branch of security management in organisations. Commonly known vulnerabilities are assigned unique identities under the CVE (Common Vulnerabilities and Exposures) scheme started by MITRE Corporation in 1999, with funding from the National Cyber Security Division of the US Department of Homeland Security. CVE IDs are used in SCAP (Security Content Automation Protocol) which is a protocol used by vulnerability management tools. A complete list of CVE IDs can be found on MITRE's CVE system as well as in the US National Vulnerability Database. Prominent software vendors can become a CNA (CVE Numbering Authority) for their products, and each CVE IDs is actually assigned by a CNA. There are three primary types of CNAs:

-The MITRE Corporation functions as Editor and Primary CNA.

-Various CNAs assign CVE IDs for own products (e.g. Microsoft, Oracle, Red Hat).

-Red Hat also provides CVE numbers for open source projects that are not a CNA.

The original CVE-ID format had just four digits for numbering vulnerabilities per year, such as CVE-2014-0160 which identifies the Heartbleed vulnerability. Only allowing 9,999 vulnerabilities per year was seen as a limitation, so that from 2014 the CVE-ID format can have five, six or more end digits to identify an arbitrarily large number of vulnerabilities each year. Figure 1 shows the number of identified vulnerabilities in the CVE scheme during the last 15 years. The trend seen on Figure 1 is that the number of vulnerabilities is increasing. There is also a wide range of different vulnerability types, and efforts have been made to provide classifications, taxonomies and ontologies for security vulnerabilities [START_REF] Pascal | Handbook of Science and Technology for Homeland Security, Classes of vulnerabilities and attacks[END_REF]. One purpose of vulnerability classification is to identify weaknesses in the SDLC (Software Development Lifecycle) in order to avoid vulnerabilities in the first place.

It is of course impossible to completely avoid generating security vulnerabilities during system and software design. However, the state of cybersecurity can be significantly improved by reducing both the number and the severity of security vulnerabilities generated. The then is how best to work towards this goal. Several approaches are already used to this end, such as automatic methods that can do code analysis and fuzzing to discover and eliminate vulnerabilities before setting code into production. The most important approach is to follow principles for secure software development, and to ensure that software designers have sufficient security expertise. We discuss the latter approaches below.

Software Development Lifecycle

Several software development models or approaches have been proposed and applied during the last 30 years. Each model has its characteristics, advantages and disadvantages, but common to them all is that they are typically not focusing on security [START_REF] Harris | CISSP All-in-One Exam Guide[END_REF] (p.1111). A selection of five prominent development models are briefly analysed and compared in [START_REF] Munassar | A Comparison between Five Models of Software Engineering[END_REF]. These are:

-Waterfall model -Iteration model -V-shaped model -Spiral model -Agile model, aka. XP (Extreme Programming).
The waterfall model is the classical and most heavy-weight approach to software development, whereas the agile model is the most light-weight and flexible approach. We will briefly describe the waterfall and agile models, as they represent very different approaches to secure programming. Figure 2 shows the waterfall model. The basic idea behind the waterfall model is that the tasks of each phase must be fully completed before the next phase, which is symbolized by the waterfall metaphor where water only flows downwards. This also implies that the complete set of requirements must be defined and fixed at the beginning of the project. In case it is necessary to revisit a previous stage, then a costly overhead is to be expected (metaphorically make water flow upwards), so this should be avoided. However, it is typically the case that requirements have to be changed in the middle of a software development project, so that many software development projects based on the waterfall model have suffered large blow-outs in cost and time.

As a reaction to the rigid structure of the waterfall model several other models have been proposed, where the most recent and radical is the agile model (also known as XP: eXtreme Programming) illustrated in Figure 3 below. The basic idea behind the agile model is that new or evolving requirements can be specified in parallel with, or after already implemented requirements [START_REF] Beck | Manifesto for Agile Software Development[END_REF]. This is possible by splitting the development into separate stories where each story covers a set of requirements implemented as functions that can be developed and tested more or less independently of other stories. Each cyclic iteration in the agile model is a sprint which can be completed in only a few weeks. The major drawback of the agile model is that it often does not scale well to large and complex development projects. Specific security related tasks should be included in the various phases of the SDLC, whether the development follows the waterfall model, the agile model, or any other model. Due to the radical difference between the waterfall and agile models, the development team needs to adapt the specific approach to secure development depending on the model followed, as described in the next section. The 1 st phase of Microsoft SDL is security training which emphasizes how important it is that programmers and other team members have acquired adequate security skills for their job. Security training empowers developers to have awareness for threats and vulnerabilities and to create secure applications.

In Microsoft SDL, every phase of the waterfall model includes security related tasks, such as in the planning phase, requirements phase and design phase. Risk analysis is for example included in the design phase.

According to [START_REF] Harris | CISSP All-in-One Exam Guide[END_REF] (p.1102) most vulnerabilities emerge during coding. It is therefore crucial that the programmer follows strict and secure methods of secure programming. By looking at the list of 25 most common software errors maintained by SANS6 , we see that many of these are directly related to irresponsible or sloppy programming practice.

Security Software Development in the Agile Model

There are relatively few studies in the literature on secure agile software development models. In Wichers' proposal [START_REF] Wichers | Breaking the Waterfall Mindset of the Security Industry[END_REF] it is argued that secure software development in the agile model needs a quite different approach to that of the waterfall model.

In [START_REF] Wichers | Breaking the Waterfall Mindset of the Security Industry[END_REF] it is recommended to identify all stakeholders and clarify what their main security concerns are. From this analysis a set of threat models can be extracted which in turn form the basis for stakeholder security stories. Then during the development phase, one has periodic security sprints in between the regular development sprints. It is also proposed to include a final security review before deploying the final system.

Microsoft has presented a version of SDL for agile software development [START_REF]Security Development Lifecycle for Agile Development[END_REF]. The Agile SDL model contains the same security steps as in the waterfall SDL model, where these steps are grouped in 3 categories:

-One-Time practices: Foundational security practices that must be established once at the start of every new Agile project. -Every-Sprint practices: Essential security practices to be performed in every sprint.

-Bucket practices: Important security practices that must be completed on a regular basis but can be spread across multiple sprints during the project lifetime.

We find that Microsoft's agiler SDL has merit. However, it has limitations by not separating between functional and non-functional security requirements.

We therefore propose an agile model for secure software development which is partially inspired by the model described in [START_REF] Wichers | Breaking the Waterfall Mindset of the Security Industry[END_REF] and by Microsoft's Agile SDL model, but which is also an improvement over these because it does not share their disadvantages mentioned above. Our model is also inspired by previous work in [START_REF] Oftedal | Leveraging agile to gain better security: An agile developer's perspective[END_REF].

Our approach to handling security in the agile model is based on the distinction between what we call functional security controls and non-functional security controls.

-Functional security controls reflect and implement user stories that are directly related to security, such as when password management and verification is used as a control to implement a user story for logon, or when ACLs (Access Control Lists) are used as a control for specifying and enforcing policies for using various resources within a domain. -Non-functional security controls are applied in order to eliminate or mitigate vulnerabilities in the implementation of other user stories, such as when applying secure programming techniques in order to avoid buffer overflow bugs, or when applying input filtering when designing a front-end to an SQL database in order to avoid SQL-injection. Software designer must understand that any type of user stories, both ordinary user stories as well as specific security related user stories, must be implemented in a secure way. The way to do that is precisely through nonfunctional security controls. The idea is that security threats that are intrinsic to a specific user story should be handled during the sprint for the same user story.

A further example of non-functional security controls is when implementing a user story about the logic for handling the check-out of a shopping basket on an e-commerce website, where a threat could be that the customer is able to trick the system into changing the number of items after the price has been computed, so that he could receive many items but only pay for one. This security concern must be handled during the sprint that implements the check-out of shopping baskets. Based on these considerations we propose to introduce a new security phase into the sprint iteration. This security phase focuses specifically on identifying threats against the current user stories. The new phase should also specify how the threats can be controlled or mitigated, and should specify tests for those mitigation controls. The implementation of non-functional security controls is then handled in the ordinary phase that develops, integrates and tests the new functionality for the current sprint.

Finally, we propose to include a security review in the phase of the sprint iteration cycle where the current version of the system is evaluated. This modified phase, as well as the two new phases that are specific to security, are indicated as yellow boxes in Figure 5 which illustrates our proposed model for secure agile software development. -Handling an obvious non-functional security requirement as a functional security requirement would generate unnecessary overhead. This is because non-functional security is an integral part of other user stories, so if non-functional security is handled separately it would lead to re-iteration of those user stories. Nevertheless, the non-functional security requirements could be adequately taken care of. The conclusion is that development efficiency would suffer, not security. -In case as an obvious functional security requirements is not handled as a separate user story then the design team has no clear strategy for handling such requirements. At the limit, such functional security requirements could be awkwardly included as a sub-story of other user stories. Alternatively the requirements would not be handled at all, which would be a serious design failure.

If in doubt, it is always safe to consider a security requirement as a separate user story. However, to optimize agility, clearly non-functional security requirements should be integrated as part of other relevant user stories whenever possible.

Cybersecurity Training

Security design is challenging, and requires strong skills to get it right. It can therefore not be expected that IT graduates without security training have the necessary skills for developing secure systems. A typical approach to security design in the industry is to let security specialists do a security review of systems that have been developed by software designers without security skills. However, this approach wastes time and manpower. The right approach is to have system designers with security skills who are able to identify vulnerabilities and threat scenarios during the design and development.

It is interesting to notice that in the Microsoft SDL model for secure software design, the 1 st phase focuses on security training. In other words, SDL assumed that the design team has acquired security skills before the proper development project starts.

In agile models for secure software design there is no separate phase for security training, neither in the model presented [START_REF] Wichers | Breaking the Waterfall Mindset of the Security Industry[END_REF] nor in our model presented in Section 4.2. For both models it is assumed that team members already have the required knowledge and skills to identify threat scenarios and to craft the corresponding security controls for mitigating those threats. In other words, without security skills among the development team members, no agile model for secure software development would be practical. Given that a large proportion of students following IT programs today still get no or only limited exposure to cybersecurity it is obvious that practicing agile models for secure development is problematic. For this reason there are maturity models for secure software development, where the most prominent are Building Security In Maturity Model 2 (BSIMM2) and OWASP's Open Software Assurance Maturity Model (OpenSAMM).

Governments or interest organisations in many countries are aware of this deficiency and have therefore launched programs to strengthen security education. In the USA for example, NICE (National Initiative for Cybersecurity Education) established in 2014 builds on the previous Comprehensive National Cybersecurity Initiative started in 2008 as an initiative to strengthen cybersecurity skills in the US federal government sector. NICE has been extended to include the commercial sector, where the goal is to strengthen cybersecurity skills from kindergarten through post-graduate school. The goal of NICE is to establish an operational, sustainable and continually improving cybersecurity education program for the nation to use sound cyber practices that will enhance USA's security.

However, NICE is a US-based imitative and it is still too early to tell how it will influence security education in university IT-programs. The global higher education sector has not yet reached a common consensus that cybersecurity should be an integral part of IT education. In contrast to IT education, in the domain of architecture and civilly engineering education it is obvious that students must acquire knowledge about fire safety. Admittedly there is a difference between these two domains. In architecture and civilly engineering there are strict regulations regarding fire safety, whereas there are no specific regulation for information security in IT systems.

We think initiatives like NICE in the USA should be copied in other countries as well, and could be supported by national computer societies and their umbrella organisation IFIP . National governments could also encourage the higher education sector to strengthen cybersecurity education as part of their IT education programs.

Conclusion

There is a consensus in the industry that security must be part of the software development lifecycle. It is not a question of which development model is used, but how well the organisation is able to integrate security in the process.

A weak spot in all the models is that they all depend on the team members having adequate security skills. It can not be expected that every organisation must provide security training to their own staff. Security training must therefore be part of IT education programs in higher education. There is an urgent need to strengthen IT education programs worldwide with regard to cybersecurity. For this purpose it would be interesting to define a security education maturity model for the university sector. If a university offers an IT education program with insufficient security, then that university is part of the problem of causing cybersecurity vulnerabilities. It is time for all IT education institutes to become part of the solution.

Fig. 1 .

 1 Fig. 1. Number of CVE IDs registered in the period 1999 -2014

Fig. 2 .

 2 Fig. 2. The waterfall model for software development

Fig. 3 .

 3 Fig. 3. The agile model for software development

4 Secure Software Development 4 . 1 Fig. 4 .

 414 Fig. 4. SDL: Microsoft Security Development Lifecycle [2]

Fig. 5 .

 5 Fig. 5. Proposed model for secure agile software development

COBIT: Control Objectives for Information and Related Technology

ITIL: Information Technology Infrastructure Library

http://www.sans.org/top25-software-errors/


Johan Van Niekerk
email: johan.vanniekerk@nmmu.ac.za

Lynn Futcher
email: lynn.futcher@nmmu.ac.za

The use of software design patterns to teach secure software design: an integrated approach

Keywords: Information security education, secure software design, secure software development, software design patterns

During software development, security is often dealt with as an addon. This means that security considerations are not necessarily seen as an integral part of the overall solution and might even be left out of a design. For many security problems, the approach towards secure development has recurring elements. Software design patterns are often used to address a commonly occurring problem through a "generic" approach towards this problem. The design pattern provides a conceptual model of a best-practices solution, which in turn is used by developers to create a concrete implementation for their specific problem. Most software design patterns do not include security best-practices as part of the generic solution towards the commonly occurring problem. This paper proposes an extension to the widely used MVC pattern that includes current security principles in order to teach secure software design in an integrated fashion.

Introduction

During software development, security is often dealt with as an add-on. This means that security considerations are not necessarily seen as an integral part of the overall solution and might even be left out of a design. Recently some efforts have been made to "shift some of the focus in security from finding bugs to identifying common design flaws" (http://cybersecurity.ieee.org/center-for-secure-design.html). However, efforts such as the IEEE centre for secure design is still relatively new and much work in this regard remains.

For many security problems, the approach towards secure development has recurring elements. Software design patterns are often used to address a commonly occurring problem through a "generic" approach towards this problem. The design pattern provides a conceptual model of a best-practices solution, which in turn is used by developers to create a concrete implementation for their specific problem.

The use of such design patterns has several major advantages. Firstly, the pattern provides a guideline towards best-practice. Secondly, the use of the pattern provides developers with a shared vocabulary that enables them to communicate complex design concepts easily and clearly. Due to these, and other benefits, design patterns are often taught in software design courses. Most software design patterns do not include security principles as part of the generic solution towards the commonly occurring problem. This paper proposes an extension to the widely used MVC pattern that includes current security principles in order to teach secure software design in an integrated fashion.

2 Teaching Secure Software Development Khan and Mustafa [START_REF] Khan | Secured Requirement Specification Framework[END_REF] define secure software as: 'software that is able to resist most attacks, tolerate the majority of attacks it cannot resist, and recover quickly with a minimum of damage, from the very few attacks it cannot tolerate'.

According to Burley and Bishop [START_REF] Burley | Summit on Education in Secure Software: Final Report[END_REF], there is an ever-increasing demand for software systems that are resilient, reliable and secure. They state that 'secure software development is a deep and tremendously important subject. Many problems arise from not focusing on the security aspects of software development' [START_REF] Burley | Summit on Education in Secure Software: Final Report[END_REF].

Many software security vulnerabilities are not coding issues at all but design issues [START_REF] Howard | Lessons Learned from Five Years of Building More Secure Software[END_REF]. In order to meet the demands, opportunities and threats associated with software development, security needs to be integrated into the overall software development life cycle. However, the reality is that security is often perceived as a barrier to functionality, adding constraints and reducing flexibility. Software developers generally ignore the idea of security or consider it as an afterthought. This typically leads to software applications having many security flaws and weaknesses.

Microsoft authors Howard and LeBlanc [START_REF] Howard | Writing secure code: Practical strategies and techniques for secure application coding in a networked world[END_REF], in support of secure software development, stress that software developers should avoid adding security as an afterthought for the following reasons:

• Adding any feature (including security) as an afterthought, is expensive; • Adding security later may change the way features have been implemented. This, too, is expensive; • Adding security later involves wrapping security around existing features, rather than designing features with security in mind; and • Adding security as an afterthought may change the application interface, which may, in turn, break the code that has been used to rely on the current interface. Taylor and Azadegan [START_REF] Taylor | Threading Secure Coding Principles and Risk Analysis into the Undergraduate Computer Science and Information Systems Curriculum[END_REF] support this notion, and state that: 'building secure systems requires incorporating security principles early and often throughout the software development life cycle'. Information security should, therefore, be an integral part of the development process; and it should be taken into account at every stage of the software development life cycle.

In addition, software developers need to use improved practices that consistently produce secure software. Such practices should measurably reduce software specification, design and implementation defects; thereby, minimizing any potential risks. The development of secure software requires knowledge and techniques not commonly taught or practiced by most software developers [START_REF] Khan | Secured Requirement Specification Framework[END_REF].

In a report on the Summit on Education in Secure Software, Burley and Bishop [START_REF] Burley | Summit on Education in Secure Software: Final Report[END_REF] summarise some fundamental factors to ensure secure software development, namely:

• Understanding security, especially during design, requires a holistic approach; • Programmers and non-programmers must be educated in the core principles and practices of secure software design; •

The principles of secure programming must be integrated into a curriculum designed to meet the cyber security challenges of the future; and • Secure programming must be considered within the context of the full system design and deployment process. According to Heyman, Yskout, Scandariato and Joosen [START_REF] Heyman | An Analysis of the Security Patterns Landscape[END_REF], in the security discipline, a well-known principle calls for the use of standard, time tested solutions rather than inventing ad-hoc solutions from scratch. Various researchers propose that security patterns can potentially contribute significantly to the design and development of secure software, since they provide re-usable solutions to security problems, and incorporate expert knowledge. However, Yoshioka, Washizaki and Maruyama [START_REF] Yoshioka | A survey on security patterns[END_REF] state that: 'although various security patterns and techniques for using them have recently been proposed, it is still difficult to adapt them to each phase of the software development life cycle'. Further research is therefore required to address the use of patterns within the software development life cycle in order to ensure that security concerns are integrated into the development process.

Teaching Advanced OO and Design Patterns

One of the benefits of the Object Orientated Programming (OOP) paradigm is that it allows software developers to reuse source code. Such reuse is supposed to bring many benefits, including increased productivity, improved code quality, and more design consistency [START_REF] Barzilay | Understanding Reuse of Software Examples: A Case Study of Prejudice in a Community of Practice[END_REF]. In software development problems often recur, but not necessarily in the same context. Due to this difference in context, code reuse is not always practical since the different contexts of the problems might prevent the reuse of existing code without substantial modification.

In order to reuse a software solution, one would need a general solution that can be adapted to the specific problem's context. Such general solutions are not necessarily always possible in terms of reusable code, however it is often still possible to package domain-independent knowledge and expertise in a reusable way in the form of software design patterns [START_REF] Heyman | An Analysis of the Security Patterns Landscape[END_REF].

A pattern can be described as 'a solution to a problem in a context' [START_REF] Freeman | Head First Design Patterns[END_REF]:

•
The context is the situation in which the pattern applies. This should be a recurring situation;

•

The problem refers to the goal you are trying to achieve in this context, but it also refers to any constraints that occur in the context [START_REF] Freeman | Head First Design Patterns[END_REF];

•
The problem should be a recurring problem [START_REF] Dooley | Software Development and Professional Practice[END_REF];

•
The solution provides a general design (core solution) that extracts the essence of the solution to resolve the problem for the given context and constraints [START_REF] Freeman | Head First Design Patterns[END_REF][START_REF] Dooley | Software Development and Professional Practice[END_REF].

Software designers rarely start a new design from first principles. Instead they rely on existing designs to inform the new solution. Design patterns provide a commonly used mechanism, or shared vocabulary to communicate such previous solutions to commonly occurring problems. It is important to note that a design pattern is not a finished design that can be transformed directly into code [START_REF] Pieterse | What is a Design Pattern? SACLA[END_REF]. Instead, it provides a "template" for the solution that can be adapted to the problem's specific context [START_REF] Pieterse | What is a Design Pattern? SACLA[END_REF]. Design patterns provide software designers with three main advantages:

• Firstly, the solution is known to be sound because it is time-tested; • Secondly, benefits and drawbacks of a pattern are known in advance and they can be taken into account while sketching the solution; • Thirdly, patterns establish a common vocabulary that can ease communication between different stakeholders [START_REF] Heyman | An Analysis of the Security Patterns Landscape[END_REF][START_REF] Dooley | Software Development and Professional Practice[END_REF]. These advantages also make patterns very useful in the teaching of software design. Many complex system frameworks make extensive use of design patterns to provide basic underlying services within the framework. Knowledge of the underlying design patterns is often assumed, and used to aid in explanations regarding scalability, modularity, extensibility, etc. within these frameworks [START_REF] Pieterse | What is a Design Pattern? SACLA[END_REF]. Such knowledge will, however, only aid in the discussions of complex frameworks if students 'understood the intent and implementations of each of the design patterns separately before combining them' [START_REF] Pieterse | What is a Design Pattern? SACLA[END_REF].

Design patterns can thus be seen as an important tool in the communication of knowledge regarding good software design. However, due to the need to present design patterns as a general template that is not specific to a particular context, most design patterns do not by default include any aspects related to secure software development. To a certain extent this exacerbates the problem of teaching secure software development since security should ideally not be dealt with as an optional add-on in a software design. Instead, systems should be designed as secure systems from the ground up. It would thus be beneficial for the teaching of secure software design, to have design patterns that incorporate basic secure design principles as an integral part of the pattern itself. Many design patterns could probably be adapted to include security concerns, however, this paper will only focus on one such pattern, the Model-View-Controller (MVC) pattern. The MVC pattern is widely used in modern software development and is especially useful in designs for a distributed n-tier architecture, which makes it an ideal pattern for the design of many online applications. As such this pattern was deemed appropriate for use in this paper.

Integrating Secure Design Principles into the Model-View-Controller (MVC) Pattern

The MVC pattern forms the basis for the very popular n-tier approach towards software design and is thus often taught in software design courses. The pattern is a compound pattern which uses other patterns to provide specific "services" to the design. The MVC separates the design and development of the user interface (View) from the underlying controlling logic for this view (Controller), which is further separated from the problem domain's underlying state, data, and application logic (Model) [START_REF] Freeman | Head First Design Patterns[END_REF]. The structure of the MVC pattern works to separate the responsibilities of components and is especially well suited to web applications [START_REF] Syromiatnikov | A Journey through the Land of Model-View-Design Patterns[END_REF].

The View shows the windows, buttons, and other controls to the user; the Controller interprets clicks and other commands; and the Model does the business logic and object retrieval -then relaying the changes to the View again [START_REF] Syromiatnikov | A Journey through the Land of Model-View-Design Patterns[END_REF]. The View can request state information from the Model, and the Controller can ask the View to update its display. This relationship is shown in Figure 1. Secure software development requires the designer, and developers, to consider the relevance of various secure design principles for the software's context of use. A comprehensive overview of such principles falls outside the scope of this paper. However, in previous work Colesky, Futcher and Van Niekerk [START_REF] Colesky | Design patterns for secure software development: demonstrating security through the MVC pattern[END_REF] demonstrate how many of these principles can be integrated into the MVC pattern. The following discussion provides a brief overview of the proposed secure version of the MVC as shown in Figure 2.

Figure 2 provides a version of the MVC pattern with the following additional security principles incorporated:

1. Authentication, authorization, access control and trust services were added to the model between the controller and the model. The purpose of these services is to "guard all entrances"; 2.

A further layer of encipherment, which includes the hashing of passwords, encryption of sensitive data, and hiding of business logic through the preferred use of stored procedures were added to the model; 3.

A notary function is added to log evidence of all transactions originating from the controller; 4.

To combat input related risks a layer of mechanisms which include verification, the encoding, quoting, and escaping of characters, and validation of all inputs were added. The following section discusses the implications of using the security-conscious MVC for teaching secure software design.

Discussion

It is important to note that the proposed security-conscious MVC does not prescribe specific technologies for the secure services, but rather provides a specific design context where such services should be sensibly included.

Novice software development students often make mistakes such as placing the code for authentication mechanisms at view level. These mistakes are sometimes further exacerbated by having a username and password visible as unencrypted text within a web page. When developing a web application, many possible technologies could be used for access control and/or encipherment services. The intention of the security conscious MVC pattern is not to dictate a specific technology, but rather to emphasise that there should be an access control mechanism, and that this mechanism should exist between the Controller and the Model. Access control logic should thus not be exposed at the level of the View. Furthermore, by adding the encipherment layer to the pattern it provides a logical "prompt" for an educator to engage the class regarding what would be sensible to include under these services. For example, "Should the authentication mechanism make use of encrypted communications?" "What would be an appropriate encryption technology to use for this context?" "Should data exposed by the model be encrypted?" One of the first considerations a designer is faced with when designing secure software is how to restrict, or control, access to the underlying data so that only authorised users can view or modify the data. From an access control point of view, the notions of authorisation, authentication, access rights, privileges and trust are of particular importance. Access to data should be given in accordance to the principle of least privilege. This principle dictates that an entity should be given access with as few rights as possible [START_REF] Meier | Improving Web Application Security: Threats and Countermeasures[END_REF]; and it also requires that access be permitted for the shortest duration possible [START_REF] Howard | Writing secure code: Practical strategies and techniques for secure application coding in a networked world[END_REF]. In the authors' experience, discussion of this principle is often done completely out of context and never practiced by software development students.

The use of the security conscious version of the MVC pattern provides a logical prompt for the inclusion of this topic during every discussion regarding an n-tier design. By including security considerations as a default into every web application (or similar) development project, students will get substantial exposure to the issues that should be considered and will, hopefully, also get substantial practice during laboratory exercises.

The structure of the presented security-conscious MVC pattern reflects both secure design principles and best practices. For example, in addition to stimulating discussion regarding the above principle of least privilege, this version of the MVC could also be used to introduce students to the principle of fail-safe defaults, which dictates that the default access granted to a resource should be none. Thus, unless access has been granted explicitly to a resource, access to that resource should be denied. In the presented model, this principle is implemented in conjunction with the principle of least privilege via a layered approach. Firstly, the practices of requiring authentication, authorization, and controlling access ensure that only trusted entities are given access to a specific resource. Secondly, because data is encrypted and business logic is hidden, all entities have to make use of the access control mechanisms in order to be able to see the underlying data in any form. Thus, should the programmer neglect to verify whether a specific entity should have access, the default behavior would be to present the underlying data in an encrypted format.

According to Martin et al. [START_REF] Martin | CWE / SANS Top 25 Most Dangerous Software Errors[END_REF], the top four software vulnerabilities are SQL (Structured Query Language) injection, operating system command injection, buffer overflows and cross-site scripting, respectively. All of these vulnerabilities stem from various forms of malicious input. It is thus vital to include issues related to verification, the encoding, quoting, and escaping of characters, and validation of all inputs consistently during a software design curriculum. The use of this security conscious version of the pattern encourages active discussion regarding these important questions for every n-tier design. By including these topics, both in terms of underlying secure design principles and in terms of secure design best practices, as an integral part of the pattern, educators can ensure that these security services are not seen as an optional add-on, but rather as an essential part of the overall design. 'Education is a very powerful tool in helping to write secure code. By understanding possible threats, programmers can save valuable time and create secure code while users can rest assured that their information is safer' [START_REF] Yu | Teaching secure software engineering: Writing secure code[END_REF]. The authors believe that the integration of security principles into existing design patterns can be a powerful tool for educators to improve the teaching of secure software design.

The efficacy of this security conscious version of the MVC pattern as a tool to communicate security related concepts to students has not yet been tested. Furthermore, its perceived usefulness for software design educators has not been verified. In this approach, specific implementation details for such a secure MVC pattern was not included. A similar attempt to create a secure MVC pattern, that included more detailed implementation guidance, was presented by Delessy-gassant & Fernandez [START_REF] Delessy-Gassant | The Secure MVC pattern[END_REF]. However, their approach focused on the inclusion of role based access control into the MVC and was thus considered less generic by the authors who, for the purposes of teaching, specifically aimed to include both security principles and best practices without being too specific regarding implementation. Future work should focus on validating the usefulness of this enhanced version of the pattern for the purpose of teaching secure software design. In addition, the integration of security principles into other software design patterns has not yet been examined.

Conclusion

Most aspects of information and cyber security are directly affected by the ability of software developers to produce secure applications. Vulnerabilities caused by poor coding or design practices are a major cause of security breaches. It has become essential for modern software development curricula to address security as an integrated part of the software development process. This paper presents an approach that includes secure software design principles into a commonly used software design pattern. This approach allows the consideration of security principles to form part of the overall design and thus not be relegated as an optional add-on. The authors believe that this approach could play a meaningful role in the teaching of secure software development. Society as a whole can no longer afford to treat security as an afterthought.

Figure 1 :

 1 Figure 1:The Model-View-Controller[START_REF] Freeman | Head First Design Patterns[END_REF]

Figure 2 :

 2 Figure 2: Security-conscious MVC[START_REF] Colesky | Design patterns for secure software development: demonstrating security through the MVC pattern[END_REF]