NET 226 - Designing Internetwork Solutions

Chapter 8, Developing Network Security Strategies

Objectives:

This lesson concerns making choices about security in your network. Objectives important to this lesson:

  1. Assets and risks
  2. Security plans and policies
  3. Security mechanisms
  4. Modularizing security design

Chapter 8

Assets and risks

The chapter begins with a discussion about general security concerns. This will be familiar to you if you have had any security classes in this program. The author presents a list of  twelve phases in the development of a security program on page 234. She tells us that this chapter addresses seven of them. The first two phases are to identify assets and risks that those assets are vulnerable to. In fact, this is often taught as three parts of a single phase: identify assets, determine vulnerabilities, and list the risks and threats that would exploit those vulnerabilities. The author remarks that she covered these concepts in chapter 2, but she only hit them briefly. These are the first two of her twelve points.

The text moves on to the third point, analyzing requirements and tradeoffs. The point of the discussion seems to be that security can enhance confidentiality and data integrity, but it can decrease availability by making it harder to use a system. We can encrypt all of our data, but we may pay a price in processing power used to do so, and in bottlenecks of passing data through processes and extra devices. These are tradeoffs, giving up some measure of performance or ease of access for the protection our security measures offer.

Security plans and policies

Parts four and five of the author's twelve points have us develop a security plan and a security policy. The text presents the plan as a project to develop our security policy. This is a good idea, because policies can fail from having been made by the wrong people with the wrong information. The text advises us to make a plan based on the customer's requirements for security and on the factual data we have collected about assets, risks, and the company in the previous steps.

Elements that should be included in your security plan:

  • customer's goals
  • network topology
  • network services
  • administration plans for services

The text presents a simplified definition of a security policy on page 236, telling us that it is a set of rules that information system users must follow. It can be a great deal more than that. It should also include background information on why a rule exists, what it should accomplish if followed, and what may happen if it is not followed. On the next page, the text informs us that a security policy should include at least five other, more specific policies:

  • access policy - This should be a set of rules about requesting, granting, revoking, and properly using access to IT resources. The text says that it should include rules about connecting networks, devices, and software to our network. This policy area may also include rules about categorization of data in a series of security levels.
  • accountability policy - This seems to be a set of rules about user conduct, including proper reporting of problems and suspected intrusions.
  • authentication policy - Rules about user authentication go here, which may include rules about passwords and remote access to assets.
  • privacy policy - rules about company rights and employee rights to data, what is personal and what is company owned
  • technology purchasing guidelines - approved equipment lists, rules for requesting an item or requesting approval to make a purchase

A policy often provides a rationale for doing something, and a general statement about what must be done (or not done). A procedure is more detailed and specific. It tells us how to do something. Each policy may have several procedures associated with it, particularly if procedures vary from one product to another, or from one operational area to another.

Security mechanisms

This part of the chapter reviews several types of security, as well as examples of implementing security related processes.

  • Physical security comes in several types. Perimeter security is concerned with placing a boundary around some area, whether it is a room, a building, a complex, or a larger site. A basic concern for any room is a door with a lock, assuming that there are walls that prevent access other than by the door. For a larger area, we might start with a fence and locked or guarded gates.
  • We should also be concerned with physical access controls inside buildings. Common methods include guards and cameras, both of which should be made visible in general work areas, to act as deterrents to unwanted behavior. Barriers between general work areas and sensitive areas should be clearly defined.
  • Physical security also includes physical characteristics and biometric controls, such as fingerprint scanners.
  • Authentication is the process of proving your stated identity to a system. This is commonly done by stating your identity (entering a user ID), then providing the associated proof (entering a password). This is the classic case of authentication by something you know. Authentication is also commonly done by producing a card with computer chip or a magnetic stripe that has been properly coded (something you have). Less frequently, is is done by fingerprint, retinal scan, face or hand print scan (something you are) or by moving your finger over a scanner in a particular pattern (something you do)
  • Authorization - The process of granting or denying permissions to authenticated users. This is a step that happens in the background. Users are typically unaware of it until something doesn't work. The text reminds us that a common practice is to follow the principle of least privilege, granting only those permissions that permit a user to do an assigned job, and either denying or choosing not to grant other permissions. The text mentions that permissions are commonly assigned to groups, but does not mention that it is done to make authorizations uniform, consistent, and manageable for those groups.
  • Auditing (Accounting) - Tracking the actions of all or particular users. This is usually done for specific users or for specific actions when those actions or suspected users might compromise a system.
  • Data Encryption - The text reviews basic encryption concepts and the difference between private key encryption and public key encryption.

    Private key encryption is a system that uses one encryption/decryption key. Each entity using this system, whether a person or company, must have a copy of the key. These copies are distributed to trusted entities. Whatever is encrypted with this key may be decrypted with it as well. The whole system falls apart when a copy of the key is compromised. Private key encryption is an example of symmetric encryption.

    Public
    key encryption is a system that uses two encryption/decryption keys per entity. An entity must have two keys in this system: a public key and a private key. They are created so that whatever is encrypted with one must be decrypted with the other. Public key encryption is an example of asymmetric encryption.

  • Packet filters - The text explains that packet filtering can be enabled on several kinds of devices: routers, firewalls, and servers. The function of a packet filter is to allow or deny the passage of packets based in some kind of detectable property, such as source or destination address, or protocol. The text reviews the two basic types of packet filters. Implicit allow filters block any packets that match stored rules, and allow everything else. Implicit deny filters allow any packets that match stored rules, and deny everything else. (There are other actions the filter can take, but that is the basic idea.) The text mentions that Cisco routers run in implicit deny mode, allowing only those packet that match rules an administrator sets.
  • Firewalls - The text has already discussed packet filtering firewalls in the discussion above. It also mentions some other types. A stateful firewall drops any packet that is bound for a device that is not involved in a properly established session. Proxy firewalls are described in the text as devices that do both functions.
  • Intrusion Detection and Prevention Systems - An Intrusion Detection System only detects an attack, an Intrusion Prevention System detects and takes action to stop intrusions. The text mentions that both kinds of systems can be implemented on a specific host or as a system that operates for an entire network.
