Security Monitoring & Vulnerability Scanning Standard (SFA 06-107.2.5)

Systems must keep detailed records (logs) of important activity so SFA can spot, investigate, and report anything that threatens its information.

• Create and keep audit records and logs detailed enough to monitor, analyze, investigate, and report on any activity that could harm the confidentiality, integrity, or availability of information; review the chosen event types at least every 12 months (06-107.2.5.1.1).
• Make sure each record captures the basics: what type of event happened, when, where, its source, its outcome, and who or what was involved (06-107.2.5.1.2).
• Plan enough log storage to meet retention and protection needs, in line with SFA record retention requirements (06-107.2.5.1.3).
• Alert the right people right away (automatically where possible) when logging fails, and fix logging problems as soon as possible; vendors must alert SFA about failures in software they manage (06-107.2.5.1.4).
• Review and analyze logs at least every 30 days for critical systems (and as risk dictates for others), use continuous automated monitoring where feasible, and report suspicious activity through the incident process (06-107.2.5.1.5).
• Keep system clocks synchronized with an authoritative time source so log time stamps are accurate (06-107.2.5.1.6).
• Protect audit records and logging tools from unauthorized access, changes, or deletion (06-107.2.5.1.7).
• Retain audit records for the required time period so they are available for later investigations and to meet regulatory requirements (06-107.2.5.1.8).
• Configure systems so they can generate all needed audit records and let authorized staff choose which event types are logged (06-107.2.5.1.9).

SFA must control and protect the flow of traffic in and out of its networks, and defend against attacks that try to overwhelm or sneak past its defenses.

• Deploy safeguards to limit denial-of-service attacks (which try to overload systems), using traffic filtering, extra capacity and redundancy, and resilient application design (06-107.2.5.2.1).
• Monitor, control, and protect communications at the network's outer and key internal boundaries, and separate publicly accessible systems from internal networks (06-107.2.5.2.2).
• Manage external communication services with standardized interfaces, defined traffic flows, and appropriate protection for the data crossing them (06-107.2.5.2.3).
• Where feasible, block network traffic by default and only allow it by exception ("deny all, permit by exception") (06-107.2.5.2.4).
• Use boundary protections to control data flow within and between systems based on the type and classification of the data (06-107.2.5.2.5).
• End network sessions when they finish or after a defined period of inactivity, where feasible (06-107.2.5.2.6).
• Strengthen boundary protection: prevent unsafe split tunneling on remote devices, isolate security tools and critical functions on separate subnetworks, block unauthorized physical connections, and route public traffic only through managed protection devices (06-107.2.5.2.7).
• Use anti-spoofing measures so attackers cannot fake the security attributes of data sent across SFA networks (06-107.2.5.2.8).

SFA must regularly hire or task testers to safely act like attackers ("penetration testing") to find weaknesses before real attackers do.

• Run penetration tests on a defined schedule to find weaknesses in systems, components, and services; test any website or mobile app that handles PII or confidential information (as required by Texas law); perform an external network penetration test at least every 12 months; and, where feasible, run internal red-team exercises without advance notice for a realistic test (06-107.2.5.3.1).
• Include physical (facility) penetration testing of buildings that house information systems, on a defined schedule, to check that physical and environmental security controls actually work (06-107.2.5.3.2).

SFA must keep unwanted and harmful content out of its systems, from spam and phishing emails to risky "mobile code" that runs automatically.

• Use effective spam and phishing protection at the points where messages enter and leave systems, and keep those protections updated as new releases become available (06-107.2.5.4.1).
• Run automated data validation and integrity checks on important data inputs (such as user input, system data, application interfaces, and network traffic) for confidential data where feasible (06-107.2.5.4.2).
• Define which "mobile code" (small programs that run inside webpages or applications) is acceptable, block unacceptable code, control how it is acquired and used, and stop it from running automatically (06-107.2.5.4.3).

SFA must gather and share up-to-date information about threats so the university can prepare for and prevent attacks.

• Share the "indicators of compromise" (clues that reveal an attack) learned from incidents with the right managers and stakeholders so similar problems can be prevented (06-107.2.5.5.1).
• Continuously obtain security alerts, advisories, and directives from paid and open-source intelligence, vendors, and manufacturers; pass them to the right owners and staff; and act on directives within defined time frames (06-107.2.5.5.2).
• Use automated tools to exchange threat intelligence with internal and external partners (such as UT System, the Texas Department of Information Resources, and industry sharing groups) to improve situational awareness (06-107.2.5.5.3).
• Monitor open and public sources (such as websites, code repositories, and paste sites) to catch any unauthorized disclosure of SFA information and feed that into threat and incident response work (06-107.2.5.5.4).

SFA must regularly scan its systems for weaknesses, watch for signs of attack, and fix the most serious problems quickly.

• Scan systems for vulnerabilities on a risk-based schedule (at least monthly, or when new vulnerabilities appear), choose the right scan type for each system, and prioritize expedited fixes for high-severity, commonly exploited, or end-of-life issues (06-107.2.5.6.1).
• Provide a public reporting channel (such as an email address or phone number) so anyone can report a vulnerability they find in SFA systems (06-107.2.5.6.2).
• Monitor systems and network traffic to detect attacks, unauthorized connections, and unauthorized use; analyze what is found; and alert incident response staff immediately, coordinating with Privacy Officers as needed (06-107.2.5.6.3).
• Use a wireless intrusion detection system to spot rogue wireless devices and detect attempted attacks or breaches (06-107.2.5.6.4).
• Correlate event and suspicious-activity information from monitoring to build integrated, UT systemwide situational awareness (06-107.2.5.6.5).
• Work with Privacy Officers (PO), Human Resources (HR), and other departments to set up monitoring for high-risk individuals when determined necessary (06-107.2.5.6.6).
• Define processes for acquiring, managing, and exiting cloud services, with protections matched to the sensitivity of the data involved (06-107.2.5.6.7).
• Document how far and how deep vulnerability scanning reaches (systems, components, vulnerability types, methods, and coverage) and review that coverage at least every 12 months (06-107.2.5.6.8).