Grasslands Public Schools Policy Handbook Grasslands Public Schools
Home
Administrative Procedure

AP-326 — Technical Security Controls

Section Three: General School Administration
Effective Date: August 25, 2026 Last Reviewed: August 25, 2026

Background

Protecting the Division's information assets requires a layered set of technical controls that secure endpoints, detect vulnerabilities, monitor for threats, encrypt data, defend network boundaries, and maintain secure configurations. These controls complement the access controls established in A.P. 320 – Information Access Control and the data classification requirements in A.P. 313 – Data Classification. Where A.P. 313 defines what level of protection data requires and A.P. 320 defines who may access it, this procedure defines how the Division's technical environment enforces those requirements.

This procedure implements the technical security expectations established in Policy 310 – Information Security Charter and aligns with NIST Cybersecurity Framework 2.0 functions PR.DS (Data Security), PR.PS (Platform Security), DE.CM (Continuous Monitoring), and DE.AE (Adverse Event Analysis).

Control requirements throughout this procedure scale by system classification (Core, Common, Innovative) as defined in A.P. 312 – Technology Acquisition and Use. A summary matrix of all classification-scaled requirements appears in Section 8.

Scope

This procedure applies to all Division-owned, Division-managed, and Division-contracted information systems, network infrastructure, endpoints, and cloud services. It covers:

This procedure does not establish access control requirements (A.P. 320), data classification levels (A.P. 313), or incident response procedures (A.P. 321). It references those procedures where technical controls intersect with their scope.

Definitions

Terms not defined in this procedure have the meanings assigned in Policy 310 – Information Security Charter and A.P. 313 – Data Classification.

Configuration baseline: A documented, approved set of security settings for a system type or platform that serves as the standard against which deployed systems are measured.

CSPRNG: Cryptographically Secure Pseudo-Random Number Generator, a random number generator suitable for use in cryptographic key generation.

EDR: Endpoint Detection and Response, a security solution that continuously monitors endpoint devices for indicators of compromise and provides automated and manual response capabilities.

Encryption at rest: Cryptographic protection applied to data stored on disk, in databases, or in cloud storage, so that the data is unreadable without the appropriate decryption key.

Encryption in transit: Cryptographic protection applied to data as it moves between systems, devices, or networks, typically using TLS, IPsec, or similar protocols.

HSTS: HTTP Strict Transport Security, a web security policy mechanism that forces browsers to interact with a website only over HTTPS.

Indicator of compromise (IoC): An artifact observed on a network or system that, with high confidence, indicates a computer intrusion or malicious activity.

Key escrow: The practice of storing a copy of an encryption key with an authorized third party or system so that the data can be recovered if the original key holder is unavailable.

Patch: A software update released by a vendor to fix vulnerabilities, correct bugs, or improve functionality.

Vulnerability: A weakness in a system, application, or configuration that could be exploited by a threat source. (See also A.P. 328 – Risk Management Framework.)

Zero-day vulnerability: A vulnerability that is actively exploited before the vendor has released a patch or the vulnerability is publicly known.

Responsibilities

Superintendent

Access and Privacy Coordinator

Director of Technology

Technology Department Staff

System Owners (as defined in A.P. 312)

Procedures

