Difference between revisions of "Policies: ECE"

From WolfTech
Jump to navigation Jump to search
m
m
 
(3 intermediate revisions by the same user not shown)
Line 51: Line 51:
  
 
==Three Year Warranty==
 
==Three Year Warranty==
==Personal Computers==
 
'''''CLEAN'''''
 
Personal Computers getting Permanent IPs
 
  
Here's the immediate issue. IPs are controlled by individual departments or colleges. *THESE UNITS* are responsible for the network and require that all IPs be assigned BY THESE groups. So having a "central" entity, aka ITD/ComTech, do this would NOT be good. On many levels. I can go into detail later if you like, but save us all time, and make sure that you're working with individual colleges, not central IT, when requesting IPs.
 
  
One example -- I will remove ANY IP in ECE IP ranges that are not in our records. This is something you'd want to avoid.  
+
==Windows Patching Policy==
 +
The Department of Electrical and Computer Engineering uses Windows System Update Services (WSUS) to keep all Windows computers up to date with the latest security patches, updates, and drivers. This system is an integral part of maintaining both the security and availability of our network. The purpose of this policy is to optimize WSUS to meet our organizational requirements for security, stability, and user impact.
  
This is NOT a centralized problem, or one in which a centralized solution is likely to work. Should the committee like some contacts within each department/college, I can provide this.  
+
*Security
 +
** Microsoft releases new software updates on the 2nd Tuesday of each month.
 +
** When exploitation of a vulnerability is already occurring, or is imminent, Microsoft will release and update immediately.
 +
** As an academic environment, our network is relatively exposed to threats, both from off campus and from computers brought onto our network.
  
Having said that, some departments and colleges already *do* register personal machines. ECE is one of those.  
+
*Stability
 +
** Microsoft Updates have the potential cause unwanted side effects and should be tested before deployment.
  
The current version of our online request form is here:
+
*User Impact
https://www.wolftech.ncsu.edu/requests/register/
+
** Many Windows Updates require the computer to be rebooted before the update takes effect.
 +
** Some updates do not require a reboot and can be installed with minimal impact on the user.
 +
** If a user is logged into the computer, Windows Update will prompt the user to reboot.  If the user does not respond within a configurable period of time, the computer will reboot.
 +
** If a user cancels the reboot, they will be re-notified to reboot after a configurable period of time.
 +
** Many users leave jobs running on their computers overnight. Because the user is not present to prevent the reboot, the computer reboots, killing any running jobs.
  
You can get an idea of the information we require on our form there.
 
  
Sample of the rules we follow:
+
===Desktop and Laptop Clients===
 +
# When monthly updates are released, an email notification will be sent to all ECE faculty, staff, and students. When emergency updates are released, email notifications will be sent to all ECE faculty, staff, and students and the installation schedule will be set based on the circumstances.
 +
# Updates will be installed on IT staff computers to allow for rudimentary testing.
 +
# If no problems are found with the updates, they will be approved for installation 48 hours after the email notification is sent.
 +
# Updates that do not require a reboot will be installed immediately upon approval and detection. Updates requiring a reboot will be installed according to the following schedule.
 +
#* Teaching Lab Computers: 11:00 PM<BR>After hours, to avoid interrupting a class in session.
 +
#* Research Computers: 3:00 PM<BR>During working hours, to avoid "surprise" reboots.
 +
#* Faculty Computers: 4:00 PM<BR>During working hours, to avoid "surprise" reboots.
 +
#* Staff Computers: 8:00 PM<BR>After hours, to avoid disturbing staff.
  
#The registered name of the machine is USERID.ece.ncsu.edu. Students do not have the option to change this. FT Faculty can, if strongly desired. This naming convention allows identification of the owner quite easily, as well as distinguishing it as a personal machine on sight. We do, of course, maintain a comprehensive database of all of our IPs/computers, but this helps as well. Also removes some maintenance/labor costs in setting up the IP access.
 
#One registered machine per student. We will occasionally make exceptions for special cases (in which case, the name of the machine is USERID2). This is a very rare event.
 
#Symantec AntiVirus is required, but this is a general NCSU IT rule already in place. NCSU users are directed to http://www.ncsu.edu/antivirus/. Additional network usage policies are set by NCSU, the colleges, and departments. For example, you are not allowed to run servers from these machines. Should the computer show up (*blip*) on our network monitors, we will come ask what the user is up to.
 
