1. Introduction

This report explores the foundations of network security, devising a security policy for a fictional company that engages industry frameworks for best practise to discover and mitigate risk. Internal and external threats are both identified, deploying a range of network infrastructure practises to provide a level of safety whilst balancing operational requirements.

2. Network Security

Modern business environments require connectivity for internal and external communication to deliver their products and services. The internet and site to site communication are important factors and businesses value their intellectual property and access to business-critical services.

In a perfect world, there would be no need for security with people respecting others privacy, but unfortunately, that is not the case and there are people, businesses and governments looking to;

• Gain unauthorised access
• Steal information
• Disrupt services
• Install malicious software
• Other nefarious acts

Violating one or more of the following rules; Confidentiality, Integrity and Availability (CIA).

C.I.A. is defined under ISO 27000:2016 standard as the following;

• Confidentiality
  • “property that information is not made available or disclosed to unauthorized individuals, entities, or processes”
• Integrity
  • “property of accuracy and completeness”
• Availability
  • “property of being accessible and usable upon demand by an authorized entity”

Network security looks to mitigate the risks presented to a business protecting infrastructure and assets from attack using separation either physical or virtual and controls such as passwords to prevent unauthorised access and use (Kin, et al., 2011).

2.1. Business Value

The value to a business can be difficult to quantify and the easiest way is to represent what happens without adequate security. Studies into 277 companies performed by the Ponemon Institute (2013) that had experienced sensitive data theft or loss found the following;

• Highest total average cost to business unit $5.4 million in the US
• Lowest total average cost $1.1 million in India

Attacks can be costly. In a survey conducted by Incapsula (Matthews, 2014) on Distributed Denial of Service (DDoS) impact and costs, estimated that that per hour the average cost is $40,000 with an average attack lasting 6-24 hours totalling approximately $500,000.

Financial cost is not the only concern for businesses, reputation is also at stake. After attacks took place in 2016 on TalkTalk they reportedly lost over 100,000 customers whilst incurring estimated costs of around £60 million (Farrell, 2016) (Hall, 2016) (McGoogan & Palmer, 2016).

Threats are also faced internally from employees and they could be completely unaware that they are enabling an attack as is the case with social engineering or they could on the other hand have malicious intent. For example, the F.B.I. (2010) records programmer R. Makwana working for Fannie Mae, who was convicted for malicious code insertion, which, if executed was designed to destroy all company data devastating business operations.

Mitigating these scenarios and impacts is one place where businesses will find value, but decisions will need to be made on budget and requirements, understanding what is being protected, why and how. Other areas of business value can be found from adhering to legal requirements, standards set forth for enabling trade, supplier requirements and consumer confidence.

2.2. Defining Network Security

Working with the aim of protecting network assets against threats, Network Security can have a very broad scope. Skinner (2017) lists a few as;

• Hardware
• Servers
• Switches
• Routers
• Software applications
• Data

However, when considering the 7 layer TCP/IP model, only layers 1-4 specifically deal with the network and 5-7 are application centric, figure 1.

For example, a SYN flood attack directly targets vulnerabilities within the TCP/IP protocol suite whereas a buffer overflow attack will occur at level 7 within the application. Having clearly left the network portion of the model, this defines two distinct areas, Network security and Application security. Moving forward, the focus is on Network Security.

3. Security Frameworks

Several frameworks exist as guidelines and best practise for network security such as;

• ISO/IEC 27000:2016 – 27002:2016
• SANSNetwork Security
• Cisco Security Control Framework (SCF)
• Cisco SAFE
• IBM Network Security Framework

The following sections will explore Cisco SCF.

3.1. Cisco SCF & Baseline

The SCF (Cisco, 2009), outlines three main objectives;

• Protect the IT infrastructure
• Protect the IT assets using network-based controls
• Mitigate and respond to security incidents using network based controls

suggesting that when devising a security policy, the following topics should be considered;

• Infrastructure devices
• Services
• Endpoints
• Networks
• Applications

The SCF supplies detailed guidelines for each. Additionally, Cisco provides the Network Security Baseline (2013) (CNSB) providing “practices and functions commonly required by regulations and standards” and as such will be the basis for a network security policy.

3.2. Policies

Avolio et al. (2007) outline policies as defining “proper and improper behaviour; they spell out what is permitted and what is denied” typically consisting of two parts policy and procedure, spanning from a root document. When considering policy creation Avolio et al. (2007) recommend involving people from all areas of the business to identify requirements and for each asset asking the questions:

