CIS2750 - Securing Information Systems

Chapter 9, Computer Security Technology; Chapter 10, Security Policies

Objectives:

Chapter 9 focuses security software. Objectives important to this lesson:

1. Understanding antivirus tools
   
2. Firewalls
3. More on spyware
4. Intrusion detection
5. Securing networks

Concepts:

Chapter 9

The chapter begins with a discussion of virus scanners, which the author hopes you are convinced are needed for workstations and servers. Viruses are an ongoing problem, which is why the vendors of antivirus solutions are continuously updating their products. It is not unusual to see frequent updates of product software itself, and of the virus signature files the software uses. These signatures are what the antivirus product looks for in periodic scans and, if your configuration allow it, each time a file is created, downloaded, changed, or otherwise added to a protected computer.

The video below discusses how antivirus software typically works.

The text mentions a few "name brand" antivirus products. There are many more, and decision to buy or try one should be based on reviews from trusted sources.

The next section of the chapter discusses firewalls. The video below discusses several points you should understand from the chapter. The presenter seems to know what he is doing, so pay attention.

Our author has been trying to keep the chapters shorter by dealing with the most critical material. However, his discussion of stateful packet inspection lacks some necessary details. The key is that it does not allow packets from a source that does not have an established session with one of our network devices. (The exception is packets that establish such a session.)

Another aspect of firewalls is the ability to perform and monitor connections to services inside our network. The firewall can act as a gateway to the services our network provides. The firewall allows outside devices to negotiate connections with itself, then it makes connections between itself and the services the outside devices are requesting. This provides another layer of inspection of the traffic that would otherwise be flowing directly to our servers and their applications. The text tells us that this functionality is called by several names: application gateway, application proxy, proxy server, and application-level proxy.

Professor Messer discusses these features as well as the ones in the other videos. He also explains some of the firewall types in your text, and touches on Intruder Detection Systems (IDSs). Give him a chance. He's a good teacher.

The chapter continues with a discussion of IDS products, and includes a short lesson on using a free copy of Snort as an IDS. Snort is typically used in classes as an example of a packet sniffer, a program that can pick out packets of certain types. As the text explains, it can be used in several ways, the most interesting being as an IDS. It is a free product and some students have loved it in the past, so read through that section and look for a video on Snort.

Of the other topics in this section of the chapter, I like the discussion of intrusion deterrence the best. It is like the advice of Sun Tzu's The Art of War. In the beginning of chapter 3 there is an element of hope. Sun Tzu wrote that "the worst policy of all is to besiege walled cities". It is our goal, in mounting a defense, to present such a wall that the enemy will not waste its effort in an attack. This is the essence of deterrence.

A bit farther in the chapter, the author discusses authentication, and he lists a variety of historical protocols that have been used and replaced by other. The most viable one he brings up is Kerberos, which is used in Windows for login authentication. Here is a video about it that makes the lesson less difficult.

The text wanders around other subjects that seem to be odd choices. It discusses digital certificates at length, goes on about Public Key systems for a bit, brags about certificate authorities and the system of trust that makes them work.

The chapter ends with some discussion of Virtual Private Networks and WiFi security, neither of which are adequate to teach you much. I have to suspect this chapter was made more of copy and paste practice than by writing useful lessons.

The text should provide more detail about how the world uses the public key method: Public Key Infrastructure. Public Key Infrastructure is not the only cipher system used in business or government, but it is widely used by both, and by individuals to protect personal or sensitive information. There is a difference between PKI and public key cryptography.

• Public key cryptography is a system in which each entity has two cryptographic keys, each of which is the only means to decrypt what was encrypted by the other.
• Public Key Infrastructure is a system of using public key cryptography, distributing keys through trusted sources, and revoking keys that have been compromised.

Public key cryptography is how SSL encryption on a web site works. I connect to a vendor's web site. I obtain the vendor's public key by making the secure connection. My browser encrypts my credit card data with the vendor's public key and sends the ciphertext to the vendor. If the vendor's private key is secure, the vendor is the only one who can decrypt the data sent through the public key.

That's the way it is supposed to work in a perfect world. However, attackers have created a need for a security net around the process. In a way, PKI is the success story of businesses that have grown up around this technology. Components of public key infrastructure:

• Certificate authority - An entity, typically a company, that creates digital certificates, which are verified statements of a public key and its owner. They may also create the key pair for the customer, and are responsible for storing and providing certificates as needed.
• Registration authority - An entity that receives requests for certificates, verifies the requests are from recognized users (such as merchants processing credit cards), and forwards the requests to certificate authorities.
• Certificate server - A service, or the device that runs the service, that responds to certificate requests.
• Certificate repository - A database for storing digital certificates, sometimes including records of revoked certificates.
• Certificate revocation list - A list of certificates that are no longer valid for various reasons.
• Certificate validation - A process used to make sure that a request submitted for certificate creation actually came from the organization it appears to come from, and that the key submitted in the request is theirs.
• Key Recovery Service - A service that stores and recovers encryption keys in case they should be lost, for example in a system crash or attack.
• Time server - A service that provides a standard time reference, used to mark the time of requests and responses. Timestamps may be used to judge whether requests are being processed by the entity we expect to process it.
• Signing server - In a system that is increasingly automated, this is a central control over related services.

Chapter 10, Security Policies

Objectives:

Chapter 10 discusses policies, which are rules that are followed by people or by software. Objectives important to this lesson:

1. What are information security policies
2. Types of security policies
3. Developing security policies

Concepts:

This chapter covers information security policies, which the text tells us are the heart of an effective security program. The text says that policies are inexpensive (they are just rules) but hard to implement, because they have no effect if people do not comply with them. So what makes a good policy?

• A policy should not be in conflict with applicable law. (Should not? Maybe the author meant must not.)
• A policy must stand up in court when challenged. This sounds like the first rule, but it is more about proving the legality of the policy itself, not its being in accord with existing laws.
• A policy must be properly supported and administered: supported by authority in the enterprise, and implemented and enforced correctly and fairly.
  

The text lists some benefits that policies have for management:

• reference for internal audits - this proves we have a policy
  
• reference for legal disputes - shows that management made the policy accessible to those who should have acted under it
  
• statements of management's intent - serves as a guideline for staff who may need to act when management is not available for consultation
• not listed: justification of actions - staff can refer to a policy when they need to explain themselves to management
  

That list of justifications looks more like a list of alibis. It's not our fault, your honor, we told everyone notto do what they did. Do they serve any constructive purposes? Well, they should. Let's consider some (the text finally got around to them) definitions:

• policy - a plan that influences decisions;
  a guideline for decisions and actions;
  needs to be understood by those meant to follow it because it is a set of rules about what actions are acceptable and what actions are unacceptable
• standard - a statement of what must be done to comply with a policy;
  example: a standard might require that workstations bought for use in a particular area (e.g. systems development) must be either of two specific approved workstation models in order to comply with a policy that we only purchase workstations from a short list from a contracted vendor; a standard is typically more specific and narrow than a policy, and tells you how do what you need to do so you don't break the rules
• practice - if a policy and its standards are still a bit vague, a practice is document that spells out more specifically what we must do to be in compliance;
  if standards are specific enough, a statement of practice may not be necessary;
  if different work areas, for example, must follow the rules indifferent ways, they may each have a statement of practice to tell staff how to comply in their jobs
  

The text has a long list of requirements for a policy to be effective:

• must be properly written - understandable, relevant, clear
• must be distributed - although the historical legend about ignorance of the law not beingan excuse, it is not sensible to expect staff to comply with a policy they are not told about
  
• must be read - if we email a policy statement to all employees, does that guarantee that they all will read it?
  
• must be understood and agreed to - it is frequently amazing that people will agree completely with a policy as long as it applies to someone else, not them
• must be uniformly applied - the rules should be the same rules for everyone, or the policy willcause those who must follow it to resent those who do not and those who make and enforce the rules
  

The points above are sensible but arguable. Have you ever worked someplacewhere all the rules apply equally to all employees? If so, it must not have been a very large organization.

The text continues with a list of topics that should be addressed by issue-specific security policies:

• email
• Internet use
• system configurations (of workstations and other equipment, such as Point of Sale devices)
• rules about hacking, including rules about installing unapproved software
• approved use of company equipment at home
• allowed use of personal equipment on company networks
• allowed use of networks/telephones for company or personal business
• allowed use of photocopiers
• prohibited uses of company resources

The text makes a large distinction between policies created at three levels:

• Enterprise Information Security Policies - high level, enterprise-wide rules
  
• Issue-Specific Security Policies - concerned with usage and operational rules for specific systems
  
• System-Specific Security Policies - may be standards for setting up or maintaining systems

The text reminds us that in the creation phase of a policy, it should be approved by your management, human relations authorities, and appropriate legal staff before you consider distributing it and putting it in force. All staff should understand that a policy is a work rule and that it must be followed.

The discussion of Disaster Recovery policies in this chapter is well meant but misplaced. it belongs elsewhere.