NSF logo


CCL logo

Cloud Computing Lab Security

Firewalls

ESXi hosts and Windows Servers:

All of the ESXi host computers as well as Windows Server 2008 systems already have Windows firewall enabled by default. ESXi 5.1 has firewall engine enabled by default, it allows ICMP pings and communication with DHCP and DNS clients.

vCenter Server 5.1:

“The VMware vCenter Server system must be able to send data to every managed host and receive data from every vSphere Client. To enable migration and provisioning activities between managed hosts, the source and destination hosts must be able to receive data from each other.

VMware uses designated ports for communication. Additionally, the managed hosts monitor designated ports for data from the vCenter Server system. If a firewall exists between any of these elements and the Windows firewall service is in use, the installer opens the ports during the installation process. For custom firewalls, you must manually open the required ports. If you have a firewall between two managed hosts and you want to perform source or target activities such as migration or cloning, you must configure a means for the managed hosts to receive data.”

The link below outlines the ports required for communication between components: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2031843

NETLAB+ server:

Outside to Inside Firewall traffic:
Since Netlab is installed behind a campus network firewall, it listens for connections on three TCP ports. In order for users to connect successfully to the NETLAB+ server via a web browser, the following ports should be open in the site firewall for outside:

  • TCP 80: TCP web based user interface; provides HTTP access
  • TCP 22: SSH access for NDG staff; technical support; in lieu of SSH can be performed via TCP port
  • TCP 2201: Remote Access Port for lab equipment access and remote PC access

Inside to Outside Firewall:
The following ports should be open for limited outbound connections on Netlab server:


Certificates

Our current test pod installations of ESXi and vSphere use default certificates that are created during the initial installations of the software. These certificates encrypt session information between ESXi and vCenter, as well as, the SSL communications between each of the six main components of vCenter.

Those components are as follows:

  • vCenter Inventory Service
  • vCenter Single Sign-On
  • vCenter Update Manager
  • vCenter Server
  • vCenter Web Client
  • vCenter Log Browser

Each component requires its own unique certificate.

For our small test topology, these default generated certificates will suffice. However, VMware recommends changing the default certificates to certificates from a trusted Certificate Authority, such as Verisign, because the originals are subject to man-in-the-middle attacks. Therefore, for any type of persistent long-term build, it would be their recommendation to either pay a third party for a source of trusted certificates, or to use a self-signed set of certificates.

https://www.vmware.com/files/pdf/techpaper/vsp_51_vcserver_esxi_certificates.pdf


up arrow

Malware and Antivirus Protection

Windows 7 Desktop systems:

  • There is Microsoft Security Essentials on the desktops running Windows 7 in the lab room 456.
  • The settings are set for a quick scan every Sunday at 2:00 a.m.
  • The scans are set to run when the PC is on but not in use.

NetLab server:

There is no need for Malware and Anti-virus protection on the Net Lab server because it is its own “sandbox” and does not touch the internet.


Windows 2008 servers:

  • The Vsphere management which sits on top of Windows 2008 does not need malware and antivirus protection since it does not access the internet.
  • There are settings on this server which will result a denial message when someone attempts to use the internet.

In addition, Durham Tech uses Trend Micro antivirus software on it’s network devices.


Backup Management

We are still in the testing phase of our system setup, so this section provides a basic overview of how backup will work on our system. This content will be updated as needed as we draw closer to the finished product.

Netlab Server:

Since Durham Tech has a support agreement with NetDevGroup (NDG), an administrator can enable an automated daily backup of the database, and it is stored on the NDG CSS server. In case of hardware failure, the database can be restored by NDG.

http://www.netdevgroup.com/support/netlab_css_connect.html


ESXi Server:

In order to back up all the VM images on this server and other VM hosts in case of hardware failure, there is a new backup and recovery solution for the virtual machines called vSphere Data Protection (VDP). It is fully integrated with VMware vCenter Server. Vmware Vsphere Client is used to deploy VDP, after VDP has been deployed, management can be performed using the vSphere Web client with any supported Web browser. Since there are 2 separate hard drives on the ESXi server, one can act as a backup location. It has also been suggested that we can set up a standalone dedicated backup server. Best practice is to have three copies of your data: the original, a backup, and a backup of the backup

http://www.vmware.com/files/pdf/techpaper/Introduction-to-Data-Protection.pdf
http://pubs.vmware.com/vsphere-51/topic/com.vmware.ICbase/PDF/vmware-data-protection-administration-guide-51.pdf (guide)


Windows Server 2008 R2 with Active Directory and ADC backup:

A server database can be backed up using Windows Server Backup. This feature can be set to run backup at any given time, preferably at midnight, or early morning, when network traffic is least congested. It is also important to perform a regular backups of system state data by using wbadmin start systemstatebackup command.