1. Endpoint security and hardening

  1. All Division-managed endpoints shall be deployed from an approved configuration baseline maintained by the Technology Department. Configuration baselines shall be reviewed annually and updated when vendor guidance, threat intelligence, or audit findings warrant changes.
  2. Endpoint Detection and Response (EDR) shall be deployed on all Division-managed workstations, laptops, and servers. EDR agents shall be configured for continuous monitoring, automated threat detection, and centralized alerting to the Technology Department.
  3. Endpoints shall be configured to enforce the following minimum security settings:
    1. Local firewall enabled and configured to default-deny for inbound connections.
    2. Automatic screen lock after 15 minutes of inactivity.
    3. USB mass storage restricted to authorized, encrypted devices per A.P. 313 removable media requirements.
    4. Administrative privileges restricted to Technology Department staff; standard users shall not have local administrator rights.
    5. Automatic operating system and application updates enabled where technically feasible.
    6. Local administrator account passwords managed by an automated rotation solution, such as Windows LAPS (Local Administrator Password Solution), so that each Division-managed endpoint is assigned a unique local administrator password that is rotated automatically on a defined schedule and stored securely, with retrieval restricted to authorized Technology Department staff.
  4. Except for staff mobile phones, mobile devices (tablets, smartphones) used to access Division systems shall be enrolled in the Division's mobile device management (MDM) platform. MDM policies shall enforce device encryption, screen lock, remote wipe capability, and application restrictions.
  5. Remote devices connecting to Division systems from outside Division networks shall connect through the Division's VPN or through a vendor-provided secure access method approved under A.P. 322. Split tunnelling is prohibited for connections to Core and Common systems.
  6. Endpoints that cannot meet the approved configuration baseline (including legacy systems, specialized instructional devices, or vendor-managed appliances) shall be documented in the risk register under A.P. 328 with a compensating control justification per A.P. 328.

2. Vulnerability and patch management

  1. The Technology Department shall maintain a vulnerability management program that includes regular scanning, risk-based prioritization, and timely remediation.
  2. Vulnerability scanning shall be conducted at the following minimum cadence, based on system classification as described in A.P. 312:
    1. Core systems: Monthly.
    2. Common systems: Quarterly.
    3. Innovative systems: On deployment and upon material change.
  3. Scan results shall be triaged using the Common Vulnerability Scoring System (CVSS) as a baseline, adjusted for the Division's operating context and the system's classification under A.P. 312. Detailed triage and remediation procedures are defined in IM-013 – Vulnerability and Patch Management.
  4. Patches shall be applied within the following timelines after vendor release, based on the system classification and the vulnerability severity:
Severity Core Common Innovative
Critical (CVSS 9.0–10.0) 7 calendar days 14 calendar days 30 calendar days
High (CVSS 7.0–8.9) 14 calendar days 30 calendar days 60 calendar days
Medium (CVSS 4.0–6.9) 30 calendar days 60 calendar days 90 calendar days
Low (CVSS 0.1–3.9) Next maintenance window Next maintenance window Next maintenance window
  1. Where a patch cannot be applied within the required timeline due to compatibility, vendor delay, or operational constraints, a compensating control shall be implemented and documented per A.P. 328. The compensating control shall remain in place until the patch is applied.
  2. Zero-day vulnerabilities or vulnerabilities with confirmed active exploitation shall trigger the emergency patching process regardless of the regular patching schedule. Emergency patching procedures are defined in IM-013.
  3. Systems running software that is no longer supported by the vendor (end-of-life) shall be documented in the risk register under A.P. 328 with a remediation or replacement plan. End-of-life systems shall not be connected to networks containing Core systems without a documented compensating control approved by the Director of Technology.
  4. The Division shall maintain a process for receiving and responding to vulnerability disclosures as defined in A.P. 328. Vulnerability disclosure response procedures are operationalized in IM-013.

3. Logging, monitoring, and audit

  1. The Division shall maintain a centralized logging for servers, switches, and routers, and employ a monitoring capability that captures security-relevant events across all system classifications. This section extends the access logging requirements established in A.P. 320 to all security events. Detailed logging standards, review procedures, and escalation criteria are defined in IM-014 – Logging and Monitoring Standards.
  2. The following event types shall be logged for Windows endpoints, in addition to the access and authentication events required under A.P. 320:
    1. Security events: malware detections, EDR alerts, firewall blocks, intrusion detection alerts, DLP policy triggers, vulnerability scan results.
    2. System events: service starts and stops, system reboots, hardware failures, backup successes and failures, certificate expirations.
    3. Change events: configuration changes, software installations, Group Policy modifications, firewall rule changes, account privilege escalations.
  3. Log entries shall include, at minimum: timestamp, source system identifier, event type, associated user identity (where applicable), source IP address, and event outcome (success or failure).
  4. Logs should be retained for the following minimum periods based on the system classification, where vendor or platform capabilities permit. Where vendor logging retention defaults are shorter, the Technology Department shall document the gap and consider whether log forwarding or extended retention licensing is appropriate.
