CET2176C - Server+ Lecture #5 - Introduction to Security

Materials:

Lecture Only
Objectives:
The student will become familiar with:

The basic concepts of security,

Categories of security: data integrity and data confidentiality,

The common risk factors,

The security policy,

Physical and logical security.
Competency:
The student will become familiar with the basic concepts and foundational computer science philosphies concerning network security. The student will be aware of the common risk factors concerning hardware, software and data and understand the importance of designing, implementing, maintaining and enforcing security and the security policy for the server and the network.

Security of the Server and the Network

Security starts by clearly defining it:

 Definition: Security - Protection of a valuable commodity.

Security starts by identifying the valuable commodity which needs to be protected. In the case of the network and the server that runs it, this would be the data and the server that holds it. Next, the requirements and vulnerabilities must be identified. This is followed by the formulation of a security protocol or security policy. Just like any IT project this will be followed by prototyping, piloting, and implementation. These phases will be followed by evaluation, correction/modification phases until the system is stable. The long-term maintenance phase of the security policy is the establishment of continual monitoring and testing of the system. In the event of a breach the organization needs to have a contingency plan as part of the routine maintenance phase of the security policy. For large organizations with extremely sensitive and valuable data, this will include a Computer Incident Response structure which may incorporate the Help Desk and a specially trained Computer Incident Response Team. All of this falls under the Enforcement role of the security maintenance phase.

The security project then consists of:

	Planning Phase: determination of the access requirements (what data sets must be accessible and by whom) and the vulnerabilities, how might data be compromised and how can this weakness be minimized.
	Prototype Phase: Creation of Security Policy, the construction of an organized, itemized and clearly defined set of protocols for implementation
	Pilot Phase: Initial implementation of the security policy, may be to a limited set of systems to ensure reliability and functionality
	Implementation Phase: widespread adoption of the security policy
	Evaluation Phase: checking reliability and functionality of the security policy
	Correction/Modification Phase: accumulation of the evaluation data and implementing any needed corrections and/or modifications
	Repeat Evaluation and Modification phases until the system is stable
	Maintenance Phase: Security Monitoring policies and procedures should already have been defined as part of the overall security policy and should also be tested during the prototype, pilot and implementation phases
	Enforcement Phase: Undertaken in the event of an incident, incident policies and procedures should already have been defined as part of the overall security policy and should also be tested during the prototype, pilot and implementation phases.

Since the server is an integral, indeed central, node of a network, its security is also an integral component of the overall network security. However, the server itself is an asset or valuable commodity and so this must be taken into consideration. Unlike the data which is not a physical asset, the server is a physical asset and to that end introduces completely unique security issues that are not a consideration in the overall security policy of the network concerning its data. The server security policy, a subset of the overall security policy should then address:

	Server access control: only designated authorized personel should have physical access to the server
	Server access monitoring: all authorized accesses to the server should be logged including the purpose for the entry, unauthorized access should be detectable and recordable.
	Server access incident response: in the event that the server is accessed without authorization what steps will be taken concerning: authorized employee infraction, unauthorized employee infraction, and non-employee intrusion
	Server content access control: computer security policy for the system data (operating system) and the organization's data (software and data files)
	Server content access monitoring
	Server content access incident response

In the case of the server, both physical security as well as logical security policies and procedures will then be required. Depending on the organization, physical server access control may be as simple as keeping it in a locked closet or as advanced as manned guard stations, magnetic "swipe" card controlled locks, motion detectors and closed circuit security cameras.
There are steps that can be taken within the physical design of the server to ensure local physical security of the content as well, but under no circumstance should a PC-based system ever be considered physically secure if someone can get there hands on it. The PC-based system architecture was never designed with this issue in mind, and in fact the architecture lends itself to the opposite: ease of access to both hardware components and the data held in them which is directly related to the fact that the PC-based system is "user-friendly"

Physically securing a PC-based system from physical intrusion:

	Secure the chassis: rackmount systems include lockable boxes or "racksafes" which prevent unauthorized personel from physically touching the server. Example
	Removable/Hotswappable drives should be lockable: remember that most such locks are not security based and instead serve as power switches that make the user stop and think "do I really want to remove the drive?"
	Disable all onboard USB controllers in the BIOS: disable all other external peripheral ports including serial and parallel ports if present and not used. If this is not possible, another motherboard may be advisable.
	Disable all other boot devices in the boot sequence allowing only the system drive(s) to boot
	Do not install any removable media bootable drives including FDD's or optical drives
	Set a password for entry into the BIOS Setup and another one for bootup
	Physically remove all input/output devices including the keyboard, mouse and monitor. If impractical then make it necessary to unlock the racksafe in order to attach the cables for these devices to the server
	Secure network connectivity connection: the server should not be equipped with a wireless NIC, and wired NIC's connectors should be difficult if not impossible to detach the cable without unlocking the racksafe

