System Development & Maintenance Standard (SFA 06-107.2.3)

Quick Overview
  • This standard sets the specific requirements for how SFA securely builds, configures, and maintains its information systems and software.
  • It carries out the goals in the SFA 06-107.2 Information Security Technology Policy.
  • Most requirements are carried out by the IT staff who create and run systems (developers, system owners, and security teams), not by general users.
  • These requirements are the minimum baseline SFA must meet; departments may choose to do more.
  • Meeting this standard is mandatory unless a formal exception is granted.

Every system SFA relies on, from a small departmental application to a large enterprise platform, has to be built, configured, and looked after in a secure way. This standard spells out what the university must do across the whole life of a system: document how it works, develop it with only the features it needs, protect it from flaws and malicious code, engineer security in from the start, control how systems connect, lock down approved "known-good" configurations, maintain and repair equipment safely, and manage every change through a formal process. In short, it keeps SFA's systems trustworthy from the day they are designed to the day they are retired.

i
Policy vs. Standard
The matching policy (06-107.2) says what SFA wants to achieve. This standard says how, the concrete requirements. Day-to-day steps live in procedures.

Who This Applies To

This standard applies to all SFA employees, users, third-party service providers, research partners, and other authorized users of SFA information resources, including authorized vendors, visitors, and contingent workers who work within SFA IT facilities. In practice, the requirements below are carried out mostly by the people who build and run SFA systems: the CISO, the Office of Information Security, system developers, and system owners.

i
Baseline, not a ceiling
Everything here is the minimum SFA must do. Departments may add stricter requirements, but never anything weaker. See the SFA 06-107 Controls Crosswalk for higher control tiers.

Who Is Responsible

Key roles & responsibilities ⌄
A note on names: At SFA, the senior information security role is the Chief Information Security Officer (CISO). There is no separate "Information Security Officer" position. The abbreviation ISO at SFA refers to the Office of Information Security (the office that supports the CISO), not to a person.
  • Chief Information Security Officer (CISO) & Office of Information Security: Develop and maintain the processes for secure system development, secure engineering principles, system connections, configuration baselines, and change management, working with developers and product owners.
  • System Developers: Work with system and application owners to build, install, configure, and maintain systems in test and production environments, and put protections in place to prevent and fix vulnerabilities.
  • Privacy Officers (PO): Help make sure development and maintenance processes comply with relevant and emerging laws and regulations.
  • Information System / Application Owners: Work with developers to define what a system needs, make sure it is adequately protected, and monitor for and resolve vulnerabilities.
Full role definitions Complete responsibilities for each role are in the attached standard PDF.

What This Standard Requires

The requirements are grouped into nine areas. Expand any area for a plain-language summary of what it requires. The official requirement numbers (like 06-107.2.3.1.1) are shown so you can match them to the attached PDF.

1  System Operational Documentation  Writing down how each system works ⌄

SFA must keep written security plans and operating documentation for its systems, and keep them current.

  • Create, review, and update system security plans at least every 12 months, covering the system's boundaries, its operating environment, how security requirements are met, its connections to other systems, and the monitoring it needs; update the plans after reviews or when the system changes (06-107.2.3.1).
  • Approve, document, and control any use of real production data in test or pre-production environments, and protect those environments to match the sensitivity of the live data they hold (06-107.2.3.1.1).
  • Build and maintain administrator and user documentation (setup, secure operation, and known risks) and give it to the system administrators, owners, and users who need it (06-107.2.3.1.2).
2  System Development  Building only what's needed, from trusted software ⌄

Systems must be built to expose only the features they need, using software from trusted sources.

  • Apply "least functionality" by turning off unneeded functions, ports, protocols, software, and services, and define hardening requirements for how systems are configured (06-107.2.3.2.1).
  • Review systems at least every 3 months to find unnecessary or insecure functions, ports, protocols, software, and services, and disable or remove them (06-107.2.3.2.2).
  • Build or obtain software only from SFA itself or legitimate third parties, and do not use unapproved Free and Open Source Software unless the CISO reviews and approves it through change management (06-107.2.3.2.3).
  • Create a configuration management plan (roles, how configuration items are identified and managed, review and approval, and protection from tampering) (06-107.2.3.2.4).
  • List the software approved to run, allow only that software to execute (allowlisting), and update the list on a set schedule (06-107.2.3.2.5).