#OS Updates: All personal machines operating on the ECE network must be configured to automatically install Windows patches from our WSUS server.  For more information and instructions on how to configured your computer to use WSUS, see [[Active_Directory/Documentation/WSUS | WSUS]].
 
#You must have an NCSU UnityID to have a permanently registered IP. All faculty, staff, students, postdocs, and, usually, visiting scholars (see NoPay notes below), have a UnityID.
 
#All personally owned machines are removed from the network once the userid of the owner has been disabled by the University. We have scripts that report these machines to us on a weekly basis. If we know someone has left, we'll remove it ahead of this time.
 
  
==WSUS Update Policy==
+
* Any user wishing to avoid an automatic reboot must manually download and install the updates and reboot before the scheduled installation.  For instructions, click [[Active_Directory/Documentation/Manually Install Updates| here]].
[[Active_Directory/Documentation/Update_Policy| Update Policy]]
+
* The reboot timer is set to 30 minutes.  If the user fails to cancel the reboot within 30 minutes, the computer will automatically reboot.
 +
* The notification interval is set to 30 minutes.  If the user cancels the reboot, they will be re-prompted to reboot after 30 minutes.
 +
 
 +
===Personal Computers===
 +
* All ECE faculty, staff, and students will be notified when new updates are released.
 +
* Users will be advised to install the Microsoft Updates on their personal and home computers.
 +
* All personal computers that have been issued an IP address on the NCSU network are required to be configured to receive updates from ECE's WSUS server.  For instructions on how to configure your computer to use WSUS, click [[Active_Directory/Documentation/WSUS#How_to_Manually_Configure_Your_Personal_Computer| here]].
 +
 
 +
===Exceptions===
 +
* The only exception to this policy is for computers that do not have a network connection.

Latest revision as of 17:19, 2 March 2017

Computers Stay On

Dual Boot

REWRITE for GENERAL USE -- add in info about


Security

Remote Access Servers

VCL/GRENDELs

On the NCSU network, an unpatched Windows workstation is hacked within 30 seconds. Often, less time is required. Keeping the OSes patched is our number one way to prevent one machine from attacking the rest.

Dual booted machines are the blight of security within this environment.