• Who administers the asset?
• Who uses it?
• How critical is it to the mission of your enterprise?
• How do you manage it?
• How do you protect it?

Finally looking at who and how to enforce created policy and what to do in the event of an incident.

The following sections consider several potential network assets and associated threats for policy creation.

4. J-TECH Overview

A fictional company has been created with the network infrastructure detailed in figure 2.

The IT security manager has been tasked with constructing a policy to mitigate several identified key threats to the network infrastructure. The CNSB (2013) attempts to mitigate the following;

• Denial-of-service (DoS)
• Distributed DoS (DDoS)
• Unauthorized access
• Session hijacking
• Man-in-the-middle (MITM) attack
• Privilege escalation
• Intrusions
• Botnets
• Routing protocol attacks
• Spanning tree attacks
• Layer 2 attacks

To do this the CNSB covers several headings discussed in more detail below.

5. Device Access

Core devices such as routers and switches present a crucial access point for attacks, gaining control of these could compromise the entire network. Strict controls and separation are required to prevent unauthorised access.

The confidentiality of information must be considered when communicating with these devices as they will often present a range of configuration methods such as Telnet, SSH and HTTP(S). Cisco (2013) points out that insecure protocols such as Telnet with cleartext transmission should be disabled to prevent snooping and devices must be reviewed individually for services that may be enabled by default. Table 1 below outlines CNSB’s access guidelines.

Accessibility Restriction	Approach
Terminal and Ports	·    All devices should have unused ports shutdown ·  ACLs to allow IT IP address range and approved protocols ·    Deny all other device management access
Access to services	·    Permit requests to all authorised services ·    Deactivate unused device services
Manage sessions	·    Use timeouts closing inactive sessions ·    Set session maximum time
Dictionary and DoS attacks	·   Lockout on multiple failed logins ·   Limit login attempt rate

To this effect the following policy has been defined in table 2.

Area	Control used
Management access	·   Console port secured using password ·   VTY lines password protected ·   Enable password protected ·   SSH V2 enforced ·   Passwords encrypted ·   HTTP(S) disabled
Authorised services	·   Access Control Lists (ACLs) placed to allow authorised services
Session management	·   Enforce 5-minute timeout ·  Hung sessions must be closed
Dictionary and DoS attacks	·  Passwords must be minimum of 8 characters ·   Password entry must be delayed ·   After five failed logins within 90 seconds restrict access for 90 seconds. ·   Restricted ACL on VTY lines ·   Management IP 192.168.99.10 only on final VTY

Several issues are addressed by the above policy. The controls and separation used are designed to prevent DoS using ACLs, preventing unauthorised traffic connecting to the ports preserving availability to management. If this was subjugated, then strong passwords and login controls prevent automated dictionary attacks from succeeding within a viable timeframe. However, DoS can be performed by simply establishing a connection to the ports, once a connection is established no other incoming connection can be made. For this CNSB (2013, p. 2.13) recommends an out of band management device connected on the final VTY line with a highly restrictive ACL. By doing this a designated management station will still have access even during a DoS attack. These factors make a three-tiered defence, but as the steps taken are not a guaranteed preventative solution, CNSB recommends logging events to a central system permitting real time analysis of network telemetry and identification of attacks as they occur, reacting as required.

An example securing the management lines has been completed using the commands shown in figure 3.

5.1. Legal Notifications

The CNSB (2013, p. 2.13) contains significant detail surrounding legal notifications, stating that advice should be sought if necessary to remain compliant with local or international laws and individual privacy regarding usage monitoring.

The use of a banner is to inform potential unauthorised users that their actions are indeed unauthorised and that monitoring will take place of any activates performed should legal proceedings be required.

In addition, the CNSB advise against any device specific information being placed within the banner which would otherwise give an attacker information. A sample provided from Cisco has been implemented on J-TECHs devices using the configuration shown in figure 4.

Area	Control
Legal banner	·   Infrastructure devices must display company banner
CIA Addressed	·   Confidentiality Availability

6. File Transfer

Updates or configurations may need to be remotely loaded to infrastructure devices, the CNSB identifies three common methods;

• File Transfer Protocol (FTP)
• Trivial File Transfer Program (TFTP)
• Secure Copy (SCP)

