3 Maintaining the Security of Devices

You should know the following terms:

• Anti-malware software
• Anti-virus software
• Audit logs
• Backups (Backup strategy)
• BYOD (Bring Your Own Device)
• Detailed logging
• DHCP messages
• Firewall
• Firewall logs
• Hardening
• Incident Response Plan
• Internet of Things (IoT)
• Log server
• Logs
• Network vulnerability scanner
• Patch-management process
• System logs
• Workstation logs

Default Configurations

A common task for entry-level technicians is the deployment and maintenance of devices in the inventory. Hopefully, the imaging and reimaging of devices used by staff and students is automated, including configurations that “harden” the devices against cyberattacks. Hardening refers to reducing a device's vulnerability to attack. This often entails changing any default passwords on the device, installing only necessary and approved software and uninstalling unnecessary software, and disabling or removing unnecessary services. New devices may need to run updates to ensure they are using the most up-to-date operating system before being deployed. Hardening practices also often include enabling auto-updates for the operating system, the configuration of firewalls and activating security software, such as Windows Defender in supported devices. Know the hardening practices your district applies.

Updates

Many IT providers release periodic updates to their software. These updates often include security updates, or patches, that mitigate vulnerabilities in previous versions of software that become known over time. Every district should have a patch-management process for operating systems and district-approved applications so the devices on your network that run them are at a reduced risk of attack.

Four steps to consider for your patch-management process include:

1. Review current systems for any known vulnerabilities that may not be patched within your district. You can find  this information from vendors as well as online security-focused websites.
2. Determine who is responsible for monitoring the need for new patches as they become available. New patches should be tested in a sandbox environment before widely deployed across your district.
3. Determine reasonable maintenance windows when systems can be taken offline to apply updates.
4. Use a reliable network vulnerability scanner to monitor your network and assure all patches are in place and operating correctly. A scan of the network can detect any additional issues you may need to review.

Know your obligations for which of these steps, if any, you are responsible for in your position. You may want to determine if you should sign up for updates about new vulnerabilities from the Cybersecurity & Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) Catalog. CISA also offers a free Vulnerability Scanning Service. Contact CISA at vulnerability@cisa.dhs.gov to determine if your district is eligible. 

CISA reports that some third-party services automatically identify the presence of vulnerabilities from the KEV catalog. If your district utilizes one of the following services, you should know your responsibility for monitoring or maintaining them. According to CISA, third-party services that leverage the KEV Catalog include but are not limited to Palo Alto Networks Cortex, Tenable Nessus, Runecast, Qualys VMDR, Wiz, Rapid7 InsightVM, and Rapid7 Nexpose. 

Protecting Systems

Defending against cyberattacks requires a multi-pronged approach from your network at large down to each device that connects to it. Each device on your network should have up-to-date anti-virus and anti-malware software installed, software like Windows Defender on Windows OS devices. Your IT Department can ensure this occurs on all district-owned devices, and should recommend that visitors who use your network do the same as a condition of acceptable use of your network resources. Staff who wish to use personal devices may benefit from guidance, like an FAQ page or simple tutorials on your website, for how to prepare their personal devices before connecting to your network, which would most likely be a guest network. 

Anti-malware software should have updated definition files to defend against most current malware attacks. This software should also be configured to scan any removable devices, such as thumb drives or USB hard drives that might contain malicious software with or without the owner’s knowledge.

A critical strategy for maintaining your network and the data it contains is to perform and test backups. Your district should use a comprehensive backup strategy to ensure that all critical files are backed up on a regular basis, such as once a week. Backups may occur more frequently for the most critical files. Some districts may utilize free tools such as Windows Auto-Backup and Google Backup & Sync, but these should be followed up by tests to make sure you can truly restore all of your data from those backups. 

In addition to databases and user files, your backup should include configuration files for all of your devices, including network hardware such as switches, routers, and firewalls. Backup files should use encryption, as poorly protected back-up files are a target for some cyber attackers. A common back-up strategy is 3-2-1 in which three copies of backup data are stored on two different types of storage media with one copy kept off-site (Larson, D. K-12 CIS Security Framework, p. 24). You should understand your role in supporting network backups and how they are used when necessary.

Know the backup procedures in your district and what type of information is actually backed up. You may need to know where backups are located, especially if using a strategy that involves multiple backups. Do backups include data on mobile devices and data on cloud-based storage? Also know your district’s SOP for requesting restoring data from a backup.

Monitoring Systems

Logs are records of events on your network. Generally, there are two types of logs that are configured and reviewed independently: 1) system logs, and 2) audit logs. System logs report data on system-level events such as start/end times on system processes and crashes. Audit logs include user-level events, such as when a user connects to and logs into your network, accesses a network resource or a file. Logs should also capture when a user attempts to access a resource without sufficient access. Appropriately configured logs can be especially helpful in the event of a cyberattack as they can indicate when and how the attack occurred, information that was accessed, and any data that was removed. Logs may also be required in the case of any subsequent investigation after an attack.

Every IT Department should maintain a proper logging and audit system to monitor their infrastructure and troubleshoot issues that may arise. Detailed logging should be enabled on all servers, systems, and applications in your district in order to collect information such as timestamps, addresses, usernames, and event types. This type of logging can be enabled on firewalls, proxies, and Virtual Private Networks (VPN). This can require a lot of storage over time, so many districts will maintain a centralized log server to collect and maintain historical data. The centralized server also makes it easier to audit logs without having to pull data from multiple sources, but should be installed outside of your main environment in case you need to access it when the main environment goes down.

Your district should be collecting logs of:

