ITS 2110 - Introduction to Network Security

Chapter 9 - Client and Application Security

Objectives:

This lesson covers chapter 9 in the text. It discusses general security for client computers. Objectives important to this lesson:

  1. Securing a client device
  2. Using physical security
  3. Application security
Concepts:

Chapter 9 begins with an explanation that a host is any device on a network (e.g. a computer, a printer, or any other device that can be given a network address.A client is a device that sends requests to severs, computers that are more powerful and capable of sharing their resources to other devices. Most computer networks are called client-server networks because they follow this model.

The text presents some history about hardware and processes used to boot (start) "early personal computers", by which the author means computers built after 1970. The discussion about the transition from BIOS (Basic Input-Output System) chips to UEFI (Unified Extensible Firmware Interface) is a little light. This article on howtogeek.com is a bit more readable and detailed. Short version: UEFI supports more memory and larger storage devices at boot time. BIOS chips could only operate in 16-bit mode, so modern processors have to gear down to use them, at least until the main operating system is loaded. For an explanation in a video, take a look at this one:


The video discusses the memory and storage device issues, but it goes to a commercial at about 3:55, which we can skip. UEFI supports Secure Boot which is meant to protect your computer from having its operating system perverted. The system starts by verifying hardware, then verifying each layer of software in a chain of trust. Like most features, you can turn Secure Boot off, which you would want to do if you need your computer to be able to boot into multiple operating systems.

The text discusses electromagnetic spying, which is not too hard to understand, but a bit hard to do. Follow this link to a story on Wikipedia that explains that the problem was known back in World War II. Electronic devices radiate energy. That energy can be detected and analyzed. It was possible, for instance to pick up the radiation put out by a CRT monitor, and to recreate the image that monitor was displaying. It may be more interesting to know that reconstruction of the processing going on in a computer can be attempted from captured electromagnetic radiation, from electrical usage, from signal loss through wires, and by flux in magnetic fields. This is not a joke. The text tells you about the Telecommunications Electronics Material Protected from Emanating Spurious Transmissions, or TEMPEST standard created by the US National Security Agency. As the text explains, the standard proposes shielding, filters, and separation of components whose emanations might be detected. The text does not mention that TEMPEST also covers methods to use such methods to spy on such equipment. If you think about it, the goal of guarding against such spying implies the knowledge of how to do it.

On page 379, the text turns to securing an operating system. It begins with a list of six OS categories, each of which is a bit different.

  • Network OS - runs on network infrastructure devices
  • Server OS - runs on servers in networks
  • Workstation OS - runs on client and standalone computers
  • Appliance OS - runs on a device (like a camera or a game machine), usually a cut down version of workstation software
  • Kiosk OS - runs on an information device in a lobby, a store, or a travel terminal; may be similar to workstation software, but usually much less complex
  • Mobile OS - runs on smart devices, tablets, and other "low end" computers

We could say that devices toward the top of the list require more complex operating systems. Operating systems with more features will require more protection. The text presents a short list of typical OS security concepts:

  • disable unnecessary ports and services - in this recommendation, the word port means a named location in memory that is used to communicate with a program or service; tell the computer not to run services you don't need, and not to check ports that you don't intend for it to use
  • disable default accounts and change default passwords - any attacker will look up the default accounts with elevated rights in your OS, along with their default passwords in order to exploit these built-in vulnerabilities
  • employ least functionality - this is about user rights and permission; don't assign rights to a user account that the user does not need
  • application whitelisting /blacklisting - take either the approach of listing all allowed applications (whitelisting) or all forbidden applications (blacklisting)

The text recommends establishing a security template (a set of configuration parameters) that can be pushed to a Windows computers with an Active Directory Group Policy. It also recommends that patches for various OSs should be pushed to all applicable devices that attach to such networks. A model for such a plan is shown in the graphic on page 383. Typical options for such systems are discussed on the pages that follow.

The text discusses a few categories of software that help protect an OS. They would be equally recommended for all operating systems.

  • antivirus/antimalware software
  • antispam software (typically installed as part of an email product)
  • antispyware

The next several pages of the text are not relevant to the topic of the chapter, so we will move on to page 392 and the discussion of physical security. 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. The text also mentions barricades and bollards, both of which come in a variety of styles. The short video below demonstrates a bollard model that can be raised and lowered as needed to prevent or to allow traffic through a choke point.

The text recommends that guards and cameras 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. The text mentions banks as a commonly available example of businesses with areas for the general public, and areas that are for staff only. Banks often have high counters, gates, security barriers, guards, and bullet resistant glass or plastic barriers between staff and customers. Data centers do not generally provide service to the public, but is not uncommon to have a data center share a building with another service from your company that does invite customer traffic. When this is the case, there must be controls to prevent access by people who should not have access.

Under the heading of automated security, the text discusses several types of sensors that will set off alarms or communicate to staff when they are set off.

  • visible light and infrared cameras and motion detectors
  • radio frequency sensors
  • vibration sensors
  • sonic alarms, which may be microphones listening for sounds or for disruption of ultrasonic sounds the sensors emit
  • magnetic sensors

A few pages discuss types of locks. It is a short list, so let's consider the items on it. This article on Wikipedia discusses some of the same physical locks.

  • pin tumbler lockWarded locks use wards which, we are told, are permanent projections inside a key operated lock that prevent a key from turning unless it is cut so that it avoids the wards. This sort of lock is the simplest one in the list and it can be picked easily, even with a thin key cut to miss most wards.
  • Tumbler locks are more common, and harder to pick because they require the key to push several pins, that are attached to springs, up to different correct heights. When the two-part pins are in the right position, each will allow the cylinder of the lock to turn. The picture on the right shows this kind of lock.
  • Combination locks - The combination locks most of us have used operate on a different system that makes them much harder to pick. Wheels inside the lock must align to make it possible to open the lock. The text warns us that electronic versions of these locks do not work the same way. They are really just password systems that use a number as the password.
  • Cipher locks - You can run a Google search on this kind of lock to see that there are many styles. The typically have several buttons that can stand for numbers or letters, and they can be set to open to most any combination of key presses that the user wants. The text explains that they can also work with swipe cards and with biometric sensors.

On page 401, the chapter opens its third topic, application security. Applications can be as vulnerable to exploitation as operating systems, and they can provide attack vectors for exploiting the operating system as well. Pages 401 and 402 list some classic methods of attacking a program. The text advises us that the best protection comes from thinking about possible attacks while an application is still being written. In fact, the author wastes a could of pages discussing software development techniques before exploring some advice on page 404.

Coding technique What does it do? Why?
Error handling
Stop, present error message, or continue program Avoid crashing the program and giving the attacker access to the computer
Input validation
Reject invalid data, ask user to input proper data
Avoids injection attacks and scripting attacks
Normalization Normalize data in tables
Reduces redundancy and data exposure
Stored procedures, code reuse, and SDKs
Organizes code in reusable modules
Reuses tested code, avoids extensive testing of unproven code
Validate input on server and client side
Checks for valid data on each side of a client-server relationship
In case we miss or the attacker works around validation on one side

The last recommendation in the chapter is to thoroughly test programs, whether you write them yourself or not. Test with samples of live data, live operators, large scale usage, and in any way programs have failed in your environment in the past.