TFTP is not authenticated, while FTP requires username and password, but both send data cleartext. CNSB (2013, p. 2.30) notes that sensitive information could be obtained from sniffing the usernames, passwords or files. SCP on the other hand uses SSH for authentication and transport. As SSH is already leveraged with J-TECH’s policy the decision is taken to enforce SCP to protect the confidentiality of data transmitted.

Area	Control
File transfer ·   Configuration files ·   OS Image	·  All file transfers must use Secure Copy (SCP)
Responsibility	·  NetSec
CIA Addressed	·  Confidentiality

7. Image Verification

Cisco NSB (2013, p. 2.32) recommends verifying all software using the MD5 hash, this provides integrity ensuring that it hasn’t been altered, helping mitigate vulnerabilities that might be introduced by installing malicious software.

Area	Control
Software Installation / Update	·   All transferred files must be validated using MD5 hash
Responsibility	·   NetSec
CIA Addressed	·   Integrity

8. Management Network

For management traffic CNSB (2009, p. 3.3) recommends the use of separation and control to prevent snooping and provide device availability. Ideally provided by separate additional physical infrastructure directly linking management to devices, Out-of-band (OOB). This enables device access even if a network link is unavailable during incidents. Alternatively, Pseudo out-of-band, the virtual separation of traffic using VLANs and the same physical infrastructure can be used. However, virtual separation relies on the same infrastructure, in the event of an incident, complete visibility and control could be lost over portions of the network.

This ultimately is a cost based decision depending on mission critical services being available. Currently J-Tech is using VLAN separation for a scalable cost effective solution, but, being a small company, would not incur large costs to roll out a dedicated OOB management infrastructure, increasing availability, visibility and control over the network, figure 5. The management network policy is below, table 6.

Area	Control
Management Network	·   OOB communication to be implemented where possible ·   Pseudo OOB communication must be used where OOB is not possible – VLAN / VPN
Responsibility	·   NetSec
CIA Addressed	·   Confidentiality Integrity Availability

9. Routing Infrastructure

The primary purpose of a router is routing packets to their destination. Attackers can look to exploit routing protocols to cause service interruption or force route changes through either compromised trusted devices or a spoofed device enabling snooping of cleartext data (Cisco NSB, 2013, p. 3.1). . J-TECH currently has an OSPF protocol in use and as best practise CNSB (2013, p. 3.1) recommends using neighbour authentication and passive interfaces to help mitigate these threats.

9.1.  Neighbour Authentication

Routing updates can be a vector for attacks such as;

• Session resets
• Unauthorised peers
• Route injection
• Removal or modification of legitimate routes

By use of a symmetric secret key, updates can be authenticated providing the key remains secret. CNSB (2013, p. 3.3) supplies two methods for this; cleartext or Message Digest Algorithm V5 (MD5). Since cleartext can be intercepted and the MD5 method never sends the key over the network, MD5 is the clear winner. By pre-sharing the key out of bands the message and key are hashed using the MD5 algorithm and attached to the outgoing message, the receiving device hashes the received message with its stored key, verifies against the sent hash confirming the authenticity and integrity of the message.

CNSB (2013, p. 3.3) suggests the use of unique secret key pairings per device but suggest this could become hard to manage in large environments. Balance is therefore required between operation efficiency and security, table 7.

Area	Control
Neighbour Authentication	·  All routing protocol messages to use shared keys and MD5 authentication ·  Border devices to use unique pairing keys ·  Non-border device to use pre-defined key ·  Keys to be stored securely in accordance with infrastructure key policy.
Responsibility	·  NetSec
CIA Addressed	·  Integrity Availability

9.2.  Passive Interfaces

As standard, a Cisco router will accept routing updates on any interface and this can introduce the chance of inserting unauthorised peers and accepting non-legitimate updates. By setting interfaces to passive where neighbour adjacencies are not expected this can prevent these links from being established. CNSB (2013, p. 3.5) notes that depending on the protocol in use passive interfaces can have different effects, table 8.

Protocol	Disables incoming updates	Disables outgoing updates	Prevents adjacency establishment	Prevents peer insertion	Prevents manipulation of routes	Prevents route based DoS
RIP	X	Y	N/A	X	X	X
IGRP	X	Y	X	X	X	X
OSPF	Y	Y	Y	Y	Y	Y
EIGRP	Y	Y	Y	Y	Y	Y