It can be seen that the vulnerabilities being addressed are an attempt to make it as difficult as possible to:

1) boot to an alternate boot disk or device

2) use the server including its BIOS Setup Utility

3) remove drives

4) remove the server completely
Logical server security is in essence network administration which falls beyond the scope of the Server+ curriculum. However, the Server+ professional should be aware that logical security falls under the general categories of:

1) Hardware level passwords and encryption: the ATA/IDE interface has supported hard drive passwords and encryption for a long time in laptops, but this technology is rarely implemented in non-portable systems.

2) Encrypted file system: some operating systems including Windows 2000 and higher now support encryption at the file system driver level, while a few of the boot files must be stored unencrypted, all sensitive data can be encrypted, furthermore, all sensitive local security data in Windows 2000 and higher is kept encrypted.

3) Encrypted Authentication: all over the wire logon credentials should be transmitted encrypted: i.e. Novell Netware 4.11 Servers/Workstations exchange NDS tree logon packets encrypted using the RSA asymmetric encryption protocol natively (it takes an administrators action to disable this, which should never be done)

4) Authentication policies and procedures: The administrator can force minimum password length, limit maximum number of bad logon retries, valid logon locations (computers) from which the user can logon, time/day user logon restrictions, etc.

5) Operational authentication/logon restrictions/policies: Employees should know that they are never allowed to logon at any machine except where they are assigned and authorized to do so, they should never share sensitive information with others, they should never write down or keep sensitive data in plain text or in the clear, etc.

6) Event logs should be customized and organized to flag significant events and should be reviewed regularly

7) System monitors should be customized and organized to flag significant activities and should be running at all times, and someone should be assigned the responsibility of receiving system monitor messages and responding to these when they occur (Computer Incident Response System)

8) Extensive knowledge and familiarity with the system: allows administrators to identify suspicious behavior of the systems and of the users.
Logical security falls into two basic categories: data confidentiality or access control and data integrity. Access control is the one that most people think of when asked "what do network administrators do?" However, access control itself is an extremely complicated subject. Within the network environment there are three basic methods of controlling access to a particular object, say a file:

1) User-level rights - the user's profile indicates that they have rights to the file (trustee assignment)

2) Share-level rights - the object's profile lists all of the users who have rights to the file (trustee list)

3) Discrete-level rights - there is a direct and specific profile that states that this user has certain rights to this file, a standalone rights assignment.
Obviously no administrator wants to go through the network building a security access control matrix one discrete-level rights assignment at a time. The user rights or trustee assignments and object rights or trustee lists are built in one of two ways: to grant global access then deny access to specific areas, or to revoke global access then grant access to specific areas. In the first methodology, everyone has access to everything and then the administrator goes around applying access restrictions to certain areas as needed. While this requires less time to establish, it takes more time to evaluate and correct as access holes are discovered and then eliminated. In the second methodology, it takes much longer to establish, because hidden OS level functions may require a user to have unforeseeable rights to seemingly unrelated objects in order for certain functions to work properly, and it may take as much time through the evaluation/correction cycles, but it is inherently far more secure, erring on the side of the pessimist: assume noone needs the right to anything, then everything is secure. then grant rights to objects as it becomes apparent that these rights are necessary.
Data integrity security falls into the general objectives of:

1) Disallow authorized users from making unauthorized modifications to the target

2) Disallow unauthorized users from making modifications to the target

3) Maintain data consistency (i.e. disallow multiple simultaneous authorized changes to the target)
Data integrity control is usually manifested in the form of the individual or "atomic" rights that can be assigned to an object in the case of a file in the Microsoft DOS file system this can be:

R - Read-Only - all users may inspect the content of or use the file, but they cannot modify it

H - Hidden - no user is allowed to know that the file exists

S - System - considered part of the operating system, in early versions this was a combination of the hidden and read-only attributes but in later versions this effect was removed.

A - Archive - indicates that the file has been modified, the time/date stamp will indicate the last time this happened
A File attribute is then a form of object assigned data integrity control rights, each individual right, such as the read-only attribute is an atom within the complete set of file attributes for the file. The trustee list is not explicit, but instead implicit: the rights apply to all users of the system. Obviously, DOS was intended for a single-user environment, not a multi-user networked environment, thus the simple file access control/data integrity system. In Novell Netware, users can have the following rights assigned to them (user-level rights) for specific files or contents of entire driectories:

S - Supervisor - an atom that gives the user all of the following rights at once

R - Read - The right to inspect the content of a data file or execute an executable file

W - Write - The ability to create new data (add content, modify content of existing files)

C - Create - The ability to create a new file, salvage (undelete) files

E - Erase - The ability to erase or delete the file

I - Inherit - Allows rights on the object to inherit down (rights to the directory flow down into subdirectories of it)

M - Modify - The ability to change attributes of the object, but not its content

F - File Scan - The ability to see that the object exists but nothing else

A - Access Control - The ability to grant rights to others to the object
Clearly these are attributes designed for a multi-user network environment. Individual objects also have their own attributes that they hold much like the DOS-type file attributes. These share-level rights assigned to each specific file or groups of files include:

A - Archive (same as a DOS attribute above)

Ci - Copy inhibit - will not allow any user to copy the file from the current location to any other location

Dc - Don't compress - keeps the native file system compression driver from compressing the file

Di - Delete inhibit - keeps any user from deleting the file

Dm - Don't Migrate - keeps the secondary backup subsystem from migrating the file out to long term off-line storage (such as a tape backup) Files that have not been used for a long time, are moved automatically out, this stops this behavior from happening to the file (or all contents of the directory if applied to a directory)

Ds - Don't suballocate - The file system can suballocate unused sectors within a file's last cluster to store other files, this prevents this behavior.

H - Hidden (same as DOS hidden attribute)

Ic - Immediate compression - indicates that the native file system compression should be done on this file as soon as possible

N - Normal - Indicates Read/Write user rights to any user who does not have a distinguishable set of rights to the file (disambiguation)

P - Purge - Fully deletes the file if it is deleted, all files when deleted in Novell are moved to a salvage region from which they can be salvaged (similar to the recycle bin) This prevents this behavior and allows it to be really deleted

Ri - Rename inhibit - Disallows any user from renaming the file

Ro - Read-Only (same as DOS Read-Only)

Rw - Read/Write - allows users to read the content and write new content into the file

Sh - Shared - allows the file to be opened simulateously by more than one user

Sy - System - Identifies the file/directory as part of the operating system, hides it from directory listings

T - Transactional - flags the file to be protected by the Novell Transaction Tracking System

Xo - eXecute Only - Allows the executable file to be executed, nothing else, implies Copy inhibit
It is important to distinguish the roles and behaviors of user assigned user-level rights vs. atomic object based attributes or share-level rights. Object based file attributes for example, apply to all users and are part of the data integrity control security objectives, user assigned rights including trustee lists assigned to the object incorporate, in the Novell security system, elements of both overall access control as well as data integrity control. It is obvious from this discussion, that the actual implementation of data confidentiality and data integrity security measures even within an extremely well designed network operating system are not clearly defined. As such it is important to establish the data security criteria in order to analyze what measures are necessary in order for the system to apply the security requirements that are needed.
There seems to be a growing observance in computer science that data protection (preservation of data integrity) is a mechanism while data security (user-level access control or data confidentiality) is a policy. In the examples above from the Novell Netware server operating system is can be seen that file attributes center around data integrity (protecting the file from inadvertent user caused damage or deletion) and these file attributes are considered data protection mechanisms attached to the files themselves with no regards as to the rights of any particular user. A file marked Di - Delete inhibit for example, will not allow a user with the "E" (erase) right within the directory to delete it. As a data protection mechanism it overrides the data confidentiality based security policy given to the user in the directory. The network security, and this implies server security, then revolves around the two basic comcepts of data integrity which is intimately bound into the server design and implementation and data confidentiality which is intimately bound into the network design, implementation and administration. Because the server is the central node on the network, and the seat of the network administration, it stands to reason that the designer, the Server+ professional, needs to have some basic network security understanding.
The foundation of any form of security taken as the protection of a valuable commodity, when applied to an information technology framework such as an organization's network, begins with the proposal phase which put simply, is the identification of risks and threats to the organization's data. These risks fall into the following categories:

People based risks

Hardware/Network Design based risks

Software/Protocol based risks

Public Access based risks

People based risks include:

	Data loss due to human error
	Data loss or theft due to malicious user actions including: External Hacker intrusions Internal Hacker intrusions (disgruntled/disloyal employees) Social engineering: both internal and external Cracker activity: both internal and external, obtaining encrypted data and cracking it
	Examples of data loss or theft due to inadvertent user actions include: Administrator fails to create adequate security policy Administrator fails to enact adequate maintenance phase security policy (monitoring/auditing) Administrator fails to deactivate or delete unused accounts Users sharing accounts Users logging in from other users workstations Users writing down or saving plain text files with sensitive information (username/password, etc.) Unattended private PC left on and/or connected Unattended private PC left logged on Inadequate/ineffective usernames, passwords, and/or policies regarding them Unattended unlocked server/telecom room Discarding media without proper processing

