|
|
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:
- Assets and risks
- Security plans and policies
- Security mechanisms
- 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.
|