With the OS switching back and forth, neither OS (we're patching Linux across the network as well) is kept up to date. And we can't know how long a machine has stayed on one OS versus the other.

Therefore, the goal has been to discourage, and eventually remove the use of dual booted systems *wherever possible*.

What I need to know is the reasons/needs for the dual boot. I'll give you one: OPNET currently requires Windows -- assuming your primary use of the machine is as a Linux box, then this would be a good reason to have both the OSes. Granted, once OPNET *is* available on Linux, this would no longer be a legitimate reason.

While you know our goal is to move to a non-dual boot environment, *I* need to know the obstacles that *you* see to this. What applications prevent your use of a single OS? Having this information helps to better define this policy.

We wouldn't want to have Windows on a box simply because a student likes to use Outlook to check his mail, or because they prefer Office over StarOffice.

I would ask that you work with us on this. We have no research support funding. Trust me, if we could, we would -- so we have a limited staff to respond to issues that arise. We do so because I recognize the needs of the department, and because I'd like to avoid the "wild west" of computing that ECE was four years ago. Our goals are to meet your legitimate needs, but we must weigh that against the cost of support and to the rest of the network.

  • We will dual boot this machine*.

You are correct that a 600Mhz machine will not meet your needs. Outside of the Networking group, one of the major reasons we have dual boot requests is because a student wants to "play" with the buzz work "Linux". A secondary machine on which to do this often does meet their needs, and is therefore a standard response to such requests. I will have our people adjust this response to elicit legitimate reasons for the request and possible exceptions, as in this case, to the policy.

We *WILL* be erecting the firewalls on both the Linux and Windows OSes.

This should help, partially, to protect the machines while updates are installed. Unfortunately, not all issues are due to outside attacks, but it's something. This should not affect the use of the machine, but if it does, let us know, and we'll see what specific exceptions to this firewall can be made.

While the machine is being built, please send me the reasons a dual boot is important to you in this case. If we can determine what the problems are with a single OS, we can attempt to resolve them, or at least keep them in mind.

File Sharing Applications

The Digital Millennium Copyright Act amends federal copyright laws, providing liability protections to providers of online services when their networks contain material infringing upon copyrights.

WolfTech actively searches for software piracy upon the network. Here's information on piracy, our policies, and the process should you be caught with illegal software.

Software piracy is something that we have been hearing a lot these days. While it has been around since the time Bill Gates dropped out of Harvard, it has just recently become big news. Today, with high speed Internet connections rampant, peer-to-peer, p2p, file sharing applications have begun springing up all over the place. These handy applications allow people to share music, videos, other applications, and anything lese electronic.

So whats the big deal? Not everybody sees this as sharing. When you download something for free via p2p applications, you are technically stealing from the original author. Programs sold for hundreds, even thousands, of dollars are being swapped from computer to computer via the Internet. Each time someone copies a file or program from another user, they are costing that company the cost of the product.

There are other ways of distributing pirated software, such as selling burned CDs, but it is all legally punishable. If convicted, a software pirate can spend up to five years in prison or be fined up to $250,000. Plus, litigation can continue into civil court where damages may rack up even more. In addition to the financial burden, if you work for a company, you have single handedly tarnished their entire reputation.

Running the program in itself is not even illegal under current US Copyright Law. However, what you get off of the program may be illegal. The act of sharing the file or program, under many licensing schemes, is illegal. If you are caught using the programs for illegal activities, it is the responsibility of NC State to report you to the proper authorities, and your network account may be deactivated.


Three Year Warranty

Windows Patching Policy

The Department of Electrical and Computer Engineering uses Windows System Update Services (WSUS) to keep all Windows computers up to date with the latest security patches, updates, and drivers. This system is an integral part of maintaining both the security and availability of our network. The purpose of this policy is to optimize WSUS to meet our organizational requirements for security, stability, and user impact.

  • Security
    • Microsoft releases new software updates on the 2nd Tuesday of each month.
    • When exploitation of a vulnerability is already occurring, or is imminent, Microsoft will release and update immediately.
    • As an academic environment, our network is relatively exposed to threats, both from off campus and from computers brought onto our network.
  • Stability
    • Microsoft Updates have the potential cause unwanted side effects and should be tested before deployment.
  • User Impact
    • Many Windows Updates require the computer to be rebooted before the update takes effect.
    • Some updates do not require a reboot and can be installed with minimal impact on the user.
    • If a user is logged into the computer, Windows Update will prompt the user to reboot. If the user does not respond within a configurable period of time, the computer will reboot.
    • If a user cancels the reboot, they will be re-notified to reboot after a configurable period of time.
    • Many users leave jobs running on their computers overnight. Because the user is not present to prevent the reboot, the computer reboots, killing any running jobs.


Desktop and Laptop Clients

  1. When monthly updates are released, an email notification will be sent to all ECE faculty, staff, and students. When emergency updates are released, email notifications will be sent to all ECE faculty, staff, and students and the installation schedule will be set based on the circumstances.
  2. Updates will be installed on IT staff computers to allow for rudimentary testing.
  3. If no problems are found with the updates, they will be approved for installation 48 hours after the email notification is sent.
  4. Updates that do not require a reboot will be installed immediately upon approval and detection. Updates requiring a reboot will be installed according to the following schedule.
    • Teaching Lab Computers: 11:00 PM
      After hours, to avoid interrupting a class in session.
    • Research Computers: 3:00 PM
      During working hours, to avoid "surprise" reboots.
    • Faculty Computers: 4:00 PM
      During working hours, to avoid "surprise" reboots.
    • Staff Computers: 8:00 PM
      After hours, to avoid disturbing staff.


  • Any user wishing to avoid an automatic reboot must manually download and install the updates and reboot before the scheduled installation. For instructions, click here.
  • The reboot timer is set to 30 minutes. If the user fails to cancel the reboot within 30 minutes, the computer will automatically reboot.
  • The notification interval is set to 30 minutes. If the user cancels the reboot, they will be re-prompted to reboot after 30 minutes.

Personal Computers

  • All ECE faculty, staff, and students will be notified when new updates are released.
  • Users will be advised to install the Microsoft Updates on their personal and home computers.
  • All personal computers that have been issued an IP address on the NCSU network are required to be configured to receive updates from ECE's WSUS server. For instructions on how to configure your computer to use WSUS, click here.

Exceptions

  • The only exception to this policy is for computers that do not have a network connection.