IT and Cyber Security Questions

If contains Restricted data, Electronic Security Coordinator has been notified and entered into EIR

If contains HIPAA data, HIPAA officer has been notified

Document all data files and locations that may contain Restricted data

All Restricted data files are not world/group readable/writable/executable nor stored in a web-accessible location

All Restricted data files are encrypted

All Restricted data database table columns are encrypted

All Restricted data database tables are audited by access, logged and reviewed

All Restricted data databases have strong user access controls (don’t allow default public access)

Restricted data fields such as SSN is not used as a database key and is consolidated into one table

Restricted data fields such as SSN are de-identified where possible (i.e. only partial SSN or CC number)

All database backup dumps and exports (i.e. BCP) with Restricted data are encrypted and have restricted access

Test environment Restricted data is de-identified

People who have access to shared logins are routinely audited

Encryption keys are created using effective practices for digital keys and signatures

If storing student data, Registrar approval has been obtained

If storing non-public employee data, Payroll and HR approval has been obtained

Database passwords are routinely changed

EmployeeID or CampusID used as the primary person key rather than UCInetID or StudentID

Data model has been documented

Data dictionary has been documented

Database vulnerability assessment scan (Imperva) has been run

Responsible person and backup has been defined


Logging of all access to Restricted data (SQL statements) occurs and is stored in a secure and centralized location

Email is not used to send Restricted data

If the application accesses Restricted data, Electronic Security Coordinator has been notified and entered into EIR

Reports with Restricted data are printed, stored and delivered in a secure manner

If web application provides access to Restricted data, a web application firewall is in place to protect it

No direct SQL manipulation by programmers of Restricted data is done but audited if it must occur

WebAuth is used as authentication method for web applications and proper IP address and time-out validation is done

Proper authorization of user access inside the application is done (i.e. LDAP, SAMS)

Code Review has been performed

Has been tested by application vulnerability tools (Appscan)

The OIT Web Application Security Test procedure has been passed (if a web application) (TBD)

No passwords are hardcoded or stored unencrypted

All input, such as username and password, is fully validated to eliminate SQL Injection (for both web-based and non web-based applications)

Only authorized and traceable changes by programmers are made to any production software program, configuration file, database, or component

Load testing has been performed to identify any security bugs related to threading and session management

Source code is versioned using version control software

Application maintenance follows some change control procedure

Database user used by application has least privilege needed (i.e. non-DBO, read-only access if possible)

If must be PCI compliant, PCI self assessment checklist has been completed

If accesses HIPAA data, HIPAA checklist has been completed

Responsible person and backup has been defined


If accesses Restricted data, Electronic Security Coordinator has been notified

Log of who, what, and time of access to any infrastructure that provides a point of entry to Restricted data (i.e. Apache web access logs) and is archived to a secure and centralized location for forensic purposes

All infrastructure dependent applications are documented and mapped out

Each application must have current security patches applied

An on-going patching procedure with responsible party is defined for each dependent application (i.e. responsible party is subscribed to industry security alert lists)

Has been tested by application vulnerability tools

If storing local security policy (i.e. Expresso, Tomcat, Apache), membership groups and access controls are routinely audited

Digital signatures are used for application authentication/authorization where appropriate

Responsible person and backup has been defined


Access to directories with Restricted data are restricted

OS level logging of servers with Restricted data occurs and is archived to a secure and centralized location for forensic purposes

Shared group accounts are routinely audited

Privilege escalation (i.e. sudo, gsu) and administrative access controls are routinely audited

Passwords are routinely changed

Password strength is high

Failed logins are logged with IP & timestamp (archived and backed up) and repeated failures are locked out

OS specific (software) firewall used if appropriate

OS has been hardened

Only required services are running and ports are open

OS vulnerability assessment scan has been run (i.e. MBSA, Foundstone, Core Impact, TripWire)

Responsible person and backup has been defined


Hardware with Restricted data is physically segmented from non-secure systems

Physical access to hardware with Restricted data is recorded using surveillance system

Server hardware is stored in a secure location with restricted physical access (locks on entrance, seismic bracing, hardware lock devices)

Disaster Recovery and backup procedures are in place with contingency plan

Daily backups are performed, encrypted (if sensitive), and securely stored

Weekly backups are performed, encrypted (if sensitive), and stored securely off-site

Responsible person and backup has been defined


SSL/HTTPS is enforced for all web applications accessing Restricted data

VPN access is used from off-campus or from wireless devices

System is behind local hardware firewall and proper firewall rules are established, documented and routinely audited

Encrypted communication (i.e. SSHv2, VPN) is used for all access to servers

Secure FTP is used for all data transmissions between servers

Incident response plan is in place

System is behind UCI Border firewall, Server Registration has been used to close all non-public ports, and routinely audited

Network diagram exists; and if new, changed, or removed network device, network diagram has been updated

Foundstone is configured to scan device

IDS is configured to scan traffic to and from system where possible

Responsible person and backup has been defined


Power/Admin level special users and those with access to Restricted data undergo extra training and signed policy

Users have signed/agreed to policy which holds them responsible for inappropriate use of Restricted data and keeping their information confidential

If Restricted data is downloaded to local desktop, it must be secured and encrypted

If Restricted data is printed, user is responsible for keeping physical copies secure

Desktops accessing Restricted data applications must be routinely patched and scanned for security vulnerabilities, viruses, and Trojan horses and use professional backup procedures

Desktops should have password protected screensaver or lock out screen and not stay logged in and away from computer while accessing Restricted data

Restricted data is not stored on portable or removable devices

Background checks are done of all administrators, developers, and end-users with access to Restricted data

Least privilege principle is applied to users with access to desktops/laptops (i.e. not running as local admin)

Security awareness training/notification is communicated to users on an ongoing basis

Users and administrators are subscribed to campus security alert notifications

User base is audited for need to access application

Desktops/Laptops are physically secured to prevent theft