3  Secure System Protections  Guarding against flaws & malicious code ⌄

Systems must be protected against flaws, malicious code, and aging components throughout their life.

  • Give developers only the access their role needs, and screen them based on how sensitive that role is (06-107.2.3.3.1).
  • Replace components once the vendor or manufacturer stops supporting them; keep using an unsupported component (such as an IoT or research device) only with CISO approval and documented risk-reduction steps (06-107.2.3.3.2).
  • Build in protections across the development life cycle, such as sandboxing, virtualization, or separating software and firmware from other software and data (06-107.2.3.3.3).
  • Use secure design principles and secure coding so each system process runs in its own separate, protected space (06-107.2.3.3.4).
  • Find, report, and fix system flaws promptly; test updates for effectiveness and side effects before installing, and apply security updates within set timeframes (06-107.2.3.3.5).
  • Run a patch-management process with risk-based tools, a risk-based patching cadence, and automated patching where feasible (06-107.2.3.3.6).
  • Deploy anti-malware and endpoint protection on all SFA servers, workstations, and laptops, keep it current and always on, scan on access (and workstations at least weekly), and scan incoming and outgoing email at the gateway (06-107.2.3.3.7).
  • Set maximum timeframes for fixing flaws by severity, measure actual fix times against them, and take corrective action when benchmarks are missed (06-107.2.3.3.8).
  • Run integrity checks on software, firmware, and data at startup and on a set schedule, using verification tools to detect unauthorized changes (06-107.2.3.3.9).
  • For high-risk systems, refresh components to a known, trusted state at set intervals or after a suspected compromise, and avoid keeping data longer than needed (06-107.2.3.3.10).
4  Secure System Engineering  Designing security in from the start ⌄

Security and privacy must be engineered into systems from the earliest design stages.

  • Define a common set of security and privacy engineering principles and apply them when specifying, designing, building, and changing systems (06-107.2.3.4.1).
  • Require developers to manage configuration, control the integrity of changes, make only approved changes, document changes and their security and privacy impacts, and track security flaws through to resolution (06-107.2.3.4.2).
  • Require developers to build and follow integrated test plans that evaluate the system under real-world conditions after the design stage (06-107.2.3.4.3).
  • Require developers to review the system's attack surface and reduce it to defined thresholds as part of security testing (06-107.2.3.4.4).
5  System Connections  Authorizing how systems link up ⌄

Connections between SFA systems must be authorized, documented, and reviewed.

  • Set up a process to authorize internal system connections that defines the connection types allowed, their security and communication requirements, when connections must end, and regular reviews to confirm each connection is still needed (06-107.2.3.5.1).
6  Configuration Baselines  Locking in a known-good setup ⌄

SFA must record approved "known-good" configurations and control every change to them.

  • Document and maintain baseline configuration inventories (hardware, software, firmware, and documentation) for critical or high-impact systems (06-107.2.3.6.1).
  • Review and update baseline inventories at least every 12 months, or sooner after environment changes, security incidents, new threats, or regulatory changes (06-107.2.3.6.2).
  • Keep previous baseline versions for a set period to support rollback and data restoration (06-107.2.3.6.3).
  • Track, review, approve or reject, log, and implement configuration changes through authorized users, and retain change logs for a set period (06-107.2.3.6.4).
  • Test, validate, and document changes before implementing them and confirm success afterward, including security and privacy reviewers, and regularly check for unauthorized changes (06-107.2.3.6.5).
  • Use automated processes where feasible to identify, respond to, and mitigate configuration changes made without authorization (06-107.2.3.6.6).
7  Deviations from Baselines  Handling settings that drift ⌄

Configuration settings must be enforced, and any deviation from them handled properly.

  • Set and enforce security configuration settings for SFA IT products, and monitor and control changes to those settings (06-107.2.3.7.1).
  • Identify, document, and approve any deviations from configuration settings, and report and fix unapproved deviations as soon as technically feasible (06-107.2.3.7.2).