As J-TECH is currently running OSFP, passive interfaces will help provide several security benefits and is recommended in the interfaces policy table 9.

Area	Control
Passive Interfaces	·  All routing devices to use ‘passive-interface default’ command ·  Interfaces where adjacencies are expected to be enabled as required.
Responsibility	·  NetSec
CIA Addressed	·  Confidentiality Integrity Availability

10. Device Resiliency and Survivability

During an attack on routers or switches, network availability could be impacted. CNSB (2013, p. 4.1) list possible attacks that include but not limited to;

• DoS
• Flood attacks
• Reconnaissance
• Unauthorised access

The following sections look to address these issues, helping to maintain network availability even during an attack.

10.1. Infrastructure ACL

Access Control Lists (ACLs) allow the filtering of traffic and come in different forms filtering on different criteria.

• Standard ACL
  • Filters on source IP address working at layer 3
• Extended ACL
  • Filters on source and destination IP address and provides more granular control over protocol, port number and state of a SYN bit for established connections, layers 3/4

Cisco (2016) details additional ACLs types but the focus will be on standard and extended providing control of information flow over the network from both internal and external attacks, most effectively deployed at network edges. However, CNSB (2013, p. 4.7) states that infrastructure ACLs “are not effective mitigating attacks originating from trusted sources and based on trusted protocols” and additionally that care must be taken when deploying as incorrectly configured ACLs can create a DoS condition by blocking legitimate services. Figure 6 shows the identified ACL locations for J-TECH.

Configuration examples for routers R1 and R2 ACLs can be located as appendix items A and B and a demonstration of the separation and control provided in the video below in figure 7, also available as appendix item C, with the defined policy as table 11. R3 has not been configured at this point as considered out of scope.

Area	Control
Service Access	·  Use of Access Control Lists ·  Provide access only to required services ·  Management Network must not be accessible ·  Protocol Filtering – To Be Considered
CIA Addressed	·  Confidentiality Availability

10.2. Port Security

CNSB (2013, p. 8.11) outlines that active switch ports present a risk from people attaching unauthorised devices to the infrastructure potentially carrying out layer 2 attacks such as MAC flooding. Port security allows limits to be placed on the number of MAC addresses permitted on a port and if a port is not intended to be used it should be shutdown. Following these rules the policy in table 12 is set out for J-TECH and example configuration shown in figure 8.

Area	Control
Switch Port Security	·  All workstation ports to be configured with maximum 1 MAC address ·  IP Phones max 2 MAC addresses ·  Workstation/Phone ports set to restrict ·  Dynamic MAC learning ·  Non-trunks set to access mode ·  Trunks set to ‘nonnegotiate’ ·  Shutdown unused ports
CIA Addressed	·  Confidentiality Availability

11. Redundancy

Equipment failure can occur at any time. CNSB (2013, p. 4.23) recommends the use of redundant designs to eliminate single points of failure. Given that duplicating every piece of equipment would likely be costly, balance is required between maintaining an acceptable level of availability and service cost.

Currently J-TECH has several single points of failure. If the topology suggested in figure 9 was undertaken the network would be far more resilient to failure. Additionally, not requiring supplementary infrastructure equipment could be a low-cost solution.

12. Network Telemetry

As well as preventative measures CNSB (2013, p. 5.1) states that “To operate and ensure availability of a network, it is critical to have visibility and awareness into what is occurring on the network at any one time” and suggests that basic telemetry is “inexpensive and relatively simple to implement”.

To provide visibility CNSB (2013, pp. 5.2 – 5.18) suggest the following topics for consideration;

• Time Synchronization
  • NTP Protocol to synchronise time across devices
• Local Device Traffic Statistics
  • Throughput and bandwidth statistics
• System Status Information
  • Memory, CPU and Processes
• CDP Best Common Practices
  • Device information exchange
• Syslog
  • Centralised logging server
• SNMP
• ACL Logging

As not all of the above are addressable within the Packet Tracer environment, focus was made on implementing NTP and Syslog deployment in order to provide network infrastructure visibility. Figure 10 below shows the completed J-TECH network.

The above topology provides OOB supply of a synchronised time to all infrastructure devices, except switches being a limitation within packet tracer and produce logs to the SysLog server. Time synchronisation is beneficial for linking incidents and is crucial that time matches across the estate as is evident in the syslog below, figure 11 and the unsynchronised switch logs being of little use. As such all device times, must be synchronised and logged centrally for analysis.