The only way to combat data loss and/or theft resulting from inadvertant user actions is through training. End-users should be sufficiently computer literate to avoid simple yet devastating mistakes like overwriting existing files. With hard drives as large as they are and as relatively cheap as they are in dollars/GB there is no need to overwrite any file. When the operating system issues this warning, users should know that they must name the new file something else, and then check into the reason they had another one with the same name later. Users should know where their files are being stored within the file system and they should know what they are naming their files. From the list above it is obvious that the network administrator should not just be computer literate, but must be well trained for the position. To this end, most employers demand that the network administrator possess at the very least an industry standard certification related to the position such as the MCSE - Microsoft Certified System Engineer. However, even with a well trained workforce and a certified professional computer network staff, there are plenty of other inadvertent user actions in the above list that can result in the loss, or worse, theft of sensitive data. This is why a security policy must be developed, implemented, administrated and ultimately be enforced if necessary.

Hardware/Network Design based risks include:

	Accessible cables/ports: point of entry for intruders
	Wireless transmissions: easily captured transmissions, even encrypted packets can be cracked given time
	Leased public communication lines: can be tapped
	Ethernet hubs: rebroadcast all traffic to all ports
	Routers (and other devices) left set to factory defaults and/or improperly/inadequately configured: often leave easy points of entry for intruders
	Modems or any other communications port/device attached to any node: can provide an easy point of entry
	Dial-Up/Remote Access Servers left set to defaults and/or improperly/inadequately configured: can leave open an easy point of entry
	Computers hosting sensitive data attached to or accessible from public access segment/domain: easily avoidable vulnerability in the network architecture

Clearly the network architecture plays a significant role in addressing the hardware/network design based security risks as does proper training of the information technology staff such that hardware/network design based risks can be minimized if not eliminated completely. Servers accessible to internal or external unauthorized users are of special concern to organizations and they are willing to undertake substantial expenditures toward modifying network architecture in order to eliminate these threats.

Some common software/protocol based risks include:

	TCP/IP is not a secure protocol: it is a generous and prolific data delivery system
	Improper domain design/administation: can lead to an unexpected trust or right which a hacker can use
	Network OS/Software contain vulnerabilities or security flaws: updates correct these as they are discovered, but there are periods of vulnerability between the discovery, proliferation of the exploitation and the patch
	NOS operators should not be able to exit to a command prompt or execute unauthorized OS/Software scripts
	Accepting installation defaults: These are usually designed to make the installation and automatic start of the OS or software package or service easy - not secure
	Transactions between systems especially between wireless transceivers or across the Internet: can be intercepted and cracked if necessary

Examples of Public Access segment/domain security risks include:

	User unplugging the networked PC and attaching their own device or system
	User installing malicious software (hacking tools, i.e. keyloggers, rootkits, etc.) or virus on the public system
	Telnet and FTP transmit user name and password unencrypted
	Malicious users can get user information from web forms filled out at spurious or dishonest websites (phishing)
	If an internal address is known, a hacker can gain entry by IP spoofing, setting his IP address equal to an internal valid one and the router/firewall allows the traffic in
	While users are chatting, others can send commands to their system (cross-site scripting vulnerability)
	Denial-of-Service attacks in which attackers flood the target system with too many packets so that the system gets paralyzed. (Likely targets are routers, firewalls and servers)

Defense against the majority of malicious user threats starts with the security policy. The security policy itself starts with a basic set of goals starting with a set of rules and regulations covering policies and procedures whose ultimate goal is to maintain the data integrity:

	Ensure that authorized users have sufficient and appropriate rights to the resources they need
	Ensure that data is protected from access by unauthorized users, both internal and external
	Prevent accidental damage to hardware, software and data
	Prevent intentional damage/theft to hardware, software, and data
	System should be capable of detecting, responding to, withstanding, and recovering from any threat
	Establish, publish, and receive acknowledgement of employees responsibilities, the rules and regulations, concerning the organization's security, its maintenance, and its enforcement. That is, be sure all employees are fully aware of the rules and understand that the system is being monitored and the consequences of a breach in policy.

