Desktop computers contain a variety of sensitive and personal information. Several steps should be taken to secure this information. This policy outlines those steps.
This policy is designed to provide the framework for securing Clarkson University owned desktop computers.
This policy impacts any individual who has a device attached to Clarkson’s computer network and who deals with University owned computer data.
Whenever a new desktop computer is setup, the following guidelines shall be followed.
All desktop systems shall be protected by a software firewall to prevent access to services which should not be available to the general public
b. Patch Management
Additionally, all desktop systems shall be protected by being kept up-to-date with the latest patches that are available for the software installed on them. This prevents an attacker from exploiting a known vulnerability.
c. Anti-Virus Software
All desktop systems shall run the University provided anti-virus software. This anti-virus software shall be kept up-to-date with the latest virus definitions (which it should receive from the University’s managed anti-virus server). It is recommended that end users check their virus definitions at least once a week to ensure that their definitions file is no more than seven days old. Additionally, when an OIT technician is servicing a system, the technician will ensure that the antivirus software is upgraded to the most-current supported version.
d. Account Management
To prevent unauthorized remote access, all desktop systems shall utilize strong passwords. These passwords should follow the established best practices for passwords as set forth in the Password Policy. All Windows desktop computers must also have password hashing set to use NTLMv2 hashes to ensure the security of hashed passwords.
e. Network Registration
All devices directly attached to the Clarkson network must be registered using the Clarkson University Network Registration system. If this device provides additional network services, the registered owner is responsible for any impact that these services may have on the network. This registration will assist OIT in tracking malfunctioning machines and quickly contacting their owner.
f. System Rebuild
Any system that is found to be infected must be rebuilt. The use of removal tools to remediate such a problem is unacceptable except in cases where a policy exception is granted by the Director of Network Services. Any system requiring a rebuild under these circumstances must be scanned for Personally Identifiable Information (PII) using an approved tool before any further work is performed on the system. Additionally, notification of the discovery of any such systems must be made to the Security Engineer and the Director of Network Services immediately upon discovery.
g. Additional Measures
Additional security measures may be required. All written and approved recommendations presented by the Desktop Security Team and/or the Security Engineer must be followed.
Failure to follow this policy will result in the offender(s) being subject to disciplinary action up to and including dismissal.
A system is defined to be infected when:
- The system is found to have known, malicious executable code present on the system; or
- External data shows that the computer in question is attacking other computers or otherwise abusing the network; or
- The system is found to have been modified by an unauthorized party; or
- A member of the security team indicates that the system is infected.
An unauthorized party is defined as an individual who is not:
- The end user; or
- The local technical support staff; or
- A staff member of the Office of Information Technology
A network device is defined as any device attaching to the network (ie. PC, game console, server, etc.).
7.0 Revision History
Draft Policy v0.1 – 21 April 2005 – jfiske
Draft Policy v0.2 – 05 July 2005 – jfiske
Draft Policy v0.3 – 06 January 2006 – jfiske
Draft Policy v0.3 – 06 January 2006 – jfiske, bhuntley, klynch
Draft Policy v0.4 – 23 March 2009 – jfiske
Draft Policy v0.5 – 28 April 2009 – jfiske
Approved Policy v1.0 – 4 November 2013 – jfiske