Classification Minimum retention
Core 1 year
Common 180 days
Innovative 90 days
  1. Logs shall be protected from unauthorized access, modification, and deletion. Write access to log repositories shall be restricted to service accounts; no individual non-administrative user shall have the ability to modify or delete log entries.
  2. The Technology Department shall implement automated alerting for high-priority events, including: multiple failed authentication attempts exceeding defined thresholds, after-hours administrative access to Core systems, EDR alerts indicating potential compromise, and pattern matches against known indicators of compromise.
  3. Log review shall be conducted at the following minimum cadence:
    1. Automated alerting: Shall be used whenever practicable.
    2. EDR Events: Shall send out automated alerts to all technology staff.
    3. Administrative access logs for Core systems: Shall be actively monitored 24/7.
    4. Firewall and network logs: Shall be actively monitored 24/7.
  4. Anomalies or suspected security events identified through logging and monitoring shall be escalated per A.P. 321 – Information Security Incident Response. Escalation criteria and timelines are defined in IM-014.
  5. In support of the proactive privacy monitoring requirements under A.P. 320 and PPMR s.6(2)(a)(iii), the Technology Department shall:
    1. Verify that logging is active and functioning on all systems containing personal information.
    2. Monitor access patterns for anomalies that may indicate unauthorized access to personal information.
    3. Monitor Microsoft and Google sensitivity label application and DLP policy events.
    4. Provide logging and monitoring data to the periodic privacy risk assessment conducted under A.P. 320.

4. Encryption and cryptographic controls

  1. The Division shall use encryption to protect information classified as Restricted or Confidential under A.P. 313, both at rest and in transit. Encryption requirements by classification are defined in A.P. 313; this section establishes the approved algorithms, implementation standards, and key management governance. Detailed encryption implementation and key management procedures are defined in IM-015 – Encryption and Key Management.
  2. The following cryptographic algorithms and protocols are approved for Division use:
Function Approved standard Minimum strength
Symmetric encryption AES 256-bit (128-bit acceptable for Internal data)
Asymmetric encryption RSA 2048-bit
Hashing SHA-2 family SHA-256
Transport layer security TLS 1.2 (TLS 1.3 preferred)
  1. The following algorithms and protocols are prohibited: DES, 3DES, RC4, MD5, SHA-1 (for security purposes), TLS 1.0, TLS 1.1, and SSL (all versions).
  2. Encryption at rest shall be implemented as follows:
    1. All Division-managed laptops and workstations shall use full-disk encryption with hardware-backed key storage (TPM or equivalent) and key escrow to a managed key storage system. Approved encryption platforms and key escrow procedures are defined in IM-015 – Encryption and Key Management.
    2. Servers storing Restricted or Confidential data shall use server-side encryption appropriate to the platform.
    3. Cloud services storing Division data shall be verified for encryption at rest as part of the vendor assessment under A.P. 322. Where vendor-managed encryption is used, the Technology Department shall verify the algorithm and key management practices meet Division standards.
  3. Encryption in transit shall be implemented as follows:
    1. All Division web services and applications shall use HTTPS with TLS 1.2 or higher. HSTS shall be enabled on all Division-hosted web services.
    2. Email transmission shall use opportunistic TLS. For Restricted or Confidential information, an approved data-classification-aware encryption platform shall be applied per IM-015.
    3. File transfers shall use SFTP or SCP; unencrypted FTP is prohibited.
    4. VPN connections shall use IPsec or TLS-based tunnelling with approved algorithms.
  4. Cryptographic keys shall be managed through a defined lifecycle including generation, storage, rotation, revocation, and destruction. Key management governance requirements are defined in IM-015.
  5. The Director of Technology shall maintain a certificate inventory covering all Division-managed TLS certificates, code signing certificates, and any other digital certificates. Certificates shall be monitored for expiration with automated alerts at 30 days prior to expiry. Certificate management procedures are defined in IM-015.