The actual details of the security policy are often particular to the organization's situation ranging from classifications of employees and network support staff to the actual network architecture and the security policy will have to be created individually for each organization. However here are some basic guidelines for developing an effective security policy. Remember that many of the possible security risks to the network data are people based risks and any security policy that depends on the users to observe the rules in order to work; is doomed to fail:

	Ensuring all users have exactly appropriate rights on the network
	Working toward the prevention of unauthorized access to the network which includes logging, monitoring and testing accounts
	Protecting sensitive data from unauthorized access both from inside and outside
	Reporting damaged hardware and software
	Reporting suspicious user activity on any system
	Reporting suspicious behavior of any system
	Reporting suspicious email, disallow the pursuit of unknown emails (all spam must be deleted without opening it)
	Disallow leaving system unattended while logged on
	Disallow filling out forms while on line
	Disallow downloading or bringing in and installing any software
	Disallow attaching or installing any peripheral device
	Disallow sharing of user name and/or passwords
	Users must understand that most of the time email and Internet traffic are not encrypted and very insecure
	Use and enforce effective password policy
	Organized team for security threat response
	Strong and consistent monitoring and enforcement
	Clear and effective communication of the security policy to all employees

An effective, or strong, password policy guideline:

	Password must be greater than 8 characters
	Password must contain at least one upper case, one lower case, one digit, one punctuation character (if system allows these)
	Users must choose passwords that do not contain personal info (social security, telephone #�s, address, friends or relatives or pet names or any of their personal info)
	Do not use any actual word that might be found in the dictionary
	Users may not write down nor record nor email their username or password
	Users must change their password on a schedule
	Users may not alternate two or more passwords

Security at the server/telecom room should consist of:

	Keeping the room locked, logging all authorized access and detecting any unauthorized access
	Making it as difficult as possible to physically gain access to the server and its content
	Proper design, installation and construction including factors listed above
	Elimination of physical design based risks including factors mentioned above
	Data integrity objectives should be met

The data integrity objectives of the server involve the ability to detect, respond to, withstand, and recover from any threat. Factors that assist in attaining these basic data integrity objectives include:

	Implementation of a sound, well maintained and organized software suite including an anti-virus, anti-spyware, firewall, and OS functions, settings and utilities designed to manage and maintain the server's data integrity.
	Maintenance of the software suite
	Regularly scheduled testing of the software suite
	Implementation of a sound, well maintained and organized backup scheme
	Maintenance of offsite data backups
	Regularly scheduled testing of backups
	Implementation of sound, well maintained domain organization of users, groups, rights, etc.
	Maintenance of the domain organization including configuration of event logs and monitoring software
	Regularly scheduled perusal of event logs and monitor alerts
	Regularly scheduled security audits and testing
	Implementation of sound, well maintained fault tolerant and redundant storage: RAID
	Implementation of sound, well maintained fault tolerant and redundant power supply: surge protection, line conditioning, battery backup UPS and generators
	Maintenance of fault tolerant and redundant systems
	Regularly scheduled testing of fault tolerant and redundant systems

Review Questions

Define security:
What are the two basic categories of logical security? Define each one.
List and describe the six points of the server security policy.
List and describe the eight points of physically securing a PC-based computer.
The objective of the eight points of physically securing a PC-based computer is to prevent what four things?
List and describe the eight general categories of logical server security.
List and describe the three basic methods of data confidentiality or access control.
What is an access control matrix?
Describe the two ways in which access control for the network can be constructed?
List and describe the three general objectives of a data integrity security protocol.
Which atomic object-level attribute(s) in DOS would prevent any user from deleting the file.
Which atomic object-level attribute(s) in the Novell file system would prevent any user from deleting the file.
Which user-level rights in the Novell file system would allow the user to delete the file.
Which category of logical security is often called a mechanism? Why?
Which category of logical security is often called a policy? Why?
If a security mechanism and a security policy are in opposition, which takes precedence?
List the four categories of security risks on the network.
List the three major categories of people based security risks on the network.
Give four examples of data loss or theft due to malicious user action on the network.
Give three examples of data loss or theft due to inadvertent user action of the administrator of the network.
Give two examples of data loss or theft due to inadvertent user action of the personel authorized to access the server/telecom room of the network.
List eight examples of hardware/network design based security risk on the network.
List six examples of software/protocol based security risk on the network.
List seven examples of public access based security risk on the network.
List the six general goals of any security policy.
List the five user activities that any security policy should directly forbid.
List the seven strong password policy guidelines.
List the five strong server/telecom room physical security guidelines.
List the five strong server/telecom room physical security guidelines.
List the four general items that are covered in the data integrity security policy guidelines.
List the three general practices concerning each item in the list form the preceding question that are covered in the data integrity security policy guidelines.