http://technet.microsoft.com/en-us/library/998366c1-0a64-45e6-9ed3-4c3f5b8406f0


up arrow

Update and Patch Management

This document gives a snapshot of the update and patch management settings as of 3/15/2013 for the Windows servers, vSphere server, TFTP, and Netlab server. These settings will change over the course of our progress, to reflect the settings in place when the two test environments are merged into one. Also, after consideration and consult, the agreed upon settings will be put in place by one of the project managers, or by one of the team leaders.

Below is a list of the servers and their update management settings.


Server 2008 R2 with Active Directory, DNS, and DHCP roles:

The current update settings for this server are set to ‘Never check for updates.’ This server is the main AD server so this setting is to prevent updates from occurring until the admins are ready for that process to happen. We can discuss setting up a specific time of the day for this process to occur so that it will have minimum impact on either administrative or end users.


Server 2008 R2 set as ADC backup:

The current update setting for this server is to ‘Install updates automatically every day at 3:00 am.’ As this server acts as another domain controller, updates at this time should have minimal effect on either administrative or end users.


TFTP Server:

In this case, TFTP is being run as an application, as opposed to an actual server. Therefore, the updates can be pulled from the vendor site when necessary.


vSphere Server:

The quote below sums up the update process when we get Auto Deploy to function fully.

“With Auto Deploy, ESXi software images can be shared by all hosts running on matching hardware. Centralized image management eliminates the need to patch and update individual ESXi hosts. Instead, simply perform a single update to the shared image profile and then reboot the vSphere hosts to have the update applied.”

http://www.vmware.com/products/datacenter-virtualization/vsphere/auto-deploy.html


Netlab Server:

Customers with a current support agreement with NDG get their updates via an Internet connection either automatically, or, it can be done manually. “In automatic mode, NETLAB+ will check for updates. If new packages are available, the NETLAB+ server will download and install each package when the lab is not in use.”

http://www.netdevgroup.com/support/netlab_css_connect.html#s2_1


up arrow

Security Policy

Audit Security Policy

Information System Audit Logging Requirements

The purpose of this policy is to minimize the risk of several specific security threats such as random password hack, improper access to sensitive files, or misuse of privileges.

Windows Server 2008 - Logs shall be created whenever any of the following activities are requested to be performed by the system:

  1. Create, read, update, or delete confidential information, including confidential authentication information such as passwords.
  2. Create, update, or delete information not covered in #1.
  3. Initiate a network connection.
  4. Accept a network connection.
  5. User authentication and authorization for activities covered in #1 or #2 such as user login and logout.
  6. Grant, modify, or revoke access rights, including adding a new user or group, changing user privilege levels, changing file permissions, changing database object permissions, changing firewall rules, and user password changes.
  7. System, network, or services configuration changes, including installation of software patches and updates, or other installed software changes.
  8. Application process startup, shutdown, or restart.
  9. Application process abort, failure, or abnormal end, especially due to resource exhaustion or reaching a resource limit or threshold (such as for CPU, memory, network connections, network bandwidth, disk space, or other resources), the failure of network services such as DHCP or DNS, or hardware fault; and http://www.sans.org/security-resources/policies/info_sys_audit.pdf.

vSphere Monitoring and Performance:

  1. Built-in tools to monitor and troubleshoot host and VM performance.
  2. VMs, the hosts, the networking traffic and the storage traffic are subject to monitoring at all times. http://pubs.vmware.com/vsphere-51/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-51-monitoring-performance-guide.pdf.

Computer Security Policy

Acceptable Use Policy

Defines security measures to protect the organization's corporate resources and proprietary information. Durham Tech has the right to establish standards for security, privacy and data integrity on its computing systems as it deems appropriate. The college may determine the nature and extent of access to computer resources and may deny individuals (or groups) access to computer systems and networks. This includes determining who may connect a device to the computer system and the specifications for such a device .

Furthermore, all software installed or used on Durham Tech computers MUST be legally licensed for use on the college premises. Do not copy copyrighted software from computers on campus or install software on campus computers that is not legally licensed.

Users are expected to abide by all federal and state laws governing computer use.

Anyone who violates this policy is subject to the College’s student code of ethics and possible criminal complaint or civil action for damages.

Users may not attempt to evade, disable or “crack” passwords or other security provisions.

In addition, users may not knowingly install any viruses or other destructive computer program onto campus computers.


Password Protection Policy

Defines standards for creating, protecting, and changing strong passwords.

The purpose of this policy is to establish a standard for creation of strong passwords, the protection of those passwords and the frequency of change.

The scope of this policy includes all students of the Capstone Project.

