Infrastructure Access Rules

Once the IP addresses have been allocated, configuring access rules for the competition infrastructure will be the next thing to be carried out. There are three categories of access rules that have been implemented for the central firewall by NePAS so as to ensure proper security access control for any proposed competition. These categories of access rules are as follows:

1. Management Server Rules

The first group of access rules has to do with the management server having access to the various team infrastructure during the competition. There are two different sets of firewall rules that have been implemented for the management server functionality. These sets of firewall rules are as follows:

(a) The firewall rules contained in this section are used to allow the management server, MgtServer, to communicate with all the vulnerable servers of the various participating teams during the competition. The firewall rules that will be configured on the central firewall’s rule base for this set of access rules have an access-list name called nepas-mgt-out. These set if firewall rules will be applied on the outside interface of the central firewall device that is facing the management server in the infrastructure. These firewall rules will enable the management server to monitor and check flags of teams for scoring during any competition.

CHAPTER 7. CYBER SECURITY COMPETITION ABSTRACTIONS 132

(b) The firewall rules contained in this section are used to allow the vulnerable servers of various participating teams to communicate with the management server, MgtServer during the competition. This firewall rule is only con- figured for participating teams which have their management node option value set to "TRUE" in the competition policy intention. A deny firewall rule will be configured if the management node option value is set to "FALSE" in the competition policy intention. The fact that red team’s do not have any vulnerable infrastructure means this option will be overlooked even if it is specified. The firewall rules that will be configured on the central firewall’s rule base for this set of access rules have an access-list name called nepas- mgt-in. These set if firewall rules will be applied on the inside interface of the central firewall device that is facing the management server.

The two sets of management rules configured in the central firewall for the rep- licated competition infrastructure in Figure 7.6 above is shown in Listing 7.1

below.

Listing 7.1: Excerpt of Management Access Rules for Proposed CDX

’access-list nepas-mgt-out extended permit ip host 20.0.0.1 any’

’access-list nepas-mgt-in extended permit ip host 20.0.1.1 host 20.0.0.1’

’access-list nepas-mgt-in extended permit ip host 20.0.2.1 host 20.0.0.1’

2. Vulnerable Server Rules

The second category of central firewall rules allow all attack servers of a particular team to access their respective vulnerable infrastructure during the competition. An allow rule is configured in the central firewall’s rule base so as to enable team members have access to and fix their vulnerable servers accordingly. The firewall rules that will be configured on the central firewall’s rule base for this set of access rules have an access-list name called attack-own-out. These set if firewall rules will be applied on the outside interface of the central firewall device that is facing the attack servers in the competition infrastructure.

The access rules that have been configured in the central firewall to allow the two teams in the proposed CDX in Figure7.6above is shown in Listing7.2below. Listing 7.2: Excerpt of Team-to-Vulnerable Access Rules for Proposed CDX

’access-list attack-own-out extended permit ip host 20.0.8.2 host 20.0.1.1’

’access-list attack-own-out extended permit ip host 20.0.6.2 host 20.0.2.1’

3. Attack Server Rules

The last category of access rules implemented for cyber security competitions in NePAS determines the access rules between the attack servers of a team and its opponents. This category of access rules is implemented using the relationship between any two teams as indicated in the CDX policy intention graph. The access rules are therefore categorised according to the competition approach as follows:

(a) A comprehensive relationship between two realms in the intention graph per- mits access to the vulnerable infrastructure of both teams by their respective attack servers. This translates to an allow rule between the attack servers of both teams to their opponent’s vulnerable servers in the central firewall’s rule base of the competition infrastructure.

(b) An offensive relationship between two realms in the intention graph allows the source team attack servers to access the vulnerable infrastructure of the destination team while the destination team attack servers are denied access to the vulnerable infrastructure of the source team.

(c) A defensive relationship relationship between two realms in the intention graph translates into an allow rule in the central firewall’s rule base so as to enable the destination team attack servers to access the vulnerable infrastructure of the source team while the source team attack servers are denied access to the vulnerable infrastructure of the destination team.

