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.
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:
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.
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.
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.
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.
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.
|