5. Network security

  1. The Division's network perimeter shall be protected by firewalls configured to a default-deny posture: all traffic is blocked unless explicitly permitted by an approved rule.
  2. Firewall rules shall be reviewed at minimum annually by the Director of Technology. Rules that are no longer required shall be removed. Each rule shall have a documented business justification.
  3. The Division network shall be segmented to separate, at minimum, administrative, instructional, guest, and infrastructure traffic. Specific zone definitions, VLAN assignments, and inter-zone access policies are documented in IM-017 – Network and System Documentation.
  4. Inter-zone traffic shall be controlled by firewall rules or access control lists. Instructional and guest network segments shall not have access to administrative or infrastructure network segments.
  5. Wireless networks shall use WPA3 where supported by hardware, or WPA2-Enterprise as the minimum standard. Open (unencrypted) wireless networks are prohibited. Guest wireless networks shall be isolated from administrative and infrastructure resources by default. Where guest access to specific internal services is operationally necessary, those services shall be added to a documented permitted-services list maintained by the Technology Department and reviewed at minimum annually. The permitted-services list is documented in IM-017 – Network and System Documentation.
  6. Remote access to Division systems shall require VPN or an approved secure access method. Remote access connections shall enforce multi-factor authentication per A.P. 320.
  7. The Technology Department shall monitor network traffic 24/7 for anomalies, including unusual data transfers, connections to known malicious destinations, and unauthorized devices on Division networks.

6. Secure configuration management

  1. The Technology Department shall maintain documented configuration baselines for each major platform and system type deployed in the Division. Configuration baselines shall be based on vendor security guidance, CIS Benchmarks, or equivalent industry standards where available.
  2. Configuration baselines are required for:
    1. Core systems: Detailed baselines with all security-relevant settings documented.
    2. Common systems: Baselines covering critical security settings (authentication, encryption, logging).
    3. Innovative systems: Vendor default security settings are acceptable unless the system processes Restricted or Confidential data.
  3. All changes to production systems shall follow the Division's change management process. Changes to security-relevant configurations on Core systems require approval from the Director of Technology prior to implementation.
  4. The Technology Department shall monitor for configuration drift (unauthorized or unintended changes to security settings) on Core systems. Drift detection shall be performed at minimum quarterly, and any deviations from the approved baseline shall be investigated and remediated.
  5. Configuration baselines shall be reviewed annually and updated to reflect changes in vendor guidance, threat landscape, or Division infrastructure. Step-by-step procedures for documenting configuration baselines, network diagrams, and system architecture are defined in IM-017 – Network and System Documentation.

7. Secure printing

  1. Division print infrastructure shall enforce pull-printing (also known as secure release printing) for all devices connected to networks that process Restricted or Confidential information. Under pull-printing, print jobs are held in a secure queue and released only when the user authenticates at the printer (by badge tap, PIN, or other approved method). This prevents sensitive documents from sitting uncollected in output trays.
  2. Print jobs that are not collected within 24 hours shall be automatically deleted from the print queue. The Technology Department shall configure print servers and managed print devices to enforce automatic deletion.
  3. Fax transmissions containing personal information shall include a cover sheet stating the classification level, the intended recipient, and a confidentiality notice. Fax confirmation pages shall be retained where the transmission contains Restricted or Confidential information. Where feasible, electronic fax (fax-to-email) shall be used in preference to physical fax machines, with Purview sensitivity labels applied to the resulting email per A.P. 313.
  4. Printing of Confidential information requires prior authorization from the Data Owner or Senior Administration in accordance with A.P. 313. The handling requirements for Confidential material in A.P. 313 apply to all printed Confidential records.
  5. The Technology Department shall maintain print audit logs for devices processing Restricted or Confidential information, recording the user, document name, timestamp, and number of pages. Print audit logs shall be retained in accordance with the log retention periods in this procedure.

Review

This procedure shall be reviewed every three years by the Director of Technology, or earlier if triggered by:

Cross reference

Legal references