8  System Maintenance  Servicing systems safely ⌄

Maintenance and repairs must be scheduled, approved, and carried out without exposing SFA data.

  • Define maintenance processes covering scheduling, approval and monitoring (whether on-site or remote), sanitizing assets before they leave for off-site repair, and re-checking affected security controls afterward (06-107.2.3.8.1).
  • Check and approve maintenance tools for malicious code before use, control and monitor their use, and review approved tools at least every 12 months (06-107.2.3.8.2).
  • Prevent removal of maintenance equipment holding SFA data by verifying it holds none, sanitizing or destroying it, keeping it on-site, or getting explicit authorization to remove it (06-107.2.3.8.3).
  • Approve, monitor, and record remote (nonlocal) maintenance; require multifactor authentication for remote sessions, end sessions immediately when done, and supervise on-site vendor technicians (06-107.2.3.8.4).
9  Change Management  Approving & testing every change ⌄

Changes to systems must follow a formal, tested, and approved process.

  • Run a formal change-management process that covers how changes are requested, documented and tracked, assessed and prioritized, tested in a separate non-production environment, approved by authorized users, and deployed to production (06-107.2.3.9.1).
  • Review changes within a reasonable time after implementation to confirm they were done correctly, work as intended, and produce the desired result (06-107.2.3.9.2).
  • Define, document, approve, and enforce physical and logical access restrictions for making changes, following the principle of least privilege (06-107.2.3.9.3).

Conformance & Exceptions

Meeting this standard is mandatory and effective as of the standard's publication, unless a written contract says otherwise or a formal exception has been granted. If a requirement genuinely cannot be met and there is no feasible remediation, follow the exception process in the SFA 06-107.2 Information Security Technology Policy; requests go to the SFA Chief Information Security Officer (CISO).

!
Important
Violations of SFA 06-107 may lead to disciplinary action, up to and including involuntary separation from employment.

Compliance Mapping (Reference)

For auditors and security staff. Everyday users can skip this section unless you need control references.

Frameworks & control references ⌄

The requirements in this standard map to one or more of these authoritative sources:

  • NIST 800-53 Rev 5.1.1, for example the SA, CM, SI, SC, MA, and CA control families.
  • TAC 202, Subchapter C, for example 202.71(b).
  • Texas DIR Security Controls Catalog, for example SA-5, CM-7, SI-2, MA-4, and CA-9.
  • NIST 800-171 and NIST CSF, for the corresponding development, configuration, and maintenance controls.
  • UTS 165, for example sections 12.2, 20, 21.4, and 22.6.
  • Privacy and financial frameworks (GLBA and HIPAA) where relevant.

The full requirement-by-requirement control mapping is in the attached standard PDF and the SFA 06-107 Controls Crosswalk.

Related Policies & Standards

Supporting policy: SFA 06-107.2 Information Security Technology Policy

Related standards:

Other references:

  • NIST SP 800-160 Vol. 1 Rev. 1: Engineering Trustworthy Secure Systems
  • SFA 06-107 Controls Crosswalk Reference

Responsible office: Office of Information Security  ·  Contact: itsecurity@sfasu.edu

📎
Official document
The complete, official standard is attached to this article as a PDF, including its full requirement text, role definitions, and control mappings. This article summarizes that standard in plain language. If anything in this article conflicts with the attached PDF, the PDF is the official version and takes precedence.

Need Help?

Contact the IT Help Desk at (936) 468-4357 (HELP) or submit a ticket at help.sfasu.edu. For questions about this standard, contact the Office of Information Security at itsecurity@sfasu.edu.
Print Article

Related Articles (2)

Information Security Program Definitions (SFA 06-107)
Definitions of the key terms used throughout the SFA 06-107 information security program; any term shown in italics in a policy or standard is defined here.
Information Security Technology Policy (SFA 06-107.2)
Sets SFA's objectives for the technical safeguards that protect its systems, devices, and data, covering access, asset management, system development, continuity and disaster recovery, security monitoring, and incident response; carried out by Standards 06-107.2.1 through 06-107.2.6.