Information Technology Resources
Guidelines
College of Agricultural & Environmental Sciences
Table of Contents
1. Purpose .......................................................................................................................... 4
2. Background .................................................................................................................... 4
3. Scope ............................................................................................................................. 4
4. Glossary ......................................................................................................................... 5
5. Data Classification ......................................................................................................... 7
6. Guidelines ...................................................................................................................... 8
6.1. CAES Information Security Program Management ..............................................................8
6.2. Risk Management ..............................................................................................................8
6.2.1. Risk Assessment.............................................................................................................8
6.2.2. Risk Treatment ..............................................................................................................8
6.3. Exceptions Management ....................................................................................................8
6.4. Device Management ..........................................................................................................8
6.4.1. Procuring Devices ................................................................................................................................... 9
6.4.2. Operating systems.................................................................................................................................. 9
6.4.3. Malware Protection ............................................................................................................................... 9
6.4.4. Warranty and Inventory ......................................................................................................................... 9
6.4.5. Accountability ...................................................................................................................................... 10
6.5. Access Management ........................................................................................................ 10
6.6. Software Management .................................................................................................... 10
6.6.1. Supplier Software Licensing ................................................................................................................. 10
6.6.2. Open Source ......................................................................................................................................... 11
6.6.3. Incidental Personal Use ........................................................................................................................ 11
6.7. Data Management ........................................................................................................... 11
6.7.1. Encryption ............................................................................................................................................ 11
6.7.2. Backups ................................................................................................................................................ 11
6.7.3. UC Email and Calendar ......................................................................................................................... 11
6.7.4. Institutional Information documents ................................................................................................... 12
6.7.5. Personal devices ................................................................................................................................... 12
6.8. Incident Management ...................................................................................................... 12
6.9. Physical Security .............................................................................................................. 12
6.10. Procurement .................................................................................................................... 12
Appendix A: Device Support Policies ..................................................................................... 15
Devices per Workforce Member ................................................................................................... 15
Personal devices .......................................................................................................................... 15
Appendix B: Minimum Security Standards ............................................................................ 16
Appendix C: Warranty and Replacement Schedule................................................................ 17
Warranties................................................................................................................................... 17
Replacement Schedule ................................................................................................................. 17
Funding ....................................................................................................................................... 17
Workstation standards ................................................................................................................. 17
Multiple offices ............................................................................................................................ 18
Appendix D: Privileged Account Policies ............................................................................... 19
Appendix E: Supported Software Standard ........................................................................... 20
Software Installation .................................................................................................................... 20
Email and Calendar Standard........................................................................................................ 20
Personal device access to Institutional Data .................................................................................. 20
Supported Software List ............................................................................................................... 20
Appendix F: Encryption Standards ........................................................................................ 22
Android ....................................................................................................................................... 22
ChromeOs .................................................................................................................................... 22
iOS .............................................................................................................................................. 22
Linux ........................................................................................................................................... 22
MacOS ......................................................................................................................................... 22
Windows ..................................................................................................................................... 22
Appendix G: Backup Standards ............................................................................................ 23
Android ....................................................................................................................................... 23
iOS .............................................................................................................................................. 23
Laptops........................................................................................................................................ 23
Appendix H: Data Storage, Retention, and Disposal Standards ............................................. 24
Data Storage ................................................................................................................................ 24
Retention Schedule ...................................................................................................................... 24
Disposal Methods: ....................................................................................................................... 25
Appendix I: Information Security Incident Response Plan Requirements ................................ 26
Appendix J: Secure Software Configuration and Development .............................................. 29
Software Configuration Standards ................................................................................................ 29
Secure Software Development Standards ..................................................................................... 30
1. Purpose
This document is intended to provide specific guidance for compliance with University of
California Policy BFB-IS-3
1
in a cost-effective and risk-based manner while maintaining a safe
and reliable computing environment that supports the needs of faculty, students, and staff.
Guidance described in the UC Davis Location Information Management Security Program (ISMP)
may supersede requirements described in this document.
2. Background
IS-3 follows both a standards- and risk-based approach to information security to ensure that
UC meets industry, government and regulatory requirements while also properly scoping
controls and making appropriate investment decisions.
The policy establishes a framework to achieve six goals:
• Preserve academic freedom and research collaboration
• Protect privacy
• Follow a risk-based approach
• Maintain confidentiality
• Protect integrity
• Ensure availability
The policy incorporates a subset of controls from the international standards ISO 27001 and ISO
27002 that align with and support UC’s mission of research, teaching and public service. IS-3
also addresses legal requirements associated with HIPAA, the Payment Card Industry (PCI) and
other state and federal regulations and includes requirements needed to qualify for certain
grants that are essential to UC research funding (NIST 800-171). Additionally, IS-3’s risk-based
approach guides the allocation of resources by evaluating risk and assessing the cost and
benefit of risk management.
3. Scope
These guidelines apply to all of the following
2
:
• All Workforce Members, Service Providers and other authorized users of Institutional
Information and IT Resources.
3
• All use of Institutional Information, independent of the location (physical or cloud) or
ownership of any device or account that is used to store, access, process, transmit, or
control Institutional Information.
• All devices, independent of their location or ownership, when connected to a UC
network or cloud service by Workforce Members, Service Providers, and authorized
1
https://policy.ucop.edu/doc/7000543/BFB-IS-3
2
Page 3, Scope for https://security.ucop.edu/files/documents/policies/minimum-security-standard.pdf
3
See https://security.ucop.edu/policies/quick-start-guides-by-role/index.html for particular guidelines by role
users, which may include Suppliers providing Workforce Members, used to store or
process Institutional Information.
• Research projects performed at any Location, and UC-sponsored work performed by any
Location.
The Standard (and these Guidelines) do not apply to the following:
• End-user devices used and owned by students for the purposes of attending the
University and completing projects.
• Students who are not Workforce Members.
4
Workforce Members must signify their understanding and acceptance of these Information
Technology Resources Guidelines via electronic signature.
4. Glossary
For the purposes of this document, the following terms and definitions given in the University
of California BFB-IS-3 apply.
CISO: A role responsible for security functions throughout a Location, including assisting in the
interpretation and application of this policy.
Institutional Information: A term that broadly describes all data and information created,
received and/or collected by UC.
IT Resources: A term that broadly describes IT infrastructure, software and/or hardware with
computing and networking capability. These include, but are not limited to: personal and
mobile computing systems and devices, mobile phones, printers, network devices, industrial
control systems (SCADA
5
, etc.), access control systems, digital video monitoring systems, data
storage systems, data processing systems, backup systems, electronic and physical media,
biometric and access tokens and other devices that connect to any UC network. This includes
both UC-owned and personally owned devices while they store Institutional Information, are
connected to UC systems, are connected to UC Networks or used for UC business.
Information Management Security Program: A minimum set of information security
requirements, providing Locations with the following four methods of identifying applicable
security controls to manage cyber security risk:
• Conduct a Risk Assessment – see Part III, § 6 of BFB-IS-3.
• Use a Risk Treatment Plan – see Part III, § 6.1.2 of BFB-IS-3.
• Use this policy and related standards to identify applicable controls.
4
See question 10 on https://security.ucop.edu/files/documents/policies/is-3-faq.pdf
5
https://en.wikipedia.org/wiki/SCADA
• Some combination of the above.
Location: A discrete organization or entity governed by the Regents of the University of
California. Locations include, but are not limited to: campuses, laboratories, medical centers
and health systems, as well as satellite offices, affiliates or other offices in the United States
controlled by the Regents of the University of California.
Service Provider: A UC internal organization that offers IT services to Units. Service Providers
typically assume most of the security responsibility and help Units understand Unit
responsibilities with respect to cyber security.
Supplier: An external, third-party entity that provides goods or services to UC. BFB-IS-3 Part III §
15 describes what Suppliers must do. UC has specific contract terms that clarify the
responsibilities of Suppliers and protect UC.
UC: University of California.
Unit: A point of accountability and responsibility that results from creating/collecting or
managing/possessing Institutional Information or installing/managing IT Resources. A Unit is
typically a defined organization, such as the school of engineering, or a set of departments,
such as student affairs. Because UC is a highly decentralized and independent federation of
organizational units, the policy provides Units with the flexibility and responsibility to manage
cyber risk.
Unit Head: A generic term for dean, vice chancellor or person in a similarly senior role who has
the authority to allocate budget and is responsible for Unit performance. At a particular
Location or in a specific situation, the following senior roles may also be Unit Heads:
department chairs, assistant/associate vice chancellor (AVC), principal investigators, directors
or senior managers. Unit heads have important responsibilities to ensure effective
management of cyber risk.
Unit Information Security Lead: A term for the Workforce Member(s) assigned responsibility
for tactical execution of information security activities including, but not limited to,
implementing security controls; reviewing and updating Risk Assessment and Risk Treatment
plans; devising procedures for the proper handling, storage and disposal of electronic media
within the Unit; and reviewing access rights.
Workforce Member: An employee, faculty, staff, volunteer, contractor, researcher, student
worker, student supporting/performing research, medical center staff/personnel, clinician,
student intern, student volunteer or person working for UC in any capacity or through any
other augmentation to UC staffing levels.
5. Data Classification
Protection and Availability Levels are used to help assess risk and select security controls
required by this guideline.
6
Protection (P) Levels
P4
Statutory, regulatory and contract obligations are major drivers for this risk level.
Other drivers include, but are not limited to, the risk of significant harm or impairment
P3
Unauthorized disclosure or modification could result in small to moderate fines,
penalties or civil actions. Could result in moderate damage to UC, its students,
patients, research subjects, employees, community and/or reputation; could have a
moderate impact on the privacy of a group; could result in moderate financial loss
P2
May not be specifically protected by statute, regulations or other contractual
obligations or mandates, but are generally not intended for public use or access
P1
Public information or information intended to be readily obtainable by the public, but
whose integrity is important and for which unauthorized modification is the primary
protection concern. IT Resources where the application of minimum security
requirements is sufficient
Availability (A) Levels
A4
Loss of availability would result in major impairment to the overall operation of the
Location and/or essential services, and/or cause significant financial losses
A3
Loss of availability would result in moderate financial losses and/or reduced customer
service
A2
Loss of availability may cause minor losses or inefficiencies
A1
Loss of availability poses minimal impact or financial losses
6
https://security.ucop.edu/policies/institutional-information-and-it-resource-classification.html
6. Guidelines
6.1. CAES Information Security Program Management
Information security and risk management decisions will be made consistent with this
guideline. The Unit Head is responsible for the CA&ES Information Security Program. The
Unit Information Security Leads are responsible for the tactical execution of this guideline.
All Workforce Members are responsible for ensuring the protection of Institutional
Information and IT Resources. Access to Institutional Information should follow the
principles of Need to Know and Least Privilege.
7
6.2. Risk Management
The risk management process will involve:
• Identifying and classifying assets
• Protecting assets and assessing risks based on the requirements described in this
guideline
• Monitoring risks on an ongoing basis
6.2.1. Risk Assessment
A Risk Assessment program shall be established in collaboration with the CISO by the
Unit Information Security Leads that requires performing routine risk assessment of
CA&ES Units. At a minimum, this assessment should include the Protection Level and
Availability Level
8
, and the Service Provider or Supplier for all IT Resources in use by the
Unit.
6.2.2. Risk Treatment
A Risk Treatment Plan, reviewed and/or updated annually, shall be completed by the
Unit Information Security Leads, and signed off on by the Unit head.
6.3. Exceptions Management
This guideline describes a risk-based approach to managing information security within the
college. Exceptions to these guidelines are approved by the Unit Head, who assumes the
risk.
9
If required by the UC Davis ISMP, exceptions must be registered and approved by the
CISO. For each exception registered with the CISO, a Risk Assessment and Risk Treatment
Plan shall also be filed.
6.4. Device Management
Devices include workstations, laptops, mobile phones, and tablets. The College shall establish
a Device Support Policy (Appendix A) consistent with business needs and protection of
Institutional Information. Items that must be addressed include the allowable number of
7
See §9 of https://policy.ucop.edu/doc/7000543/BFB-IS-3
8
https://security.ucop.edu/policies/institutional-information-and-it-resource-classification.html
9
See questions 4, 5, and 6 on https://security.ucop.edu/files/documents/policies/is-3-faq.pdf
Devices per Workforce Member, and support of personally-owned devices containing
Institutional Information. In addition, each device must be configured according to Appendix
B: Minimum Security Standards.
6.4.1. Procuring Devices
Where possible, supported devices should be procured via agreements in Aggie Buy
10
using standards such as Aggie Desktop
11
to take advantage of UC pricing and economies
of scale. The Service Provider should review requests prior to purchase to ensure
equipment and services may be configured securely and tracked appropriately.
12
Workforce Members issued cellular phones and other portable electronic resources must
follow BFB-G-46
13
and sign the appropriate usage agreement.
14
6.4.2. Operating systems
Supported devices must run a currently maintained and patched version of Android,
Chrome OS, iOS, Linux, MacOS, or Windows. Legacy equipment running obsolete
operating systems or applications must be approved via exception or removed from
network access.
15
Current and future device procurement should include agreements
with the Supplier to ensure security patches for the usable life of the device. Exceptions
require consultation with the CISO
16
and must be recorded on the Risk Register.
6.4.3. Malware Protection
Supported network devices must run malware protection software as detailed in
Appendix B: Minimum Security Standards.
6.4.4. Warranty and Inventory
All supported devices should be warrantied and must be inventoried. The CA&ES
standard for inventory management software is PEAKS (People, Equipment, Access,
Keys, and Space)
17
. The Warranty and Replacement schedule is given in Appendix C.
Replaced devices shall be retired via Aggie Surplus
18
in accordance with UC Davis
policy
19
.
10
https://aggiebuy.ucdavis.edu
11
https://aggiedesktop.ucdavis.edu
12
Topic #11, https://security.ucop.edu/policies/security-controls-everyone-all-devices.html
13
https://policy.ucop.edu/doc/3420357/BFB-G-46
14
https://www.ucop.edu/information-technology-services/services/ucop-it-services/work-equipment-computers-
smartphones-software/files/device-usage-agreement.pdf
15
§ 12.6 Technical vulnerability management and patch management, https://policy.ucop.edu/doc/7000543/BFB-
IS-3
16
https://security.ucdavis.edu/security/services_and_consultation
17
https://peaks.ucdavis.edu/Home/
18
https://supplychain.ucdavis.edu/procure-contract/stores/aggie-surplus
19
https://ucdavispolicy.ellucid.com/documents/view/505
6.4.5. Accountability
In order to provide updated inventorial accountability, every Workforce Member issued
a supported device must positively affirm receipt, relinquishment, or retirement of that
device in PEAKS or a similar system.
6.5. Access Management
To use IT Resources, each Workforce Member must be assigned one or more accounts of
the following types:
20
• User accounts, such as the campus login, are under the control of a specific
individual and used to access systems such as Office 365, Aggie Budget, etc. Campus
directive requires the use of Duo 2-factor authentication for all campus accounts,
which must not be accessible to others.
• Functional or shared accounts may be accessed by multiple individuals to
accomplish a shared purpose or appear as a single entity (e.g. CA&ES Advising).
• Privileged accounts are used in the administration of IT Resources. They must be
separate from and unable to access regular user account systems (such as email),
must be used only when required, and access must be relinquished as soon as the
functions of the privileged account are no longer necessary. See Appendix D:
Privileged Account Policies for further details.
UC Davis accounts should not be used or affiliated with personal accounts (e.g. Facebook).
Positions requiring the use of social media should provision those accounts as functional
accounts (e.g. Twitter @ucdavisCAES). Outside vendor accounts such as Amazon, which may
use UC Davis email by default, should be separated into personal and business accounts.
21
Passwords must not be recycled between accounts.
6.6. Software Management
Software on supported devices should have an explicit business purpose. Unless otherwise
required (e.g. for accessibility, compatibility with equipment/software or due to licensing
restrictions), the most recent version should be used. Refer to Appendix E, Supported
Software Standard.
6.6.1. Supplier Software Licensing
All software obtained from a Supplier must be reviewed by campus purchasing and have
a license that conforms with the business agreement between UC and the Supplier.
22
Software Licenses are often audited by the Supplier, and non-compliance may expose
UC to significant financial penalties. Installation of Supplier Software should be done by
automated means to ensure compliance. The standard for automated software
deployment and removal is listed in Appendix E.
20
https://security.ucop.edu/files/documents/policies/account-and-authentication-management-standard.pdf
21
See §4.5 of https://security.ucop.edu/files/documents/policies/account-and-authentication-management-
standard.pdf
22
https://supplychain.ucdavis.edu/procure-contract/buying-goods/software
6.6.2. Open Source
Use of Open-source software
23
should conform with the guidelines for using Copyright-
Protected Materials.
24
6.6.3. Incidental Personal Use
Software for incidental personal use is allowed as long as it does not interfere with
Supported Software and its use does not directly or indirectly interfere with the
University’s operation of resources; does not interfere with the user’s employment or
other obligations to the University; does not burden the University with noticeable
incremental costs; and does not violate the law or University policy.
25
Software that
does interfere with Supported Software or University operations will be removed.
6.7. Data Management
Electronically stored information must not be unintentionally released or accessed by
unauthorized parties. Security standards in Appendix B address this goal.
6.7.1. Encryption
26
All laptops, small form-factor desktops, mobile devices, and portable storage (e.g. USB
keys) must be encrypted to ensure that easily lost physical media is default protected in
accordance with state and federal law. Encryption keys shall be stored in a central
repository accessible to the Service Provider. In most cases, knowledge of the
encryption key is not required by the Workforce Member to access electronically stored
information. Provision of an encryption key to a Workforce Member (e.g. for remote
recovery of corrupted systems) requires that the device be re-encrypted with a different
key as soon as practical. See Appendix F for further details.
6.7.2. Backups
All laptops and mobile devices shall be backed up to ensure that loss or hardware failure
of the device does not cause loss of Institutional Information.
27
Per upcoming BFB-IS-12
standards
28
, a backup is defined as comprising separate on-site and off-site copies or
versions. See Appendix G: Backup Standards for further details.
6.7.3. UC Email and Calendar
All UC business done by email shall be transacted with a UC email account (Office 365 or
DavisMail). The standard for email and calendar is listed in Appendix E.
23
https://en.wikipedia.org/wiki/Open-source_software
24
https://research.ucdavis.edu/industry/ia/researchers/copyright/copyright-protected/
25
https://ucdavispolicy.ellucid.com/documents/view/357
26
https://security.ucop.edu/files/documents/policies/encryption-key-and-certificate-management-standard.pdf
27
See question 2 in https://security.ucop.edu/files/documents/policies/is-3-implementation-faq.pdf
28
Policy is currently being revised, original is https://policy.ucop.edu/doc/7020451/BFB-IS-12
6.7.4. Institutional Information documents
All Institutional Information documents shall be stored in approved cloud (e.g Box
29
) or
local storage according to the Data Sensitivity Guide
30
and Appendix H: Data Storage,
Retention, and Disposal Standards. HIPAA
31
or PCI
32
information must be stored in a
secure filesystem.
6.7.5. Personal devices
Institutional Information must not be stored on personal devices unless the Institutional
Information on that personal device is managed by the Service Provider.
33
Access to UC
IT Resources must be mediated by a secured system that is configured to protect
Institutional Information appropriately. The standard for access by personal devices is
listed in Appendix E.
6.8. Incident Management
The CA&ES Information Security Incident Response Plan meets the minimum standards
described in the UC Information Security Incident Response Standard
34
and/or the UC Davis
Information Security Management Plan (ISMP). Details may be found in Appendix I:
Information Security Incident Response Plan Requirements.
6.9. Physical Security
Devices and Institutional Information must be physically secured. Institutional Information
residing in the Cloud must be approved by campus purchasing so as to comply with UC
policy, and must have appropriate physical restrictions on the location of datacenters.
6.10. Procurement
Research, teaching, and administrative service require systems that are purchased, leased,
open sourced, developed in-house, or hosted in the cloud and configured (or developed) by
the College, Service Provider, or Supplier. These applications represent significant
resources, knowledge, and expenditures for UC. They may also present significant cyber
risks if not configured properly and/or developed according to secure software
development practices. As with other policies in these guidelines, the goal is to ensure that
such IT Resources maintain confidentiality, protect integrity, and ensure availability.
Procuring or developing such applications must follow the standards in Appendix J: Secure
Software Configuration and Development and the UC Davis Bidding Guidelines.
35
29
https://box.ucdavis.edu
30
https://cloud.ucdavis.edu/about-data-sensitivity-guide
31
https://www.ucop.edu/ethics-compliance-audit-services/compliance/hipaa/
32
https://cashier.ucdavis.edu/banking-services
33
https://security.ucop.edu/policies/security-controls-everyone-all-devices.html
34
https://security.ucop.edu/files/documents/policies/incident-response-standard.pdf
35
https://supplychain.ucdavis.edu/sites/g/files/dgvnsk2181/files/inline-files/UCDavisBiddingMatrix070118.pdf
I agree to abide by these policies.
Signature: ______________________________________________ Date: _________________
Appendix A: Device Support Policies
Device Support Policies may be customized to the individual needs of the units.
Devices per Workforce Member
To maintain efficient support, no more than 2 devices of any type (workstation, laptop, phone,
or tablet) per Workforce Member shall be supported by the Service Provider (e.g. the
Computing Resources Unit for the CA&ES Dean’s Office).
Personal devices
Support for personal devices may be limited by the Service Provider for the Unit, as follows:
• Configuration of Office 365 or DavisMail
• Configuration of access to remote services such as VPN or Box
• Configuration of 2-factor authentication
Appendix B: Minimum Security Standards
#
Topic
Requirement
36
CA&ES Standard
1
Anti-malware
Anti-malware software must be installed
and running up-to-date definitions.
Sophos or BitDefender with central console
2
Patching
Supported security patches must be
applied to all operating systems and
applications.
BigFix on Windows and MacOS, Puppet on
Linux
3
Privileged
accounts
Non-privileged user accounts must be used
and only elevated to root or Administrator
when necessary.
Local user admin managed with LAPS in
uConnect
4
Encryption
Laptops and mobile devices must be
encrypted. Separately, Institutional
Information classified at Protection Level 3
or higher must be encrypted when stored
on Laptops and mobile devices.
Windows: BitLocker
MacOS: FileVault
5
Session
timeout
Devices used to store or access Institutional
Information or IT Resources classified at
Protection Level 2 or higher must employ
lockout/screen-lock mechanisms or session
timeout or to block access after a defined
period of inactivity (15 minutes or Location
limit). Mechanisms must require re-
authentication before a return to
interactive use.
Windows: 15 minutes by group policy
MacOS: 15 minutes by screensaver setting
6
Password/PIN
Secure devices with a strong password,
PIN, smart card or biometric lock.
Duo for all campus accounts. At least a 6-digit
PIN.
7
Physical
security
Devices and Institutional Information must
be physically secured.
Servers in Data Center. Workstations in locked
offices or laboratories using key cards
inventoried by PEAKS. External security cameras
where appropriate monitored by UCD Police
according to policy.
8
Backup
Institutional Information classified at
Availability Level 3 or higher must be
backed up and recoverable. Backups must
be protected according to the classification
level of the information they contain.
CrashPlan for all laptops.
DPM for servers.
Box for all business data.
9
Portable
media
Backups and portable media containing
Institutional Information classified at
Protection Level 4 must be encrypted and
safely stored.
Minimize use of portable media; use CrashPlan
for Backups or Box for storage
10
Host-based
firewall
If host-based firewall software is available
on a device, it must be running and
configured to block all inbound traffic that
is not explicitly required for the intended
use of the device.
Network firewalls with ingress and egress rules
11
Approval and
inventory
Make sure devices can be secured before
making a purchasing decision. Make sure IT
Resources and Institutional Information are
appropriately recorded in Location
inventory.
PEAKS
12
Supported
Operating
Systems
Run a version of the operating system that
is supported by the vendor.
macOS 10.12 or later
37
Windows 8.1 or later
38
Ubuntu 18.04
36
https://security.ucop.edu/files/documents/policies/minimum-security-standard.pdf
37
https://support.apple.com/en-us/HT201222
38
https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet
Appendix C: Warranty and Replacement Schedule
The Warranty and Replacement schedule may be customized to the individual needs of the
units.
Warranties
Warranties are purchased for the duration of the Replacement Schedule, where possible. Apple
and some other vendors only have 3 year warranties; the last year(s) of service may still be
supported. Alternately, units may specify desktops and laptops from these vendors with a 3
year replacement schedule.
Replacement Schedule
• Desktops: 5 years
• Laptops: 4 years
• Mobile devices (phones and tablets): 3 years
• Monitors: 8 years
There are instances in which the Replacement Schedule may be accelerated by a year, e.g. high-
performance lab computers or workstations for faculty or staff with compute-intensive
workloads.
Funding
The Dean’s Office funds workstations for career/permanent positions in central administrative
units as follows:
• Desktops: $900
• Laptops: $1400
• Laptop Dock (keyboard, mouse): $300
• Monitors: $500
These amounts are intended to cover the full cost for standard configurations procured through
AggieBuy. Any costs beyond these levels for custom configurations must be covered by unit
funds. Mobile devices and their plans are also covered by unit funds.
Workstation standards
A desktop system is a tower or mini chassis, two monitors (or a single widescreen), a keyboard,
and a mouse.
A laptop system is a laptop, dock, two monitors (or single widescreen), keyboard, and a mouse.
Multiple offices
The Dean’s Office will cover one office workstation. Additional office workstations must be
covered by unit funds. Note that in the case of laptop systems, additional docks and monitors
are all that are required.
Appendix D: Privileged Account Policies
Privileged accounts are used to administer IT Resources. Examples include:
• Local administrator account on a laptop
• “root” access to the network firewall
• uInform access to uConnect administration tools
Privileged accounts must have a strictly defined scope of access, and must be used only when
required, only for how long required.
In accordance with the UC Account and Authentication Management Standards
39
, privileged
account access is provided on a strictly necessary basis. An example would be a faculty member
traveling internationally or in locations with poor internet access for which the Service Provider
is unable to provide an acceptable level of service.
Privileged account use may be logged as required by policy (e.g. PCI DSS standards
40
).
As needed, systems on which privileged account access was granted may be rolled back or
reimaged to a state before the privileged account actions were taken.
39
https://security.ucop.edu/files/documents/policies/account-and-authentication-management-standard.pdf
40
https://www.pcisecuritystandards.org/document_library
Appendix E: Supported Software Standard
The Supported Software Standard may be customized to the individual needs of the units.
Software Installation
To ensure compliance with licensing, all software must be installed by BigFix
41
(MacOS,
Windows) or Puppet (Linux).
42
Email and Calendar Standard
The standard for email and calendar is Office 365.
43
Personal device access to Institutional Data
The standard for access by personal devices is Office 365, Box
44
, or Remote Desktop.
Supported Software List
• .NET 3.5
• 3DF Zephyr Free
• 7-Zip 16.04
• Adobe Acrobat DC 2017
• Adobe Creative Cloud
• ArcGIS 10.5
• ArcGIS Online
• ArcGIS Pro
• AutoCAD 2017
• Box for Office
• Box Tools
• California Wildlife Habitat Relationships
• Cytoscape 3.6.0
• DNR GPS 6.1.0.6
• Easy GPS 5.79.0.0
• EndNote X7 17.7.1
• FileZilla Client 3.29.0
• Flapjack v1.16.10.31
• GeoDa 1.12
• Git Bash
• Google Chrome
• Google Earth Pro 7.3.0
41
https://itcatalog.ucdavis.edu/service/bigfix
42
https://puppet.ucdavis.edu
43
https://365.ucdavis.edu
44
https://box.ucdavis.edu
• Grasshopper
• GWR4 4.09
• IDL 8.4 and ENVI 5.2
• Integrated Genome Browser 9
• Irricad Pro V15
• Java 8 Update 152
• Java 8 Update 162
• Lumion 8.3
• Marxan
• MEGA 7
• Microsoft Office 2019
• Model Viewer
• ModelMuse
• Mozilla Firefox
• Notepad++ 7.5.3
• Pix4Dmapper
• PSPP
• PuTTy 0.70
• QGIS 2.18.15
• R for Windows 3.4.3
• Rhinoceros 5.14
• RhinoTerrain 2 LAB
• RStudio 1.1.383
• SketchUp Pro 2018
• Tablet v1.17.08.17
• Vectorworks 2018
• Vector NTI v11
• Windows Subsystem for Linux
• WinSRFR 4.1.3
• WinSIPP3
• Zoom
Appendix F: Encryption Standards
Android
Default
45
ChromeOs
Default
46
iOS
Default
47
Linux
Encrypt the /home directory
MacOS
FileVault
48
Windows
BitLocker
49
45
https://source.android.com/security/encryption/
46
https://support.google.com/chromebook/answer/3438631?hl=en
47
https://training.apple.com/us/en/courses/ios/ios_security_and_privacy_workshop
48
https://support.apple.com/en-us/HT204837
49
https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-device-
encryption-overview-windows-10
Appendix G: Backup Standards
Backup Standards may be customized to the individual needs of the units, excepting
Institutional Information classified at A3 or P3.
Android
Google account
iOS
iCloud account
Laptops
CrashPlan
50
50
https://itcatalog.ucdavis.edu/service/crashplan
Appendix H: Data Storage, Retention, and Disposal
Standards
Data Storage
A unit share is a location that stores information accessible to multiple Workforce Members.
A home directory is a location that stores information accessible to a single Workforce
Member.
A secure encrypted fileserver is encrypted, network isolated to specifically allow only
authorized users, and has access controls audited on a quarterly basis.
A secure encrypted service is encrypted, requires 2-factor authentication for authorized users,
and has access controls audited on a quarterly basis.
Data Type
Location
51
Personal Information
Box home directory
Institutional Information
Box unit share
PII low level
Box unit share
Student education records
Box unit share
Credit Card or Payment Card Industry (PCI)
information
Secure, encrypted fileserver or service
Export Controlled Research (ITAR, EAR, OFAC)
Secure, encrypted fileserver or service
Medical/Health Information
Secure, encrypted fileserver or service
Protected Health Information (HIPAA)
Secure, encrypted fileserver or service
Attorney/Client Privileged Information
Secure, encrypted fileserver or service
Federal Information Security Management Act
(FISMA) Data
Secure, encrypted fileserver or service
IT Security Information
Secure, encrypted fileserver or service
Other Sensitive Institutional Data
Secure, encrypted fileserver or service
Personally Identifiable Information (PII) High Level
Secure, encrypted fileserver or service
Personally Identifiable Information (PII) Moderate
Level
Secure, encrypted fileserver or service
Sensitive Identifiable Human Subject Research
Secure, encrypted fileserver or service
Student Loan Application Information (GLBA)
Secure, encrypted fileserver or service
Retention Schedule
The University of California Records Retention Schedule
52
is defined by BFB-RMP-1: University
Records Management Program
53
and comprises hundreds of record types. Additional polices
51
Based on the Data Sensitivity Guide for Box. https://cloud.ucdavis.edu/services/box-davis
52
https://recordsretention.ucop.edu
53
https://policy.ucop.edu/doc/7020453/BFB-RMP-1
apply in the event of “pending, foreseeable, or ongoing litigation; an investigation; or an
ongoing audit pertaining to the records”; contact the appropriate records management
coordinator for further guidance.
54
Disposal Methods:
Guidelines from the UC Institutional Information Disposal Standard.
55
See §§3-4 for a definition
of terms and requirements.
Institutional Information Protection Level
56
Device/Data
Location
P1
P2
P3
P4
Hard disk drives –
portable or internal
Delete
Clear
Purge
Purge/Destroy
Logical Storage
Logical Delete
Logical Delete
Cryptographic
Erase
Cryptographic
Erase
Optical disk – read
only (CD_ROM,
DVR_ROM, etc.)
Destroy
Destroy
Destroy
Destroy
Optical disk –
read/write (CD-
R/W, DVD-R/W,
etc.)
Delete
Clear
Destroy
Destroy
Other embedded
storage devices
Delete
Clear
Purge
Purge
Portable media –
electronic (thumb
drive, USB stick)
Delete
Clear
Purge
Destroy
Portable magnetic
media – tape
Delete
Degauss
Destroy
Destroy
Solid state drives
(SSD)
Delete
Cryptographic
Erase
Cryptographic
Erase
Cryptographic
Erase
54
https://www.ucop.edu/information-technology-services/initiatives/records-management/records-management-
committee.html
55
https://security.ucop.edu/files/documents/policies/uc-institutional-information-disposal-standard.pdf
56
https://security.ucop.edu/policies/institutional-information-and-it-resource-classification.html
Appendix I: Information Security Incident Response Plan
Requirements
The minimum standards for an Information Security Incident Response Plan is given by the UC
Information Security Incident Response Standard.
57
This plan must be on file for every Unit, and
include the following elements:
1. Identify Incident Response Team members.
a. Determine and assign roles.
b. Describe responsibilities for a role’s duties pertaining to Incident response.
2. Indicate when to use the plan.
a. Define Significant Incident.
b. Define Routine Incident.
3. Assign to a role the responsibilities of entering information into SIREN.
4. Create an Information Security Incident Communication Plan and identify how and when to
use the plan. This will also address privacy Incidents.
5. Determine if Counsel should lead the investigation and Incident response. This review and
determination should occur at an early stage of the Incident response process and be
reviewed when new pertinent information arises.
6. Determine Location procedures for Incident handling (run-books, playbooks, etc.).
a. Determine how to gather evidence for detection and analysis.
i. Collect and review initial Incident logs and information.
b. Conduct Incident prioritization.
i. In the absence of accurate inventory and based on the risk associated with
the event, the LLA and IRTC must treat the event as a Significant Incident
during the initial triage.
c. Document the Incident.
i. Use the Location reporting tool(s) (e.g., ServiceNow).
ii. Evaluate the initial information about the Incident using the Incident
classification criteria.
iii. Incident characteristics:
1. Impact to Protection Level and Availability Level.
58
2. Number of records affected.
iv. Open a case in SIREN as needed for Significant Incidents.
v. Create other supporting documentation, which can include:
1. Meeting minutes.
2. Communication record.
3. Decisions log.
57
https://security.ucop.edu/files/documents/policies/incident-response-standard.pdf
58
https://security.ucop.edu/policies/institutional-information-and-it-resource-classification.html
d. Include procedures for containment, eradication and recovery.
i. Identify and engage relevant expertise.
ii. Implement a containment strategy.
iii. Properly gather, handle and preserve evidence.
iv. Eradicate/remove the unauthorized tools used and the vulnerabilities
present during the Incident.
v. Recovery.
e. Conduct forensic analysis.
i. Identify when to engage with forensic vendors/services.
f. Determine when to engage the UC Security Incident Response Coordination (SIRC).
g. Indicate when to engage supporting ISACs (e.g., National Health, Research and
Education, Multi-State, etc.).
h. Explain when to engage with law enforcement.
i. UCPD.
ii. External law enforcement agencies.
iii. Coordinate California Department of Justice, California Highway Patrol, other
states’ law enforcement, FBI or other federal law enforcement engagement
with UCOP’s Systemwide CISO’s office, c3@ucop.edu.
i. Identify when to engage research sponsors and/or partners.
j. Determine when to notify affected individuals and/or regulatory agencies.
k. Develop a process to identify and comply with short notification deadlines (e.g.,
evolving state regulations, the 72-hour deadline to notify regulators as required by
the General Data Protection Regulation (GDPR), the duty to notify certain federal
contracting parties within one hour of discovery, the duty to notify payment card
processors or merchant banks of certain payment card incidents within 24 hours,
etc.).
7. Note how and when to account for special circumstances, such as:
a. In the case of a suspected insider threat and/or when a particular Incident Response
Team member is a person of interest, the Incident Response Coordinator, LLA or CRE
will remove that person from the Incident Response Team.
b. At the determination of the LLA, some individuals or teams may not lead
investigations within their own areas of responsibility in order to avoid possible
conflicts of interest.
8. Establish the process for coordination with:
a. Location Counsel.
b. UCOP’s Cyber-risk Coordination Center (C3).
c. UCOP’s Office of General Counsel (OGC).
9. Develop a plan for post-Incident activity.
a. Evaluate lessons learned.
b. Report findings.
c. Conduct Incident follow-up.
d. Take required technical actions.
e. Review procedures and team effectiveness.
f. Develop recommendations and next steps.
10. Plan for periodic testing of the Information Security Incident Response Plan.
Appendix J: Secure Software Configuration and
Development
Software Configuration Standards
59
1. General options
a. Enable appropriate security controls
b. Enable auditing to detect malicious actions
c. Configure application as “secure by default”
2. Secure communications protocols
a. Disable unencrypted protocols when encrypted protocols are available
i) Protection Level 3 or higher must be transmitted using secure protocols
b. TLS 1.2 or later must be used for:
i) Credential exchange
ii) Transmission of data at Protection Level 3 or higher
iii) CISO-approved cipher for TSL must be used
c. HTTPS must be forced (no HTTP connections)
d. Certificate authority-signed certificates must be used (e.g. no self-signed certificates)
e. Anonymous connections are only allowed for data at Protection Level 1
3. Default credentials must be removed
4. File and cloud access to files and information must be set to appropriate (e.g. “need to
know”) levels
a. CISO-approved methods for authentication must be used
5. Local and cloud access to administrative consoles must be restricted to intended parties
a. Unique service account credentials must be set for each logical part of the application
b. Re-use of credentials is prohibited
c. Credentials must be encrypted in transit and at-rest
d. Service account use must conform with UC Account and Authentication Management
Standard.
60
e. Supplier remote access must be secured with multifactor authentication and unique
credentials
f. Session time-outs must be set to CISO approved values
6. Separate applications and databases
a. Applications at Protection Level 3 must have separated application and database servers
7. Software version and patching
a. Operating systems and patching must comply with the UC Minimum Security
Standard.
61
b. Other software and patching must comply with the UC Minimum Security Standard.
8. Development and test systems
59
Summarized from https://security.ucop.edu/files/documents/policies/secure-software-configuration-
standard.pdf
60
https://security.ucop.edu/files/documents/policies/account-and-authentication-management-standard.pdf
61
https://security.ucop.edu/files/documents/policies/minimum-security-standard.pdf
a. Separate, secure test and development systems must be configured to protect
production systems, Institutional Information, and credentials appropriately
b. Systems must be placed on approved Location network designed for protection of
Institutional Information and IT Resources
9. Character encoding must be UTF-8 or standard character set which enables full input
validation
10. Applications storing Protection Level 3 or higher must comply with the UC Event Logging
Standard.
62
11. Hardening scripts must be executed for applications and operating systems processing or
storing Protection Level 3 or higher data.
12. Encryption at Rest must be enabled for Institutional Information classified at Protection
Level 3 or higher.
13. Backup and archival
a. Encrypt Protection Level 3 or higher data stored on removable media
b. Meets record retention schedule.
63
c. Meets business continuity requirements.
64
14. Security agents such as anti-malware, logging, firewalls, intrusion detection, and compliance
tools must be installed as required by the Location ISMP.
15. APIs, interfaces, and data transfers
a. Protection Level 3 or higher data must be secured by authentication and encryption
b. API keys must be managed per the UC Encryption Key and Certificate Management
Standard.
65
Secure Software Development Standards
66
The CA&ES Software Development Lifecycle (SDLC) includes the following security elements:
• Security planning using secure cloud-based infrastructure (Azure
67
) with an Attestation
of Compliance
68
to the latest Payment Card Industry Data Security Standard (PCI DSS)
• Threat modeling via tabletop exercise from SANS trained IT Workforce Members
• Design incorporates security and privacy guards
• Secure system architecture using web-application firewalls (CloudFlare
69
), secured cloud
services (Azure), secured authentication (CAS
70
or AzureAD
71
), systems and exception
reporting (Stackify
72
), and secure database and file access (SQLAzure or Azure blob
storage)
62
https://security.ucop.edu/files/documents/policies/event-logging-standard.pdf
63
https://recordsretention.ucop.edu
64
https://policy.ucop.edu/doc/7020451/BFB-IS-12
65
https://security.ucop.edu/files/documents/policies/encryption-key-and-certificate-management-standard.pdf
66
Adapted from https://security.ucop.edu/files/documents/policies/secure-software-development-standard.pdf
67
http://azure.microsoft.com/en-us/
68
https://www.microsoft.com/en-us/TrustCenter/Compliance/default.aspx
69
https://www.cloudflare.com
70
https://cas.ucdavis.edu
71
https://azure.microsoft.com/en-us/services/active-directory/
72
https://stackify.com
• Documentation on GitHub project pages
73
• Change management using GitFlow
74
workflow, GitHub issues
75
, and/or ServiceNow
76
• Testing using xUnit.net
77
• Automated software deployment using Octopus Deploy
78
and/or Azure Kudu
79
• Separate roles of Project Manager, Enterprise Software Architect, Security Developer,
Unit Test Developer, Database Developer, and User Interface Designer
The CA&ES standard is that a software fix should be able to be planned, tested, documented,
and deployed in a repeatable fashion as quickly as business needs dictate. Software must be
easily patchable to continue to meet business needs and security requirements. The following
items correspond to §4.1-10 in the UC Secure Software Development Standard.
1. Software Development Process
a. Code Reviews are conducted regularly by the CA&ES Enterprise Software
Architect, Scott Kirkland.
b. Security reviews conducted by the CA&ES Security Developer, who maintains a
GIAC Certified Web Application Defender (GWEB) credential.
c. Code commits are done in GitHub, with automated xUnit testing (written and
maintained by the CA&ES Unit Test Developer, Jason Sylvestre) run by
AppVeyor.
80
d. Secure, automated code testing/checking is pending replacement of the campus
AppScan
81
service.
2. Input Validation
a. Performed on all user-facing fields via various libraries to sanitize, protect
against buffer overflow, array index, or parameter manipulation.
b. SQL queries are not directly exposed in the application, Object Relational
Mapping
82
libraries such as Entity Framework
83
are used instead. This guards
against a wide range of SQL attacks. Custom queries against Location databases
are developed by the CA&ES Database Developer, Ken Taylor.
c. .NET MVC
84
is used to rationalize application URLs, preventing credentials, access
tokens, PII, or PHI in URIs.
3. Exception and Error Handling
a. Stackify is used to record exceptions and error handling.
73
https://help.github.com/articles/user-organization-and-project-pages/
74
https://datasift.github.io/gitflow/IntroducingGitFlow.html
75
https://guides.github.com/features/issues/
76
https://ucdavisit.service-now.com/
77
https://xunit.github.io
78
https://octopus.com
79
https://github.com/projectkudu/kudu/wiki/Process-Threads-list-and-minidump-gcdump-diagsession
80
https://www.appveyor.com
81
https://itcatalog.ucdavis.edu/service/application-security-consulting
82
https://en.wikipedia.org/wiki/Object-relational_mapping
83
https://docs.microsoft.com/en-us/ef/ef6/index
84
https://www.asp.net/mvc
b. Try-catch and/or exception handling is used throughout the applications on the
front-end (Javascript
85
) and back-end (C#
86
or NodeJS
87
).
4. Cross Site Scripting
a. HTML Encoding
88
is used to guard against Cross-Site Scripting attacks.
b. CSRF tokens
89
used to guard against Cross-Site Request Forgery.
5. Insecure Direct Object References
a. Are not used.
6. Logging
a. Stackify is used to log application events and exceptions.
7. TLS and Secure APIs
a. HTTPS is enforced on both Azure and CloudFlare.
b. HTTP is disabled on both Azure and CloudFlare.
c. TLS 1.2 is enabled on Azure.
d. APIs are encrypted with separate cryptographic keys.
e. Authentication is performed via CAS using its APIs.
90
8. Credentials/Passphrases
a. Passphrases are randomly generated and stored securely encrypted in
1Password for Teams.
b. Credential lockout policies are enforced via CAS.
c. Credential protocol exchange is mediated via CAS.
9. Session and Logout
a. Session timeouts are enforced via CAS.
b. Session tokens are generated securely via CAS.
c. Session tokens are deleted and newly created via CAS.
d. Session tokens are invalidated on logout via CAS.
e. CAS uses TLS 1.2.
f. CAS performs logout and prominently displays a logout screen.
g. Application state is committed or rolled back by the ORM on logout.
10. Federated Authentication/SAML/Shibboleth
a. Campus CAS, Shibboleth, and/or AzureAD is used for authentication.
11. File Management
a. File resources in Azure use random GUID.
12. Secure Configuration
a. Configuration of applications follow the Software Configuration Standards.
13. Documentation
a. Code documentation and procedures will be maintained in the UC Davis
GitHub
91
and ServiceNow instances.
85
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/try...catch
86
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/try-catch
87
https://nodejs.org/en/
88
https://docs.microsoft.com/en-us/dotnet/api/system.web.mvc.htmlhelper.encode?view=aspnet-mvc-5.2
89
https://docs.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-2.2
90
https://apereo.github.io/cas/5.1.x/protocol/CAS-Protocol-Specification.html
91
https://github.com/ucdavis
14. Version Control
a. Software is developed in the UC Davis GitHub instance.
b. Test and Production systems are in separate Azure instances.
c. GitFlow process is used to track development, test, and production versions
d. GitHub pull requests
92
are used to track changes and GitHub repository
permissions
93
are used to prevent unauthorized merges.
92
https://help.github.com/articles/about-pull-requests/
93
https://help.github.com/articles/repository-permission-levels-for-an-organization/