Modularizing security design

The text ends the chapter with a long section on protecting particular parts of a network.

  • Securing Internet Connections - If you have not done so in your design, this is the point at which you should define the entry and exit points for your network. The text recommends firewalls, packet filters, authentication, and authorization controls, which should be put in place for the entire network. It also recommends physical security and audit logs, which should be used for devices that provide critical services. This applies to Internet routers and firewalls in particular. The text also recommends blocking all incoming traffic except packets that are requests for offered services, such as web pages and downloads from approved folders.

    The text recommends that we use router protocols that include route authentication: RIP2, OSPF, EIGRP, and BGP2.

  • Securing Public Servers - Public facing servers often provide web services, FTP service, DNS, email, and electronic commerce services. As noted in other chapters, these servers should be in a DMZ, and the DMZ should be separated from the rest of your network by firewalls. Frequent patching for security updates should be a normal procedure. Since the public will submit data in the form of email, search requests, and commerce traffic, these streams should be checked for malware.

    The text calls attention to the FTP service, recommending that it be run on a separate box from the web services, and that we use FTP instead of TFTP. TFTP has no authentication function.

    Public email is a common vehicle for phishing scams and for virus injection, so this email system should be scanned for such things, as should the regular company email.

    The text warns us that the original DNS had no built in security features, so we should take other precautions to avoid DNS hijacking and other threats. Read this article on DNS threats from a 2011 issue of Security Week. Note that it recommends DNSSEC, a more secure form of DNS.

  • Securing E-Commerce Servers - The text reminds us that these are the servers that process payment card information. They will be prime targets for attacks to disable them or to harvest their sensitive information. The text recommends that we defend against DoS attacks with rules that deny successive connection attempts that are too close together in time. It also recommends that a separate DMZ should be created to hold a database server that holds customer information. That DMZ should connect to the one holding the commerce servers, but a firewall should protect each DMZ from attacks from the other.

  • Securing Remote Access - Remote access presents exposure to threats that are part of its concept. We are not on the physical network, so we begin without its protections. The text recommends using CHAP instead of PAP for remote authentication, but both are considered obsolete now. At this time, it would be more common to use Extended Authentication Protocol (EAP) with Transport Layer Security (EAP-TLS), or EAP with Tunneled TLS (EAP-TTLS). A packet that is tunneled (encapsulated) is one that has been wrapped in another kind of packet to make it more acceptable to the network it must pass through.

    The use of RADIUS is more secure, partly because of the required RADIUS server which performs authentication, authorization, and accounting functions, and is meant to support a large number of connections. The number of supported connection may lead to this choice.

    The text warns against the use of dialup connections, suggesting that we not use them. It is more common to use a VPN connection over the Internet, so this recommendation is easy to honor.

  • Securing VPNs - The text recommends we use NAT, firewalls, strong authentication, and data encryption for these connections. The text says that encryption is often done with IP Security Protocol (IPsec). It is implemented at a lower layer in the ISO network model (Network layer) than PGP (Application layer), Kerberos, or SSL (both at the Session layer). As such, it is more transparent to processes that occur at higher layers, to users, and to software running on the workstation. It works well with several security protocols, so it allows you to customize the solution.

  • Securing Network Services and Management - The text has already mentioned some recommended router protocols and it does so again. It recommends in both discussions that we should use static and default routes where possible to avoid updates that might be sent by an attacker.

    Management of switches, routers, and other networking devices should be done with nonstandard IDs and passwords, using a protocol that allows secure access such as Secure Shell (SSH).

    Management of large numbers of switches and routers may be easier with Terminal Access Controller Access Control System (TACACS), which has a horrible name, but it provides a central database of user IDs and passwords. This is also a security risk, so it must be protected. It also provides the ability to require that specific commands to the devices can only be performed by specific IDs. The text also recommends that if we must use SNMP, use SNMPv3 instead, because it supports authentication requirements.


Week 8 Assignment: Chapter 8

  • From Chapter 8:
    • Review Question 4 on page 261
      1. Research a case documented by a reputable source.
      2. Summarize the case, and reference the source.
      3. Recommend methods from pages 253-260 that might have prevented or minimized the breach in question.
  • Read Chapter 9