The firewall rules that will be configured on the central firewall’s rule base for this set of access rules have an access-list name called attack-opp-out. These set of firewall rules will be applied on the outside interface of the central firewall device that is facing the attack servers in the competition infrastructure. The access rules that have been configured in the central firewall to allow the two teams and the red team attack server to be able to access and exploit the opponent’s vulnerable servers in the proposed CDX in Figure7.6above is shown in Listing7.3below. Listing 7.3: Excerpt of Team-to-Opponent Access Rules for Proposed CDX

’access-list attack-opp-out extended permit ip host 20.0.8.2 host 20.0.2.1’

’access-list attack-opp-out extended permit ip host 20.0.6.2 host 20.0.1.1’

’access-list attack-opp-out extended permit ip host 20.0.7.2 host 20.0.1.1’

’access-list attack-opp-out extended permit ip host 20.0.7.2 host 20.0.2.1’

It should be noted that whenever NePAS is dealing with a cyber security competition with firewall device(s) within the individual team infrastructure, these rules will be

CHAPTER 7. CYBER SECURITY COMPETITION ABSTRACTIONS 134

adequately added into all firewall device(s) as the policy intention dictates. Therefore when two teams are involved in a comprehensive approach competition, access rules will be configured into the various firewall device(s) in the infrastructure to allow the respective attack servers of the various teams have access to the vulnerable servers of an opponent in order to achieve set objectives.

7.6

Closing Remarks

This chapter of the thesis gives a thorough insight into how cyber security competitions are organised and our proposed abstractions. An example is showcased to analyse how NePAS is used to support our proposed abstractions and evaluate their limitations. The next chapter will be used to critically analyse our high level abstractions using complex experiments. The chapter concludes by evaluating the limitations of the developed system’s handling of our proposed abstractions.

Critical Analysis

8.1

Experimentation

This section attempts to provide verification of how our abstraction models can be used to deploy network experiments from sets of high-level policy intention through to low level device configurations for each of the network policies discussed in the previous three chapters. There are three experiments that will be conducted in this section and each experiment will be focusing on a particular network policy that has been discussed in the previous three chapters. The experiments will have a couple of policy anomalies within the proposed abstraction models so as to see how our system, NePAS, will resolve them before low level device configurations are generated for deployment.

The first experiment to be conducted details how our abstraction models can be used to deploy a multi-tiered ISP network running BGP between various autonomous systems from a high-level inter-domain routing policy intention. The second experiment to be conducted details how our abstraction models can be used to implement a distributed firewall network for a hypothetical financial service organisation from a high-level access control policy document. The last experiment to be conducted details how our abstraction models can be used in designing and running a multi-approach cyber security competition. Each of these experiments will be discussed using four segments as follows:

1. Experiment rationale - this segment is used to briefly explain the reason for conducting the experiment and its policy requirement.

2. Policy intention - this segment is used to explain how the policy requirement from the above segment is translated into a NePAS policy intention graph. Policy anom- alies contained in these abstraction models will be highlighted in this segment. 3. Network layout - this segment is used to explain the second phase of our abstraction

model or the actual network layout that will be used during the proposed experi-

CHAPTER 8. CRITICAL ANALYSIS 136

ment. Policy anomalies contained in these abstraction models will be highlighted in this segment.

4. Experiment overview - the two segments, policy intention and network layout, are the basis for the proposed experimental setup. This segment will be used to explain the relationships between the nodes during the experiment.

5. Expected outcome - this segment is used to analyse the expected outcome (or expected result) of the experiments conducted using the system, NePAS, developed from our abstraction models. The segment will also be used to explain how NePAS handles the various policy anomalies that have been introduced in our abstraction models in the various experiments. The segment ends with an analysis of the strengths and weaknesses of our abstraction models and our system, NePAS.