• DHCP messages to determine who is trying to access your network
• Firewall logs to track visitors and any malicious attacks
• Workstation logs to track how devices are being used

Logging is likely set up by a senior technician, but all technicians should know where the log files are and how to access them, when necessary. You may also be asked to periodically review logs and verify the accuracy of the data they contain.

The logging server should notify appropriate IT staff when a high-priority security threat occurs. This notice may occur through email or text and may include events such as unexpected use of the system off routine hours or the creation or use of an Administrator account when not expected. Despite the ability to notify staff of suspicious events, IT staff should be designated to review log reports on a regular basis to determine if any suspicious events have occurred.

Inactive accounts can be used by cyber criminals to impersonate staff with legitimate accounts. Your district should have in place the policies and a system to periodically audit and remove inactive accounts. Inactive accounts may have been assigned to staff or students. Staff in the departments that monitor current employment and enrollment, such as Human Resources, and Admissions or another department for students should understand SOP for on- and offboarding people who require an account to access school resources. In most cases, creating and disabling accounts is automated, but it’s still a good idea to audit your accounts periodically.

Network Policies

Your network team will implement safeguards to help protect the network and the devices on it. Standard on most networks is a firewall located between your network and the Internet at large, which may be your Internet Service Provider’s (ISP) connection. Individual devices provided by the district also likely have firewalls installed along with antivirus and antimalware software. Only devices that meet the security configurations for your network should be on it. 

Does your district have a BYOD policy? BYOD stands for “bring your own device,” and while a popular strategy at one time to help get more devices into the hands of students and others who needed them at school, they can pose a threat to the security of your network. BYOD devices, when allowed, are usually only allowed to connect to a guest network, which has stricter security and filtering controls and limited access. You should know whether staff and students can use their own personal device on campus. If so, how should they connect to your network?

There is a growing range of Internet of Things (IoT) devices that are making their way into schools. Some can be helpful like security cameras or kitchen appliances that can be monitored by maintenance or food services staff. Others can pose security threats, such as smart speakers that can search the Internet simply by having someone talk to it. You should understand your district’s policies for IoT devices. Are they allowed? If so, how should they connect to your network? If not allowed, what is the appropriate response if you find one in use?

Dealing with a Compromised Device

You should know your district’s SOP to follow when being tasked on working with a compromised device. If you come across a compromised device through an interaction with a staff member or student, you may ask them to disconnect the device from the network but not power down the device. Disconnecting the device, which can be as easy as turning off the WiFI (sometimes a button or switch), can prevent spreading of malware to other devices on the network and stop any flow of information. Shutting down the device might eliminate evidence necessary to further troubleshoot the issue.

Know the steps to follow with a compromised device. Should the hard drive be erased? Should the device be reimaged? Where has any backup data for the device been stored and how do you access it?

Incident Response Plan

Every school district should have an Incident Response Plan that details the roles staff in different departments have in terms of protecting, detecting, responding to, and recovering from cybersecurity incidents. CIS notes in its description of Critical Security Control 17, Incident Response Management, many organizations often overlook response and recovery capabilities and may employ the insufficient strategy of re-imaging assets to their original state and moving on. Without a comprehensive plan that is able to identify threats, respond to them quickly, determine how they occurred, and what can be done to prevent them from happening again, cyberattackers may simply attack the system over and over again.  In most organizations, the Incident Response Plan is developed with input and coordination from multiple departments, such as Human Relations, Public Relations, District and/or Building Administrators and legal advisors or staff.

An Incident Response Plan may include:

• How staff are to report known or potential cybersecurity risks;
• Descriptions of differences in incident severity levels, from minor isolated incidents with low impact to critical incidents that can involve loss of data or widespread capacity impacting multiple users; and
• The roles different staff and perhaps some contracts play during an incident.

Entry-level technicians should understand their role during incidents, and how that role might be impacted by the severity of the incident. You are on the frontline for helping to recognize potential cybersecurity risks. You may be able to identify the presence of unsupported programs, unusual scheduled tasks, or suspicious emails. Your Incident Response Plan will dictate how you report these or other cybersecurity risks. Once reported, determine the actions you are responsible for in different types of cybersecurity risks. Reporting may be your last step if the incident management moves to another team, like networking. In other districts, multiple IT staff and departments may have their unique roles to perform in an incident.

An important consideration after an incident occurs is to understand what you should or should not say about it--to anyone. In mission critical incidents, statements about the incident are often carefully crafted by Public Relations staff in conjunction with leaders from IT and District Administration. In many cases, you should avoid sharing details of the incident with anyone, except during approved exchanges with others identified in the Incident Response Plan as you are following expectations for your positions.
 

Here are additional resources you may find useful:

• National Incident Management System (NIMS). FEMA. Contains access to training, tools, and the option to subscribe to email alerts.
• Example Incident Response Plan on Michigan.gov

Complete the following task or self-assessment:

Learn your district’s hardening requirements and patch-management process.  Additionally:

• Review the four steps for patch management and determine your role in those steps as well as others who may be involved throughout the process.
• Ask to determine if you should sign up for updates for new vulnerabilities from CISA or other organizations, including your trusted vendors.
• If appropriate, review your district's data backup procedures.
• It may also benefit you to learn to read and review log reports stored on a log server. Know the logs your district keeps and what the data tells you.

Find, review, and thoroughly understand your district's Incident Response Plan:

• What are your obligations in terms of protecting, detecting, responding to, and recovering from cybersecurity incidents? If you are unsure about anything, ask!

A common cybersecurity saying is “it’s not if there will be an attack, it’s when there will be an attack.” When that happens, know what to do to be an asset to your team and the district at large.