Policy General

  1. All passwords must be changed on a quarterly basis, which means when the course is over.
  2. All passwords must conform to the following guidelines:
    • All students at Durham Tech in the NET289 course must create strong passwords defined as one that contains at least three of the five following character classes:
      • Lower case characters
      • UPPER case characters
      • Numbers
      • Punctuation
      • Special characters (@,#,$,%,^,&,*, ( ), { }, [ ], etc)
      • Contain at least 15 alphanumeric characters
    • A weak password is defined as:
      • One that does NOT abide by the above stipulations.
      • One that includes your name, your friends name, family members or pets names.
      • Your birthday or other personal information such as your address or Social Security Number.
      • Any of the above spelled backwards.
      • Any of the above followed by 1 digit (ie... Barry1)
      • Any common dictionary word or guessable phrase.
    It is suggested to try to create a password from a phrase that can be easily remembered.
  3. Password Protection Policy
    • Always use different passwords for accessing different systems or applications.
    • Do not share passwords with others unless you are certain of their moral character.
    • Do not write down passwords.
    • Do not reveal passwords in emails, text, facebook or any other form of social media.
    • Do not speak about your password in front of other students.
    • Do not reveal passwords in questionnaires or phishing schemes.
  4. Use of Passwords and Passphrases for Remote Access Users
    Access to the Durham Tech Networks via remote access is to be controlled using either a one-time password authentication or a public/private key system with a strong passphrase.
  5. Enforcement and Consequences
    The above are merely guidelines and suggestions gathered from http://www.sans.org/security-resources/policies/Password_Policy
    Any consequences which arise from a compromise of Durham Tech's computer system would be the responsibility of the administration at Durham Tech to resolve.

Software Installation Policy

The purpose of software installation policy is to minimize the risk of loss of program functionality, the exposure of sensitive information contained Durham Tech’s computing network, the risk of introducing malware, and the legal exposure of running unlicensed software

  • Students may not install software on school’s computing devices operated within the school network.
  • Software requests must first be approved by the instructor. Software must be selected from an approved software list, maintained by the Information Technology department, unless no selection on the list meets the requester’s need.
  • The Information Technology Department will obtain and track the licenses, test new software for conflict and compatibility, and perform the installation.

Any student found to have violated this policy may be subject to disciplinary action http://www.sans.edu/student-files/projects/200711_002.pdf


up arrow

Incident Response

Incident Response Diagram

Information Security Policy

Remote Access Policy

  1. The purpose of the remote access policy is to define appropriate dial-in access and its use by authorized personnel.
  2. It is the responsibility of Durham Tech’s students with remote access privileges to use the same consideration as a user on-site.
  3. The student is responsible to ensure that family or friends do not violate any of Durham Tech’s policies.
  4. At no time should student provide their login password to anyone.
  5. User authentication and authorization for activities covered in #1 or #2 such as user login and logout.
  6. All students connected to Durham Tech’s network via remote access must have up-to-date anti-virus protection.

Technology Equipment Disposal Policy

Defines the requirements for proper disposal of information infrastructure.
https://docs.google.com/a/connect.durhamtech.edu/file/d/0B4XYBlcUNW1NZ2E4QjFFVXZSRzA/edit?usp=drive_web

Objectives

Determine whether Technology Equipment (TE) can be sanitized and disposed of as excess unclassified information technology (IT) equipment in accordance with Federal, State and Local regulations; in association with Security Team Policy.

Hard Drives Disposal

In disposing of TE is should be determined by the Security Team that computer Hard Drives contain no information unclassified prior to disposal. Hard Drives must be permanently removed from the computing device and must maintain a chain of custody. A Disposition Memorandum outlines three acceptable methods for hard drive sanitization:

  • Overwriting the hard drive by using software that replaces previously stored hard drive data with meaningless information. Only this method enables a hard drive to be redistributed for reuse.
  • Degaussing a hard drive by demagnetizing it using a National Security Agency approved degausser. Properly applied, degaussing renders data on the hard drive unreadable. After degaussing, hard drives can seldom be used.
  • Degaussing a hard drive by demagnetizing it using a National Security Agency approved degausser. Properly applied, degaussing renders data on the hard drive unreadable. After degaussing, hard drives can seldom be used.
  • Physically destroying a hard drive to ensure it is not usable in a computer and that no data can be recovered or read. Sufficient force is applied to the top of the hard drive unit to damage the disk surface. In addition, connectors that interface with the computer must be mangled, bent, or damaged to the point that the hard drive cannot be reconnected without significant rework. Before a hard drive is physically destroyed, it should be overwritten or degaussed. This method results in the hard drive being unusable.

The method of sanitization and disposal will be recorded with the Certificate of Hard Drive Disposition. Failure to properly dispose of storage TE can have negative ramifications to the environment. It can also result in fines, negative customer perception, and costs of inadvertent disclosure can be as severe as to cause a company to close.


TE Disposal

  • When technology assets have reached the end of their useful life they should be sent to the Security Team for proper disposal.
  • All data will securely erase from all storage mediums in accordance with Security Team Policy.
  • Equipment which is working may be subject to reutilization in accordance with theSecurity Team Reutilization Policy.
  • Before any TE leaves premises, all equipment must be inspected by the Security Teamfor release from the inventory system.

Monitors Disposal

  • Cathode Ray Tube monitors will be disposed in accordance with Federal, State, and/or Local regulations. Landfills and other non-approved disposal centers shall not beused for equipment disposal.
  • LCD/LED/Plasma will be disposed in accordance with Security Team Policy

Reutilization

All TE that is serviceable and not reached its usefulness will be re-incorporated/re-absorbed in the inventory of TE.
Document 1 – Certificate of Hard Drive Disposition


up arrow

Internet Security Policy

Anti-Virus Guidelines

Defines guidelines for effectively reducing the threat of computer viruses on the organization's network.

Objectives

The principal concern of this computer virus protection policy is effective and efficient prevention of network virus outbreaks and network security attacks involving computers associated with Durham Tech’s NET289 class and the lab in 456.

This policy is intended to ensure:

  1. The integrity, reliability, and good performance of University computing resources;
  2. That the resource-user community operates according to a minimum of safe computing practices;
  3. That the college-licensed virus software is used for its intended purposes; and
  4. That appropriate measures are in place to reasonably assure that this policy is honored.

Policy

Centrally provided virus protection software will be run on Durham Tech computers connected to the NET289 class in room 456.


Goals

Prevent all infections. And when that is not possible, create an outlet for notification and annotation of virus outbreaks for University service providers and end-users so that future breaches can be prevented.

Prevent the loss of information/data and software on University-owned computers and computers in the University community and minimize the cost of computing maintenance and network downtime by virus outbreaks.

  • ll computers that are connected to Durham Tech’ NET289 class located in room 456 of the Newton building must have the standard supported anti-virus software installed and scheduled to run at regular intervals. In addition, the anti-virus software and the virus definition files must be kept up-to-date.
  • All PC's are to be configured such that they schedule regular updates from the Network Services centralized anti-virus servers

End-Users

Computer systems owned by Durham Tech will run anti-virus software, and it should be active at all times. The primary user of a computer system is responsible for keeping the computer system compliant with this virus protection policy.


Responsibilities

Install and maintain current virus protection software

Be certain that the software is running correctly. If these responsibilities appear beyond the end-user's technical skills, the end-user is responsible for seeking assistance from authorized staffing of the Network Technology Department at Durham Tech.

Notify the above staff if a virus infection occurs even if the virus has been successfully disinfected. This information is vital to making others aware of the danger and keeping accurate records of outbreaks.

Perform regular backups. Virus infections often destroy data on an individual's computer.

Without proper backups, recovery of destroyed files may be impossible.

This policy is based upon information received from other University Antivirus software policies, such as Auburn University and The University of Richmond.


up arrow

Server Security Policy

The purpose of this policy is to establish standards for the base configuration of internal server equipment that is owned by Durham Tech. This will minimize unauthorized access to Durham Tech proprietary information and technology

General Guidelines

  • Services and applications that will not be used must be disabled where practical.
  • The most recent security patches must be installed on the system as soon as practical.
  • Servers should be physically located in an access-controlled environment.
  • Servers are specifically prohibited from operating from classroom area.

Monitoring

  • All security-related events on critical or sensitive systems must be logged and audit trails saved .
  • Security-related events will be reported to the instructor, who will review logs and report incidents to IT management. Corrective measures will be prescribed as needed.
  • Security-related events include, but are not limited to:
    • Port-scan attacks
    • Evidence of unauthorized access to privileged accounts
    • Anomalous occurrences that are not related to specific applications on the host.

http://www.sans.org/security-resources/policies/Server_Security_Policy.pdf


Backup Policy

The purpose of this policy is to protect data at Durham Tech to be sure it is not lost and can be recovered in the event of an equipment failure, intentional destruction, or disaster.

  • Full backups are performed everyday at midnight.
  • A designated IT personnel shall perform regular backups and test the ability to restore data from backups on biweekly basis.
  • Data backed up include:
    • VM images and VM hosts
    • System state data
    • The registry
  • Systems to be backed up included but are not limited to:
    • Domain controllers
    • DHCP server
    • FTP server

Physical Security Policy

The composition of the facility is single story brick and mortar. The roof is flat and contains no arch. The exterior is entry point controlled by five (5) double door configuration ingress/egress. The doors are secured at 2200 hrs and open to the public at 0700. The doors are steel construction with a viewing window, and possess an interior serpentine composite metal insulation that acts as an absorbing buffer in the event of forced entry during secured periods. The doors are secured by either traditional key and/or by Radio Frequency Identification (RFID).



up arrow