13. Summary

Further work is required to secure and harden the controls in place. Redundancy has been sacrificed for OOB management availability and network telemetry, requiring router upgrades to implement all solutions. Additionally, several areas within the CNSB have only been touched upon, finding a balance between operational efficiency and time allocated for the task. Companies could potentially spend huge amounts of time and money on security policy and still not be protected from every attack vector. Defining a security policy allows for the standardisation of processes with designation of responsibility and accountability to specific business roles. This provides the ability to ensure governance over a deployed solution. The J-TECH associated configuration scripts can be located as appendix item D detailing the full deployment from figure 10 previously.

14. Conclusion

It is clear from the devised policy that even with control and separation in place network security provides a level of safety but is never fully secure. Security must be balanced with resources and capabilities to provide, where possible, a multi-layered solution to lessen an assessed risks’ impact. However, new internal and external threats are constantly evolving and as such any security policy must be rigorously enforced and updated to maintain asset safety. This highlights network security’s responsibility for maintaining CIA and visibility. Further research into CNSB and CSF will provide more aspects for consideration, expanding on the subjects covered within this report. The policy created provides an insight into a practical Cisco Network Security Baseline implementation and a solid foundation for J-TECH’s future policy development.

References

Avolio, F. M., Fallin, S., Pinzon, D. S. & CISSP, N., (2007) Producing your network security policy.
Available at: http://www.watchguard.com/docs/whitepaper/securitypolicy_wp.pdf
(Accessed: 20 March 2017).

Cisco, (2009) Cisco Security Control Framework (SCF) Model.
Available at: http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Security/CiscoSCF.html
(Accessed: 01 March 2017).

Cisco NSB, (2013) Cisco Network Security Baseline.
Available at: http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Security/Baseline_Security/securebasebook.html
(Accessed: 05 March 2017).

Cisco, (2016) Configure Commonly Used IP ACLs.
Available at: http://www.cisco.com/c/en/us/support/docs/ip/access-lists/26448-ACLsamples.html#anc16
(Accessed: 08 March 2016).

F.B.I., (2010) Former Employee of Fannie Mae Contractor Convicted of Attempting to Destroy Fannie Mae.
Available at: https://archives.fbi.gov/archives/baltimore/press-releases/2010/ba100410a.htm
(Accessed: 03 March 2017).

Farrell, S., (2016) TalkTalk counts costs of cyber-attack.
Available at: https://www.theguardian.com/business/2016/feb/02/talktalk-cyberattack-costs-customers-leave
(Accessed: 02 March 2017).

Hall, K., (2016) TalkTalk admits losing £60m and 101,000 customers after that hack.
Available at: https://www.theregister.co.uk/2016/02/02/talktalk_hack_cost_60m_lost_100k_customers/
(Accessed: 02 March 2017).

ISO/IEC, (2016) ISO/IEC 27000:2016(en) – Information technology – Security techniques – Information security management systems – Overview and vocabulary.
Available at: https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-4:v1:en
(Accessed: 05 March 2017).

Kin, W., Jeong, O.-R., Kim, C. & So, J., (2011) The dark side of the Internet: Attacks, costs and responses. Information Systems, 36(3), pp. 675-705.

Matthews, T., (2014) Incapsula Survey : What DDoS Attacks Really Cost Businesses.
Available at: https://lp.incapsula.com/rs/incapsulainc/images/eBook%20-%20DDoS%20Impact%20Survey.pdf
(Accessed: 02 March 2017).

McGoogan , C. & Palmer, K., (2016) TalkTalk loses 101,000 customers after hack.
Available at: http://www.telegraph.co.uk/technology/2016/02/02/talktalk-loses-101000-customers-after-hack/
(Accessed: 02 March 2017).

Ponemon Institute LLC, (2013) 2013 Cost of Data Breach Study: Global Analysis.
Available at: https://www.symantec.com/content/dam/symantec/docs/reports/cost-of-a-data-breach-global-report-2013-en.pdf
(Accessed: 02 March 2017).

Skinner, R., (2017) NetSec Week1.
Available at: https://learn.ucs.ac.uk/webapps/blackboard/execute/content/file?cmd=view&content_id=_606238_1&course_id=_19349_1
(Accessed: 02 February 2017).