I nf or ma tion S e c ur ity P olicy M anual Policies, Standards, and Procedures October 2012
About the October 2012 Revision This revision addresses the following: 1. Throughout the manual, updates references to the Acceptable Use Statement, DMV 350 (Rev 6/2012), adds an image of the form, references and associated procedures. 2. Changes obsolete Protecting the Information on DMV Computers (DMV 166) references to ISO’s self-published Protecting DMV Information and Information Assets booklet. This booklet can be found on the DMVWeb or contact
[email protected]. 3. Incorporates the draft Security Information and Event Management (SIEM) policy and associated standards and procedures. 4. Adds an image of the E-Mail Monitoring Form and associated procedures. 5. Changes State Administrative Manual (SAM) links from html to aspx.
Annual Update In compliance with the Payment Card Industry Data Security Standard (PCI-DSS) Version 2.0, requirement 12.1.3, this manual will be reviewed at least annually and updated when the environment changes.
Printing This manual was created for two sided printing with major headings beginning on an odd page to allow insertion of tabbed dividers. If printed on one side, blank pages will occur to maintain pagination.
Comments Please contact the Information Security Office at
[email protected] with any questions, comments, corrections, or suggestions.
Table of Contents Introduction ........................................................................... 1 Preface ................................................................................................. 1 Introduction.......................................................................................... 1 Policy Objective .................................................................................... 1 Individual Responsibility ....................................................................... 2 Management Responsibility ................................................................. 2 About this Manual ................................................................................ 2 Security Control Classes, Families, and Identifiers .................................................. 3
Management.......................................................................... 5 Program Management ......................................................................... 5 PM-1 Information Security Program Plan ............................................................... 5
Information Security Program ............................................................................ 5 PM-2 Senior Information Security Officer ............................................................... 8
Information Security Officer ............................................................................... 9 PM-3 Information Security Resources.................................................................... 11
Data Resource Managers .................................................................................. 12 PM-4 Plan of Action and Milestones Process ........................................................ 15 PM-5 Information System Inventory ...................................................................... 16
Desktop Computer Policy ................................................................................. 16 PM-6 Information Security Measures of Performance ........................................ 18 PM-7 Enterprise Architecture .................................................................................. 18 PM-9 Risk Management Strategy ........................................................................... 19 PM-10 Security Authorization Process ................................................................... 20
Information Controls......................................................................................... 20
Table of Contents
Page i
Planning ............................................................................................. 21 PL-1 Security Planning Policy and Procedures ...................................................... 21
Information Protection Standards Policy ......................................................... 21 PL-2 System Security Plan........................................................................................ 22 PL-4 Rules of Behavior ............................................................................................. 23
Responsible Computing .................................................................................... 23 Acceptable Use ................................................................................................. 25 Electronic Mail .................................................................................................. 28
Risk Assessment ................................................................................. 37 RA-1 Risk Assessment Policy and Procedures ....................................................... 37 RA-2 Security Categorization .................................................................................. 38
Classifying and Handling Information ............................................................... 38 RA-3 Risk Assessment .............................................................................................. 46 RA-5 Vulnerability Scanning.................................................................................... 46
System and Services Acquisition ......................................................... 47 SA-1 System and Services Acquisition Policy and Procedures ............................ 47 SA-2 Allocation of Resources .................................................................................. 47 SA-3 Life Cycle Support............................................................................................ 48 SA-4 Acquisition Process ......................................................................................... 49 SA-5 Information System Documentation............................................................. 49 SA-6 Software Usage Restrictions .......................................................................... 50 SA-7 User-Installed Software .................................................................................. 51 SA-8 Security Engineering Principles ..................................................................... 52
Design and Utilization of Reliable Systems ....................................................... 52 SA-11 Developer Security Testing .......................................................................... 53
Application Security and Secure Coding Policy ................................................ 53 Application Testing ........................................................................................... 55 SA-17 Developer Security Architecture Design ..................................................... 56
Page ii
Table of Contents
Operational .......................................................................... 57 Awareness and Training ..................................................................... 57 AT-1 Security Awareness and Training Policy and Procedures ........................... 57
Information Security Awareness and Training ................................................. 57 AT-2 Security Awareness ......................................................................................... 59 AT-3 Security Training ............................................................................................. 59
Configuration Management ............................................................... 61 CM-1 Configuration Management Policy and Procedures .................................. 61 CM-2 Baseline Configuration .................................................................................. 61 CM-3 Configuration Change Control...................................................................... 63 CM-5 Access Restrictions for Change ..................................................................... 63 CM-6 Configuration Settings................................................................................... 63 CM-8 Information System Component Inventory ................................................ 64
Contingency Planning ......................................................................... 65 CP-2 Contingency Plan ............................................................................................. 65 CP-8 Telecommunications Services ........................................................................ 65 CP-10 Information System Recovery and Reconstitution .................................... 66
Disaster Recovery Plan ...................................................................................... 66
Identification and Authorization ......................................................... 69 IA-2 Identification and Authorization (Organizational Users) ............................ 69 IA-4 Identifier Management .................................................................................... 69 IA-5 Authenticator Management ............................................................................ 70 IA-7 Cryptographic Module Authentication .......................................................... 70 IA-8 Identification and Authorization (Non-Organizational Users) ................... 70
Incident Response............................................................................... 71 IR-1 Incident Response Policy and Procedures ..................................................... 71
Information Security Incident Reporting and Follow Up .................................. 71 IR-4 Incident Handling ............................................................................................. 74 IR-5 Incident Monitoring ......................................................................................... 75 IR-6 Incident Reporting............................................................................................ 75
Notification of Security Breach Involving Personal Information ...................... 75 Table of Contents
Page iii
Maintenance ...................................................................................... 79 MA-1 System Maintenance Policy and Procedures .............................................. 79 MA-2 Controlled Maintenance ................................................................................ 80
Effective Management of Data Processing and Information Technology Infrastructure .................................................................................................... 80 MA-3 Maintenance Tools ......................................................................................... 82
Media Protection ................................................................................ 83 MP-1 Media Protection Policy and Procedures .................................................... 83 MP-6 Media Sanitization.......................................................................................... 83
Personnel Security .............................................................................. 85 Physical and Environmental Protection .............................................. 87 PE-1 Physical and Environmental Protection Policy and Procedures ................. 87
Physical Security of Information Assets ............................................................ 87 PE-2 Physical Access Authorizations ...................................................................... 89 PE-3 Physical Access Control ................................................................................... 90
Security of Desktop and Mobile Computers and Related Materials and Equipment ......................................................................................................... 90 Desktop and Mobile Computer Security .......................................................... 91 PE-6 Monitoring Physical Access ............................................................................ 93
Access to DMV Work Areas .............................................................................. 93 PE-9 Power Equipment and Power Cabling ........................................................... 94
System and Information Integrity ....................................................... 95 SI-1 System and Information Integrity Policy and Procedures ........................... 95
Accountability for the Source of Information, Updates and Changes ............. 95 SI-3 Malicious Code Protection ............................................................................... 98 SI-4 Information System Monitoring ..................................................................... 98 SI-7 Software and Information Integrity ............................................................... 98 SI-12 Information Output Handling and Retention ............................................. 99
Data Transfer .................................................................................................... 99
Page iv
Table of Contents
Technical ............................................................................ 105 Access Control .................................................................................. 105 AC-1 Access Control Policy and Procedures ........................................................ 105
Access Control Administration ....................................................................... 105 AC-2 Account Management .................................................................................. 115 AC-4 Information Flow Enforcement....................................................................116
Information Access ......................................................................................... 116 AC-5 Separation of Duties ..................................................................................... 118 AC-17 Remote Access ............................................................................................. 118 AC-18 Wireless Access ............................................................................................ 123 AC-19 Access Control for Mobile Devices ............................................................ 124
Mobile Devices ................................................................................................ 124 AC-20 Use of External Information Systems ....................................................... 129
Off-Shift Processing ......................................................................................... 129 Internet Resource Use .................................................................................... 130 AC-22 Publicly Accessible Content .......................................................................133
Audit and Accountability .................................................................. 134 AU-1 Audit and Accountability Policy and Procedures ......................................134
Automated Update and Change Requirements ............................................. 134 Transaction Auditability .................................................................................. 136 AU-3 Content of Audit Records ............................................................................137 AU-6 Audit Review, Analysis, and Reporting ...................................................... 138
Security Information and Event Management ............................................... 138
Security Assessment and Authorization ............................................ 153 CA-2 Security Assessments .................................................................................... 153 CA-3 Information System Connections ................................................................ 153 CA-6 Security Authorization .................................................................................. 153
Table of Contents
Page v
System and Communications Protection .......................................... 155 SC-1 System and Communications Protection Policy and Procedures ............155
Confidentiality Requirements ......................................................................... 155 Confidential or Sensitive Information on Desktop or Mobile Computers ..... 157 Network Security ............................................................................................ 158 Intranet Security ............................................................................................. 160 SC-7 Boundary .........................................................................................................163
Firewall Security .............................................................................................. 163 SC-12 Cryptographic Key Establishment and Management .............................. 166 SC-13 Use of Cryptography ................................................................................... 167
Encryption ....................................................................................................... 167 SC-17 Public Key Infrastructure Certificates........................................................ 170
DMV Public Key Infrastructure & Certificate Policy ....................................... 170 DMV Public Key Infrastructure & Certificate Policy Procedures .................... 177 SC-18 Mobile Code .................................................................................................193 SC-19 Voice Over Internet Protocol ......................................................................193 SC-20 Secure Name/Address Resolution Service (Authoritative Source) ........193 SC-23 Session Authenticity .................................................................................... 194
Glossary ............................................................................. 195 Acronyms ........................................................................... 205 Commonly Referenced Forms............................................. 206 Policy Exception Request – EXEC 205................................................ 206 Acceptable Use Statement – DMV 350 ............................................. 207 Acceptable Use Statement (DMV 350) Procedures.............................................209 Acceptable Use Statement Embedded References .............................................212
Introduction .................................................................................................... 212 Access .............................................................................................................. 213 Disclosure ........................................................................................................ 214 Use .................................................................................................................. 215 Employee Responsibility ................................................................................. 216 Acceptable Use Statement Cross Reference ........................................................ 218 Page vi
Table of Contents
E-mail Monitoring Request Form and Procedure .............................. 221
PCI-DSS Requirements & Security Assessment Procedures Matrix ................................................................................ 223 Applicable Statutes ............................................................ 227 California Penal Code Section 502 .................................................... 227 Information Policies Act ................................................................... 227 Federal ............................................................................................. 227 Government Code............................................................................. 227 Other ................................................................................................ 228
Table of Contents
Page vii
Introduction Preface The Department of Motor Vehicles (DMV) is responsible for the administration of statewide programs that use and rely on electronically stored and hard copy Information Assets. The DMV and its customers query and update information in these records through transactions that result in the collection of billions of dollars each year. A superstructure of laws, regulations, administrative requirements, and good business practices determines how this information may be used and how it must be protected. A primary responsibility of the Department is to ensure Information Assets are available to Government and Industry Partners in addition to DMV employees for job completion, and proper levels of security are used to protect the information's confidentiality, integrity and accessibility. Consistent with the objective of the Department to use technology to support business strategies, and the focus of DMV’s Strategic Plan and the Information Technology Strategic Plan, DMV's Information Security Program contains policies that support the information security needs of the Department's operations. Responsibility for managing the Information Security Program is assigned by the Director of the Department of Motor Vehicles to the Chief Information Security Officer. The program emphasizes a sharing of the management of information security issues between departmental management and the Chief Information Security Officer. This manual contains the policies and Department - wide procedures that integrate the Information Security Program into DMV operations. Questions concerning the use or interpretation of information contained in the manual should be addressed to the Information Security Office, Executive, Mail Station F116, or by phone at (916) 657-5830.
Introduction At the Department of Motor Vehicles, the Information Security Program applies to all systems, automated and manual, for which the Director has responsibility. The program includes the policies, procedures, guidelines, and safeguards that assure information is available when and where it is needed, protects the integrity of the Department's Information Assets, ensures confidentiality, maintains the privacy rights of individuals, and controls the release of information to authorized persons. This Information Security Policy Manual contains the policies and practices of the program. The manual is used by staff to identify, understand, and discharge their information security related responsibilities.
Policy Objective The Information Security policies and associated standards, procedures and controls define how DMV provides the appropriate level of security required by law or administrative regulation to protect DMV Information Assets from unauthorized use or disclosure; to protect individuals employed by the state who are authorized to access confidential, sensitive or personal information from temptation, coercion, and threat; and to ensure the continued availability of DMV's systems and Information Assets. October 2012
Page - 1 -
Individual Responsibility At the Department of Motor Vehicles, Information Assets are given the protection appropriate to ensure the level of confidentiality, availability, and integrity required to carry out the Department's mission. The protection of DMV’s Information Assets is a basic responsibility of all individuals who access DMV information.
Management Responsibility DMV management ensures that employees have been informed of their obligation to protect DMV Information Assets. Management must identify and protect Information Assets within their assigned area, and implement security practices and measures that are consistent with those discussed in this manual. Finally, management is responsible for noting variances from established security policy and procedures and for initiating required corrective actions.
About this Manual In accordance with the State Administrative Manual (SAM) Section 5100, “State agencies must use the American National Standards Institute (ANSI) and the Federal Information Processing Standards (FIPS) standards in their information management planning and operations.” To that end, this manual is organized around the security controls listed in the National Institute of Standards and Technology (NIST) Special Publication 800-53: Recommended Security Controls for Federal Information Systems and Organizations, specifically the following appendices: Appendix F – Security Control Catalog Appendix G – Information Security Programs. (Refer to the table on the following page for an overview of the classes, families, and identifiers of the security controls.) DMV Information Security policies are included in this manual in their entirety. Other related policies may only be referenced under the IT Policy, Standards, Instructions and Guidelines heading. IT Policy, Standards, Instructions and Guidelines IT Policy, Standards, Instructions and Guidelines provide a significant level of guidance for DMV with respect to how to implement a security control. Therefore, the following are referenced with the most closely related security control: 1. Other applicable DMV policies, e.g., Administrative Policy Manual (APM) 2. State Administrative Manual (SAM) sections: Chapter 4800 - California Technology Agency Chapter 5300 - Information Security (Office of Information Security), 3. Information Technology Policy Letters (ITPL) 4. Statewide Information Management Manual (SIMM) 5. National Institute of Standards and Technology (NIST) publications (i.e., Federal Information Processing Standards (FIPS) or Special Publications (800 Series)).
Page - 2 -
October 2012
Security Control Classes, Families, and Identifiers As stated in NIST Special Publication 800-53, security controls are organized into eighteen families. Each security control family contains security controls related to the security functionality of the family. In addition, there are three general classes of security controls: management, operational, and technical. The table below summarizes the classes and families in the security control catalog and the associated security control family identifiers. CLASS
FAMILY
IDENTIFIER
MANAGEMENT
Program Management
PM
MANAGEMENT
Planning
PL
MANAGEMENT
Risk Assessment
RA
MANAGEMENT
Security Assessment and Authorization
CA*
MANAGEMENT
System and Services Acquisition
SA
OPERATIONAL
Awareness and Training
AT
OPERATIONAL
Configuration Management
CM
OPERATIONAL
Contingency Planning
CP
OPERATIONAL
Incident Response
IR
OPERATIONAL
Maintenance
MA
OPERATIONAL
Media Protection
MP
OPERATIONAL
Personnel Security
PS*
OPERATIONAL
Physical and Environmental Protection
PE
OPERATIONAL
System and Information Integrity
SI
TECHNICAL
Access Control
AC
TECHNICAL
Audit and Accountability
AU
TECHNICAL
Identification and Authentication
IA
TECHNICAL
System and Communications Protection
SC
*SP 800-53 Security Controls not currently addressed in writing by the Department or at the state level are not referenced in this manual. Therefore, gaps may appear in the numbering sequence.
October 2012
Page - 3 -
Page - 4 -
October 2012
Management Program Management PM-1 Information Security Program Plan
Information Technology Policy Information Security Program Policy # Revised: Issue Date: Owner: Purpose:
IS 2012-05 Unknown Information Security Office
SAM SIMM: Supersedes:
5300.3 Policy 1
The purpose of this policy is to describe the scope of the Information Security Program. Government Code Section 11546.1 requires the Director to designate a Chief Information Security Officer to oversee this program. As manager of this program, the Chief Information Security Officer shall: 1. Ensure the safety and security of documents, files, records, off-site backup files, and disaster recovery plans. The disaster recovery plans define the strategy for continuing departmental operations during and subsequent to a disaster. 2. Require the preparation of an inventory of all confidential, sensitive, and personal data in the Department. 3. Perform risk analyses of current or planned DMV systems and Information Assets. 4. Ensure adequate safeguards are installed and implemented to protect confidential, sensitive, and proprietary data. 5. Prepare, review, and coordinate Department wide, division, and section/unit procedure changes to accommodate new or changed security policies. 6. Coordinate security and disaster recovery training. 7. Prepare and distribute information security incident reports. 8. Oversee the development and implementation of and conduct security awareness training. 9. Ensure the use of standardized audit logs for all financial, sensitive, and confidential record transactions.
October 2012
Page - 5 -
Background/History:
A successful information security program requires a firm commitment from all members of the DMV management team. Executive management acknowledges this commitment and provides the resources necessary to protect the Department's Information Assets. DMV's Information Security Policy Manual provides the foundation for developing a clear and uniform understanding of the Department's security objectives, the basis for protection of Information Assets and facilities, and the organizational structure through which this program is managed.
Persons Impacted: Policy:
All DMV employees, contract staff and Government and Industry Partners. The Department of Motor Vehicles will implement and maintain an effective Information Security Program. The Director will designate an Chief Information Security Officer to manage the program. The program defines the information security related roles and responsibilities of individuals and Government and Industry Partners using DMV Information Assets. This information is published in an Information Security Policy Manual for distribution to staff.
Procedures:
Procedures related to this policy statement are the responsibility of the Information Security Office.
Roles and Responsibilities:
Information Security Office: Publish and maintain the Information Security Policy Manual. Employees, Contract Staff and Government and Industry Partners: Understand and apply the information and instructions in the Information Security Policy Manual.
Definitions:
Government and Industry Partners The term used in this document for external personnel who access the DMV systems performing transactions (including inquiries) for their employer or for DMV.
Authority/References:
Government Code Section 11546.1 State Administrative Manual (SAM) Section 5300.3
Related Information:
Template update: Not applicable or not available.
IT Policy, Standards, Instructions and Guidelines References ITPL 11-04 Changing References from Predecessor Organizations to the California Technology Agency SIMM 70
IT Security Certifications
SAM 4800
State Information Management Principles
Page - 6 -
October 2012
SAM 4810
Statutory Provisions
SAM 4819.31 Basic Policy SAM 4819.32 Exclusions SAM 5300
Introduction
SAM 5300.1 Statutory Provisions SAM 5300.2 Applicability SAM 5300.3 Agency Responsibilities SAM 5315
Organizing Information Security
SAM 5315.1 Agency Management Responsibilities SAM 5315.2 Agency Designations SAM 5335
Communications and Operations Management
SP 800-100
Information Security Handbook: A Guide for Managers
October 2012
Page - 7 -
PM-2 Senior Information Security Officer The DMV's Chief Information Security Officer (CISO) has overall responsibility for ensuring the implementation, enhancement, monitoring, and enforcement of the Information Security Program. The CISO enables agency compliance with the Information Security Program through the development of policies and procedures that promote information security awareness and establish necessary safeguards. The Chief Information Security Officer reports information security incidents, represents the DMV in all information security matters and coordinates and directs security program activities and reporting processes.
Page - 8 -
October 2012
Information Technology Policy Information Security Officer Policy # Revised: Issue Date: Owner:
IS 2012-27 11/19/1999 Information Security Office
SAM SIMM: Supersedes:
5300.3 APM 6.010
Purpose:
Template update: Not applicable or not available.
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
Template update: Not applicable or not available.
Policy:
It is the policy of this Department that the Chief Information Security Officer (CISO) shall carry out the duties and responsibilities required by SAM Section 5300.3.
Procedures:
Template update: Not applicable or not available.
Roles and Responsibilities:
The CISO shall: 1. Promulgate applicable regulations, policies, and procedures for the continuous and effective management, control, and disposal of information and information resources necessary for carrying out departmental functions; 2. Ensure the safety and security of such information resources, including offsite storage and recovery plans necessary for the continuance of essential departmental operations during and subsequent to a disaster; 3. Require: periodic inventory of confidential, sensitive and proprietary data; risk analyses (new and changed risks) of confidential data and other information resources; and periodic assessment of safeguards installed and implemented and their adequacy.
October 2012
Page - 9 -
Roles and Responsibilities: (continued)
4. Identify staff members within the Department who are authorized to use, handle, access, retrieve, change, modify, delete, or erase information, data, records, and files. Make known to them their responsibilities to employ established and approved safeguards and controls; 5. Require appropriate and effective security training of DMV personnel; 6. Prepare periodic reports to Department management, and other agencies as required; 7. Assist Department management in carrying out their information security responsibilities; 8. Attend appropriate training courses recommended for the continued development of information security skills, practices, and management techniques; and 9. Review all internal information security actions and activities and report violations of approved rules, regulations, policies, procedures, and laws to Department management for corrective action.
Definitions:
Template update: Not applicable or not available.
Authority/References:
State Administrative Manual Section 5300.3
Related Information:
Template update: Not applicable or not available.
Page - 10 -
October 2012
PM-3 Information Security Resources Division and Program Management Division Chiefs and Program Managers will actively support the Information Security Program through the following: Aggressively following up on information security and privacy incidents occurring in their area of responsibility; Promptly addressing variances from security policies and procedures within their area of control; Initiating appropriate and consistent corrective action; Protecting Information Assets in their area of control; Implementing security practices and procedures in accordance with established policy and consistent with the criticality, classification, and value of the Information Asset; and Ensuring that personnel under their supervision understand and fulfill their obligation to protect organizational assets.
October 2012
Page - 11 -
Information Technology Policy Data Resource Managers Policy #: Revised: Issue Date: Owner:
IS 2012-04 04/2012 Unknown Information Security Office
SAM SIMM Supersedes:
5320.1, 5320.2 Policy 3, APM 6.020
Purpose:
The purpose of this policy is to provide the means for establishing Data Resource Managers (DRMs) and clarifying their roles and responsibilities. Each designated DRM is the individual representative of management responsible for making and communicating judgments and decisions on behalf of the Department regarding the use, identification, and protection of the specified data resource.
Background/History:
Government Code Section 11019.9 requires state agencies to enact and maintain a permanent privacy policy in adherence with the Information Practices Act of 1977 (Title 1.8 (commencing with Section 1798) of Part 4 of Division 3 of the Civil Code). The privacy policy shall include the purposes for which personally identifiable information (PII) is collected and the general means by which PII is protected. This revision specifies which roles within the Department are generally responsible for the provisions within Government Code Section 11019.9. This revision also updates the Roles and Responsibilities to mirror actual practice.
Persons Impacted:
The Information Privacy Office (IPO), the Information Security Office (ISO), the Audits Office, and persons assigned to fulfill the DRM role.
Policy:
A DRM will be designated for each automated database or file required to accomplish the DMV mission. DRM assignments will be at the Program Manager level, or at the section manager level in organizations without Program Managers.
Page - 12 -
October 2012
Procedures:
The Data Resource Manager (DRM) Handbook identifies the specific Information Assets under the purview of the DRM, classification of the information, the purposes for which personal information is collected, decisions that affect the data resource users and custodians, and related security information necessary to carry out the DRM responsibilities. A copy of the completed handbook will be forwarded to the ISO for coordination and filing. The ISO will provide copies to the custodians to ensure they have current information about DRMs, their decisions and responsibilities. The Data Resource Manager (DRM) Listing identifies the databases required to meet the Department's mission and their respective DRMs.
Roles and Responsibilities:
Deputy Director of impacted Business Function: The Deputy Director will designate the DRM and provide written notification to the ISO. Data Resource Managers Council: To facilitate communication, education, and consistent resolution of departmental issues, the DRMs will participate in a Data Resource Managers Council (DRMC). This group will meet periodically to address items of common interest and issues raised by the data resource managers, users and custodians. ISO: (a) Schedule and facilitate the DRMC. (b) Inventory and update the DRM Handbook. (c) Document the general means by which personal data is protected. The IPO will insure that the personal data collected is relevant to the purpose for which it is needed. The Audits Office will ensure that the subsequent use of the data is limited to those purposes previously specified.
October 2012
Page - 13 -
DRM: Each DRM will complete a DRM Handbook for each database they are designated as owner and update annually thereafter.
Roles and Responsibilities (continued):
In addition, as the information owner, DRMs are responsible for the following functions related to their databases: 1. Identification of the database or file; 2. Classification of the information stored in the database or file; 3. Document the purposes for which personally identifiable data are collected; 4. Authorization for access to the information in the database or file; 5. Assignment of custody of the database or file; 6. Approval of new or modified applications affecting or processing the database or file; 7. Approval of contingency plans affecting the database or file; 8. Participation in making decisions regarding risk management of the data; 9. Monitoring of procedure compliance; and 10. Follow-up of security violations. Definitions:
Template update: Not applicable or not available.
Authority/References:
SAM Sections 5320.1, 5320.2 Government Code Section 11019.9
Related Information:
Data Resource Manager (DRM) Listing Classifying and Handling Information
IT Policy, Standards, Instructions and Guidelines References APM Chapter 6.102 Chief Privacy Officer SAM 4903.1 Information Management Organizations SP 800-87 Rev. 1
Page - 14 -
Codes for Identification of Federal and Federally-Assisted Organizations
October 2012
PM-4 Plan of Action and Milestones Process IT Policy, Standards, Instructions and Guidelines References SAM 4900 Purpose SAM 4900.1 Definitions SAM 4900.2 Basic Policies SAM 5320.3 Responsibility of Custodians of Information SIMM 05
Reporting Schedules
05A Required IT Reports and Activities
October 2012
Page - 15 -
PM-5 Information System Inventory
Information Technology Policy Desktop Computer Policy Policy # Revised: Issue Date: Owner:
IS 2012-29 3/2003 Information Security Office
SAM SIMM: Supersedes:
4989-4989.8 APM 8.000
Purpose:
Agencies may acquire desktop and mobile computing commodities necessary to support the agency's programmatic functions and business needs. This includes acquiring desktop and mobile computing commodities to support increased staffing, as well as the ongoing replacement of obsolete or nonfunctioning desktop and mobile computing commodities.
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
Employees issued a computer workstation (desktop) or laptop in accordance with their job duties.
Policy:
It is the policy of this Department to provide each employee with the desktop computing resources appropriate to the job performed. This may include access to DMV’s intranet (DMVWeb) and the internal to DMV or external network based or connected resources required by each individual’s job. The desktop requirements will be defined by division management and provided by Information Systems Division (ISD) in such a manner that the resources committed to any individual will not adversely impact the resources availability needed by others to do their work. The objectives of this policy include: 1. Protecting the Department's investment in information systems and reducing the risks associated with decentralization of systems; 2. Ensuring that the establishment of locally hosted desktop computer-accessible databases does not involve loss of data integrity or security; 3. Establishing an efficient process for the justification and acquisition of desktop and portable computers;
Page - 16 -
October 2012
Policy (continued):
4. Providing compatibility of hardware and of software within the Department to facilitate integration of systems, to simplify user training, and to lower acquisition and administration costs; 5. Being responsive to the needs of management and all DMV users; 6. Encouraging the use of available software packages rather than the custom development of programs within the Department; and 7. Creating a support structure that provides reliable technical assistance to users of personal computers and coordinates user training and systems administration and maintenance.
Procedures:
Desktop/Mobile Computing (DMC) Policy
Roles and Responsibilities:
Refer to the Desktop/Mobile Computing Policy
Definitions:
Refer to the Desktop/Mobile Computing Policy
Authority/References:
SAM Sections 4989-4989.8
Related Information:
Desktop/Laptop Operating Systems Policy Desktop/Laptop Operating Systems Procedures Desktop Standards Committee
IT Policy, Standards, Instructions and Guidelines References APM Chapter 6.300 Equipment Inventory Control SAM MM 11-03 Rev. 1 Reduction of Cell Phones, Smart Phones, and Cell Devices Pursuant to Executive Order B-1-11 and the removal of Confidential, Sensitive or Personal Information SAM 5335
October 2012
Communications and Operations Management
Page - 17 -
PM-6 Information Security Measures of Performance IT Policy, Standards, Instructions and Guidelines References SAM 5310 Policy, Standards, and Procedure Management
PM-7 Enterprise Architecture IT Policy, Standards, Instructions and Guidelines References 2000-01 DMV Architecture Standards Policy ITPL
10-15 Enterprise Architecture Standards and Procedures
ITPL
09-03 Establishment of a Statewide Enterprise Architecture and the Associated Policy and Process
SAM 4906
Enterprise Architecture
SIMM 58
Statewide Enterprise Architecture
A Enterprise Architecture Developers Guide B The Enterprise Architecture Governance Process C Enterprise Architecture Glossary D Enterprise Architecture Standards
SIMM 158
Technical Reference Model Service Component Reference Model Enterprise Architecture Practices
A Technical Reference Model Practice B Service Component Reference Model Practices
Page - 18 -
October 2012
PM-9 Risk Management Strategy IT Policy, Standards, Instructions and Guidelines References SP 800-39 Managing Information Security Risk: Organization, Mission, and Information System View
October 2012
Page - 19 -
PM-10 Security Authorization Process
Information Technology Policy Information Controls Policy # Revised: Issue Date: Owner:
IS 2012-26 11/19/1999 Information Security Office
SAM SIMM: Supersedes:
APM 6.000
Purpose:
Template update: Not applicable or not available.
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
Template update: Not applicable or not available.
Policy:
It is the policy of this Department to protect information resources to ensure their confidentiality, integrity, and availability is assured for DMV, its partners, and customers. The Director shall designate a Chief Information Security Officer to carry out this responsibility as required by Government Code Section 11546.1. Template update: Not applicable or not available.
Procedures: Roles and Responsibilities:
Template update: Not applicable or not available.
Definitions:
Template update: Not applicable or not available.
Authority/References:
Government Code Section 11546.1
Related Information:
Template update: Not applicable or not available.
Page - 20 -
October 2012
Planning PL-1 Security Planning Policy and Procedures
Information Technology Policy Information Protection Standards Policy Policy # Revised: Issue Date: Owner:
IS 2012-30 12/2008 Information Security Office
SAM SIMM: Supersedes:
APM 8.010
Purpose:
The purpose of this policy is to bring the Department of Motor Vehicles (DMV) into compliance with the State Administrative Manual (SAM) standards.
Background/History:
The SAM provides direction for departments to follow the American National Standards Institute (ANSI) management information standards and the Federal Information Processing Standards (FIPS). The ANSI standards are national consensus standards, which provide guidance on a variety of issues central to the public and industrial sectors. State agencies are directed to use FIPS standards, which fall under National Institute of Standards and Technology (NIST) in their information management planning and operations. The FIPS standards are adopted and promulgated under the provision of Public Law 89– 306 (Brooks Act) and Part 6 of Title 15, Code of Federal Regulations, and serve to improve the utilization and management of computers and automated data processing. All employees and contract staff participating in the Systems Development Lifecycle as well as users of those systems.
Persons Impacted:
October 2012
Page - 21 -
Policy:
The DMV adopts the American National Standards Institute (ANSI) management information standards and the Federal Information Processing Standards (FIPS) and the National Institute of Standards and Technology (NIST) as baseline security standards and best practices to increase the confidentiality, integrity, and availability of DMV Information Assets. DMV must use the ANSI, FIPS, and NIST standards in their information management planning and operations. Adoption of these standards will facilitate the interorganizational sharing and exchange of equipment, data, software and personnel. Use of these standards will also facilitate communication (1) among state agencies; (2) between the state and its IT vendors; and (3) between the state and its IT information providers/recipients.
Procedures:
Template update: Not applicable or not available.
Roles and Responsibilities:
Template update: Not applicable or not available.
Definitions:
Template update: Not applicable or not available.
Authority/References:
State Administration Manual Section 5100 FIPS NIST ANSI Revision History (PDF) Template update: Not applicable or not available.
Related Information:
PL-2 System Security Plan IT Policy, Standards, Instructions and Guidelines References SP 800-18 Rev.1 Guide for Developing Security Plans for Federal Information Systems
Page - 22 -
October 2012
PL-4 Rules of Behavior
Information Technology Policy Responsible Computing Policy # Revised: Issue Date: Owner:
IS 2012-22 Unknown Information Security Office
SAM SIMM: Supersedes:
Policy 21
Purpose:
In support of its mission, the Department of Motor Vehicles provides employees, contractors and customers access to Information Assets. This access is a privilege granted to users by DMV management. The purpose of this policy is to ensure every user is aware of his/her responsibility for the confidentiality, integrity, and accessibility of these resources.
Background/History:
Computing and network resources are owned by the DMV and are to be used for DMV related activities. They are not to be used for commercial purposes or non-DMV related activities without written approval by management.
Persons Impacted:
All users that access, support, or monitor DMV’s Information Assets.
Policy:
All users of DMV computing systems will respect the rights of other computer users, the integrity of the physical and logical controls, and all license and contractual agreements. It is DMV policy that all DMV computer users act in accordance with these responsibilities, relevant laws and contractual obligations, and observe the highest standard of ethics.
Procedures:
The Information Security Office has published a booklet titled Protecting DMV Information and Information Assets for computer users, system administrators, and managers of DMV computing resources. This booklet serves as a guide containing the necessary information users should know to comply with this policy. All the individuals in these groups should read and understand their responsibilities as listed in the booklet. This booklet can be obtained from the Information Security Office.
October 2012
Page - 23 -
Roles and Responsibilities:
Data Resource Manager (DRM): Access to DMV information resources may be granted by the appropriate DRM based on the DRM's judgment of the following factors: relevant laws and contractual obligations, the requester’s business need for the information, the information's sensitivity and/or confidentiality, and the risk of damage to or loss by the Department. DRMs may allow non-DMV users access to information consistent with the guidelines above. Users: DMV computer and network users and system administrators must guard against abuse that disrupt or threaten the viability of all systems, including systems connected to DMV's networks.
Definitions:
Template update: Not applicable or not available.
Authority/References:
Template update: Not applicable or not available.
Related Information:
To ensure the availability and integrity of DMV's computers, networks, and information resources, DMV treats access and use violations seriously. DMV reserves the right to limit, restrict or extend computer, network, and information access to its Information Assets. Access to information resources without proper DRM authorization, corruption or misuse of Information Assets and unauthorized use of DMV's computers or networks are violations of this policy and form the basis for administrative and/or criminal action.
Page - 24 -
October 2012
Information Technology Policy Acceptable Use Policy # Revised: Issue Date: Owner: Purpose:
IS 2012-33 10/4/2007 Information Security Office
SAM SIMM: Supersedes:
APM 8.080
The purpose of this policy is to require full compliance with the departmental policy statement that outlines the acceptable use of information resources at the Department of Motor Vehicles (DMV) and protects users and the DMV. Inappropriate use of resources exposes the Department to risks including virus attacks, compromise of network systems and services, and potential legal liability. The departmental acceptable use statement incorporates the following: Establishes appropriate and acceptable practices regarding the use of information resources. Ensures compliance with applicable state law and other rules and regulations regarding the management of Information Assets. Educates individuals, who use information resources, of their responsibilities associated with information security and computer resource use.
Background/ History: It is common practice for many businesses and educational facilities to require that employees sign an acceptable use statement before being granted access to the network. This departmental policy is being established to continue this business practice and clarify the importance of protecting the information resources at the DMV. In addition, the policy should lessen inquiries and misunderstandings that are generated when the DMV requires the annual policy statement to be signed as part of the ongoing security awareness program. Because the current departmental annual policy statement, Acceptable Use Statement (DMV 350), has been altered and renamed several times in recent years and may be altered and/or renamed again at a future date, this policy does not address the annual policy statement by its specific title. This policy affects all employees, students, vendors, consultants, Persons Impacted: contractors, and others who access the DMV network, the Internet, and/or personal, sensitive, or confidential information at the DMV.
October 2012
Page - 25 -
Policy:
It is the policy of the Department of Motor Vehicles (DMV) that all individuals who have access to information maintained by the DMV understand the policies and procedures regarding information security at the DMV, and must agree in writing to perform their work according to these same policies and procedures. Prior to being granted access to the DMV network and annually thereafter, individuals must acknowledge adherence to this policy and must sign the Acceptable Use Statement. The Acceptable Use Statement at the DMV helps ensure that all individuals accessing the DMV network understand their responsibilities as they pertain to the information security policies and procedures of the Department. Signing an acceptable use statement annually is a method to affirm and remind all users of the commitment of the Department to protect personal, sensitive, and confidential information at the DMV from inappropriate disclosure or misuse. Failure to abide by this policy may result in forfeiture of the privilege to use electronic resources at the DMV, access confidential information at the DMV, and/or disciplinary action. The Information Security Office (ISO) must approve any exceptions to this policy. Requests for an exception to this policy must be submitted via the Policy Exception Request Form (EXEC 205).
Procedures:
Managers and supervisors must ensure that all employees, consultants, contractors, or students under their supervision: 1. Read and understand the Acceptable Use Statement. 2. Understand the roles and responsibilities for information security related to their duties. 3. Understand the consequences for failing to comply with the policies stated in the Acceptable Use Statement. 4. Print his/her name, sign and date the form. After the statement has been signed, managers/supervisors will give each individual a copy and place the original form in the confidential file maintained in the unit.
Roles and Responsibilities:
Employees/Users accessing the DMV network are required to annually read, understand, and sign the Acceptable Use Statement of the DMV. Managers/Supervisors must ensure compliance with this policy by following the procedures as defined above.
Page - 26 -
October 2012
Definitions:
Acceptable Use Statement: A policy document that a user must agree to sign and comply with in order to be provided access to personal, sensitive, and confidential information belonging to or maintained by an organization, access to the network of an organization, or access to the Internet. Also referred to as an annual security disclosure statement or a confidentiality agreement. Annual Security Disclosure Statement: See Acceptable Use Statement definition. Confidentiality Agreement: See Acceptable Use Statement definition.
Authority/ References:
State Administrative Manual, Management Memo—Protection of Information Assets (MM 06-12) DMV Privacy Policy Information Security Awareness and Training Policy
Related Information:
Acceptable Use Statement (DMV 350) Mobile Devices
October 2012
Page - 27 -
Information Technology Policy Electronic Mail Policy #: Revised: Issued: Owner:
IS 2012-34 Planned for 2012 04/2010 Information Security Office
SAM SIMM Supersedes:
APM 8.100
Purpose:
The Department of Motor Vehicles’ (DMV) electronic mail (e-mail) policy defines the guidelines for the proper use and acceptable/unacceptable procedures for using e-mail.
Background/History:
Since initial introduction, DMV’s e-mail client use has expanded and it has become an important business resource tool. With its expanded use and increased level of importance, it is necessary to implement an e-mail policy that clarifies its use for employees and protects this resource for the Department. The Information Security Office distributed the first Electronic Mail Policy on April 23, 1997. To augment previous policy content and to provide further clarification of inappropriate e-mail usage, several revisions have been made since that time. Each revision enhanced protection of the Department’s interests while further mitigating potential security risks posed by the use of this efficient technological communications tool.
Persons Impacted:
This policy affects all DMV employees with e-mail access and other individuals that have been provided the use of the Department’s electronic communications capabilities.
Policy:
It is the policy of this Department that the use of the e-mail client is a privilege granted by DMV management to employees and contractors to conduct state business. The Department shall govern the use, retention, and access to e-mail messages transported within its internal network to ensure data security and integrity, and to safeguard proper use of the e-mail client. The term e-mail client includes the other tools associated with the Department’s chosen e-mail client, such as calendars, contacts, tasks, to-do lists and attachments.
Procedures: (Must be a separate document.)
Page - 28 -
Electronic Mail Procedures
October 2012
Roles and Responsibilities:
The Deputy Director of the Legal Affairs Division and the Chief Information Security Officer or their designees shall be responsible for approving explicit monitoring of a specific user’s email. Investigations Division, Information Security Office (ISO), Audits Office, or the California Highway Patrol (CHP) may conduct audits of employee e-mail and mail enclosures. Information Systems Division provides access to and terminates employee e-mail accounts, and blocks incoming e-mail addresses from delivery when deemed necessary and appropriate. Responsibility for administering DMV’s e-mail policy is assigned to the. ISO documents and processes inappropriate e-mails that are sent by or received by employees. CHP investigates all departmental computer security crimes, including those related to e-mail usage that is deemed appropriate for their review. The ISO, Investigations Division, Audits Office, Legal Affairs Division, Human Resources Branch, in conjunction with the affected division, and the CHP when appropriate, will coordinate responses to violations of the Department’s e-mail policy. When it is deemed necessary and appropriate for business purposes, Information Systems Division (ISD) may block specific incoming and/or outgoing e-mail addresses from the Department's directory. System Administration: Only designated technical support staff will perform e-mail client administrative responsibilities such as adding/deleting users, setting/resetting passwords, handling undelivered mail, and addressing server outages, etc. E-mail messages will be backed up and stored in compliance with DMV business requirements. The administrator will backup e-mail client daily. All backed up files will be retained and/or archived based on the business needs of the Department. Staff involved with administering the e-mail client is prohibited from intentionally seeking out and reading information contained within the e-mail client, and shall not use such information for personal gain.
Definitions:
Template update: Not applicable or not available.
Authority/References:
Government Code Section 8314 Government Code Section 14613.7 (a)
October 2012
Page - 29 -
Related Information:
Privacy: The Department will take reasonable and appropriate action to prevent the illicit interception, alteration, or unauthorized viewing of e-mail transmissions over Department-owned networks. However, the privacy and reliability of e-mail messages cannot be assured. Employees should never consider electronic communications to be either private or secure, and should gauge their usage accordingly. A real world example is to consider e-mail analogous to the sending of a post card through the postal system. E-Mail Monitoring Request Form Revision History (PDF)
Page - 30 -
October 2012
Procedures Title: Electronic Mail Procedures Owner: Information Security Office Issue Date: 4/2010 Revision Date: 05/2010 POLICY Electronic Mail Policy PROCEDURES Identifying E-mail Users: Users of the e-mail client include employees and approved special designees that require electronic communication capabilities. Special designees include contractors and other State of California representatives. Each user will have a single e-mail account and address. Only approved users will be permitted to input, transfer, and store electronic information on the e-mail client. Authorization: E-mail accounts are authorized at the discretion of the employee's manager or DMV contract manager for the special designee. To assure e-mail accounts remain accurate and accessible to only authorized individuals, it is the responsibility of the immediate supervisor/manager to close e-mail accounts of employees or special designees that have transferred, terminated, or separated from the Department. Access Control: To add, transfer, or delete an e-mail account, as appropriate, the manager must submit a completed ISD 100 (System Access Control) to the appropriate PC Coordinator. To access an employee's e-mail account, the manager must submit a completed and approved EMail Monitoring Request form to the Information Systems Division. Proposed language being vetted for planned 2012 update: Mobile Devices: Corporate issued or authorized personal mobile devices shall utilize the Department’s standard software for access to the Department’s e-mail client. DMV’s policies, standards, and procedures still apply, where applicable, including the Acceptable Use Statement (DMV 350). Secure E-mail: For those with business justification to send information classified as confidential, sensitive or personal, the Department email shall be sent using secure e-mail. To become an authorized user for secure e-mail, use the system access request process by completing an ISD 100 form.
October 2012
Page - 31 -
Employee Absences: Employees scheduled to be away from the office for one (1) or more work day(s) must activate the "Out of Office Assistant" feature in Microsoft Outlook. Examples of appropriate use of the "Out of Office Assistant" include employees being physically away from the office to attend training classes, conferences, or seminars, or when employees are scheduled to be on vacation or their regular day off. It does not include employees who have the ability to monitor their e-mails throughout the day while working outside of their office. The Auto Reply text of the outgoing message should indicate the start date of the employee's absence and the employee's return to work date, along with the name and telephone number of a person to contact for immediate assistance. Because the Auto Reply feature does go outside the Department, employees should use caution when providing personal information in their messages. Employees can use one of the following methods to ensure critical messages are read and acted upon: Forward all incoming e-mails to the supervisor or another employee for message review and possible action. Automatically forward incoming e-mails from a specific address or address group to the supervisor or another employee for review and possible action. E-Mail Retention: There is a tendency to retain e-mail messages longer than necessary for business purposes. To ensure system availability, DMV staff shall adhere to the following e-mail retention policy: Employees shall delete all nonessential incoming and outgoing e-mail messages and all obsolete messages on a weekly or otherwise regular basis. A nonessential e-mail message is one that no longer requires action on the part of the sender and/or receiver of the message. Generally, an email message may be retained as a reminder of an upcoming meeting or a pending decision or assignment, but should be deleted when the reminder is no longer necessary. Alternatively, an email message that may need to be available over an extended period of time should be removed from the e-mail client and placed in the employee's personal folder on the Department's private drive (e.g., U \) for future reference. Note: This section is not applicable for matters under litigation. All e-mail pertaining to any matter under litigation or pending litigation must not be deleted until authorized by the Legal Affairs Division.
Page - 32 -
October 2012
Appropriate Usage: Use of the Department's e-mail client is for conducting state and Department business. Departmental employees may use the e-mail client for the transmission and storage of human resources related documents such as electronic filings for examinations, electronic job applications and resumes, examinations and job opportunity bulletins, and other entities dealing with specific employee actions (i.e. back pay, workers' compensations, adverse actions, grievances, etc.). Additionally, with supervisory approval, employees can use the Department's e-mail client in the course of communications regarding Department-wide, divisional, or unit events, or for charitable drives, subject to any of the following conditions: The event has been approved by the Employee and Administrative Services Unit (EASU). The e-mail is issued or authorized by a departmental coordinator, chairperson, or the Director or his/her designee. The event is being held to celebrate the retirement of a Department employee. The message pertains to an activity/interest (i.e., Sunshine Club activities) involving employees within a unit, provided management has first approved its transmission. Use of the Department's e-mail client to disseminate these communications should be kept to a minimum, and must conform to this policy's section regarding prohibited use. Any use of the Department's e-mail client during work hours for personal enjoyment, private gain or advantage, or an outside endeavor not related to state business, is prohibited. Incidental and minimal use (as defined in Government Section 8314) of the Department's e-mail client is allowed outside of work hours (before work, after work, and during breaks and lunch periods) as long as such use is consistent with the guidelines provided above, and under "Prohibited Use and Activities of the Department's E-mail Client."
October 2012
Page - 33 -
Proposed language being vetted for planned 2012 update: Appropriate Content and Format: As previously stated, the Department's e-mail client is for conducting state and Department business. Content and format shall be professional and suitable for the audience. 1. Signature blocks may contain the following: Name Title, either working or state classification Unit, Division, and/or Agency Mailing and/or physical address Desk, cell, and/or fax number Professional certifications 2. The following Confidentiality Notice shall be included when appropriate: Confidentiality Notice: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. 3. The following content is not allowed: Stationery and themes (a set of unified design elements and color schemes applied to messages. They specify fonts, bullets, background color, horizontal lines, images, and other design elements included in outgoing e-mail messages.) Animations (the rapid display of a sequence of images of 2-D or 3-D artwork or model positions to create an illusion of movement) Unofficial logos or images Quotes other than excerpts from DMV’s current mission or vision statement as published on the Department’s public facing website: dmv.ca.gov Prohibited Use and Activities of the Department's E-mail Client: The Department's e-mail services may not be used for purposes other than state business or those activities authorized by the Department. No individual or organization may use the e-mail client anonymously or under false identification. Users shall not initiate, forward or store material or language that is discriminatory, fraudulent, harassing, embarrassing, sexually explicit, profane, intimidating, defamatory, or otherwise unlawful or inappropriate on the Department's e-mail client. Users shall not initiate or forward chain e-mail. Chain e-mail is a message sent to other individuals asking each recipient to send copies with the same request to any number of others. Utilizing the Department's e-mail client for solicitations of goods or services (i.e., products, cookie and candy sales, etc.) is prohibited unless the solicitation is part of conducting state business or a Department authorized activity or function. Users shall not attempt to connect to third-party e-mail systems from the DMV. This includes web-mail sites like Hotmail, Yahoo, and MSN, and Internet Service Provider e-mail accounts like Surewest, AT&T, and Earthlink.
Page - 34 -
October 2012
Monitoring: All electronic information within the e-mail client is the property of the Department of Motor Vehicles, State of California. Any data stored on the Department's e-mail client can be made accessible by the Department at any time. This data can be disclosed to whomever the Department deems appropriate. The Department's e-mail client may be monitored, as necessary, for operations, maintenance, security, and management reasons. Monitoring will comply with existing Department policy and procedures, as well as applicable state and federal laws. Monitoring the e-mail of a specific user shall only be initiated when there is sufficient reason to believe there has been inappropriate use of the system or as a means of obtaining evidence to support employee misconduct not related to e-mail. Such accounts may be monitored without further notice to the employee. Specific monitoring shall have the approval of the Chief Information Security Officer and the Deputy Director of the Legal Affairs Division, or designee. Investigations Division, Information Security Office, or Audits Office staff may conduct audits of employee e-mail and mail enclosures. Such audits may include viewing directories, e-mail, or data files on the network, desktop computers, laptop or notebook model computers, or backup media.
October 2012
Page - 35 -
IT Policy, Standards, Instructions and Guidelines References DMV Laptop Acceptable Use Standards
SAM 4819.3 State Information Management Authority and Responsibility SAM 5100
Policy
SP 800-14
Generally Accepted Principles and Practices for Securing Information Technology Systems
Page - 36 -
October 2012
Risk Assessment RA-1 Risk Assessment Policy and Procedures IT Policy, Standards, Instructions and Guidelines References SAM 5305 Risk Management SP 800-30
October 2012
Risk Management Guide for Information Technology Systems
Page - 37 -
RA-2 Security Categorization
Information Technology Policy Classifying and Handling Information Policy #: Revised: Issue Date: Owner:
IS 2012-03 04/2012 06/2007 Information Security Office
SAM SIMM Supersedes:
5320.2, 5320.5 APM 8.200
Purpose:
The purpose of this revision is to rename and align the existing Classification of Information Policy at the Department of Motor Vehicles (DMV) with State Administrative Manual (SAM) Section 5320.2 and SAM Management Memo—Protection of Information Assets (MM 06-12) that expand information classification criteria and require implementation of procedures for access, handling, and maintenance of personal and sensitive information.
Background/History:
All files, databases, materials, printed documents, and other media containing confidential, sensitive, and/or personal information require special precautions to prevent unauthorized disclosure of the information. Data classification is a key element to identifying appropriate levels of precautions to protect information resources.
Persons Impacted:
Page - 38 -
Current DMV policy requires Data Resource Managers (DRMs) to classify the information resources under their control as confidential, proprietary, sensitive, and/or public. To comply with California Civil Code Section 1798.29, SAM Sections 5320.2 and 5320.5, and SAM MM 06-12, this policy defines confidential, sensitive, and personal information and augments the classification requirement to appropriately safeguard information regardless of media type. This policy affects all employees, external entities, vendors, consultants, contractors, and others who have access to information maintained by the DMV.
October 2012
Policy:
It is the policy of the Department of Motor Vehicles (DMV) that all files, databases, materials, printed documents, and other media containing confidential, sensitive, and/or personal information use the classification structure listed below to protect essential public resources from unauthorized use, access, disclosure, modification, loss, or deletion. Public Information – Information maintained by state agencies that is not exempt from disclosure under the provisions of the California Public Records Act (Government Code Section 6250 et seq.) or other applicable state or federal laws. Confidential Information – Information maintained by state agencies that is exempt from disclosure under the provisions of the California Public Records Act (Government Code Sections 62506265) or other applicable state or federal laws. Sensitive Information and Personal Information may be found in Public Information and/or Confidential Information. All media, such as files, databases, printed documents, and other formats, containing sensitive and/or personal information require special precautions to prevent unauthorized disclosure. Sensitive and personal information contained in public records must be protected from inappropriate disclosure. Sensitive Information – Information maintained by the Department that requires special precautions to protect from unauthorized use, access, disclosure, modification, loss, or deletion. Sensitive information may be either public or confidential and is information that requires a higher than normal assurance of accuracy and completeness. Thus, the key factor for sensitive information is that of integrity. Typically, sensitive information includes records of financial transactions and regulatory actions. Personal Information – Information that identifies or describes an individual as defined in, but not limited by, the statutes that follow. This information must be protected from inappropriate access, use, or disclosure and must be made accessible to data subjects upon request. Notice-triggering personal information – Specific items or personal information (name plus Social Security number, California driver license or identification card number, or financial account number) that may trigger a requirement to notify individuals if it is acquired by an unauthorized person. See Civil Code Sections 1798.29 and 1798.3.Other individually identifiable information including certain health information. See the Information Practices Act (Civil Code Section 1798 et seq.) and the Declaration of Rights (California Constitution Article I, Section I).
October 2012
Page - 39 -
Policy (continued):
It is also the policy of the DMV to develop and implement procedures for the access, handling, and maintenance of confidential, sensitive, and personal information to preserve the integrity of the data. The Information Security Office must approve exceptions to this policy. Submit requests for exceptions to this policy via the Policy Exception Request (EXE 205) form.
Procedures: (must be a separate document)
Classifying and Handling Information Procedures
Roles and Responsibilities:
The Chief Privacy Officer provides notification to subjects of record for privacy and/or information security incidents in accordance with California Civil Code Section 1798.29. Data Resource Managers (DRMs) are responsible for maintaining the accuracy of the Data Resource Manager Summary located within the Data Resource Manager Handbook for each database to which they are the designated owner, and for notifying the Chief Information Security Officer whenever changes to the data occur. DRMs will identify and classify all Information Assets under their control on the basis of the classification structure. DMV Management in coordination with DRMs will identify and classify all Information Assets under their control. Deputy Directors and/or designees are responsible for the classification of files, materials, confidential documents, and other media under their control. They are responsible for the protection of the Information Assets from unauthorized use, access, disclosure, modification, loss, or deletion. The Chief Information Security Officer is responsible for tracking all Data Resource Manager Summaries located within the Data Resource Manager Handbooks and defines special security precautions that must be followed to ensure the integrity, security, and appropriate confidentiality level of the information.
Page - 40 -
October 2012
Definitions:
Data Subjects: Individuals whose sensitive and/or personal information is reviewed or requested. Data Resource Manager Summary: The portion of the DRM Handbook that is completed by the DRM and inventoried in the Information Security Office. It contains information regarding database classification, database component parts, and the resources (hardware, software, and personnel) necessary for the database to function. Electronic Devices: Devices that contain long term electronic memory, including, but not limited to, hard drives, facsimile machines, scanners, copiers, printers, cell phones and digital cameras. Electronic Media: Removable storage devices that include, but not limited to disks, CDs, cassettes, USB drives. Information Assets: (a) Computing hardware, e.g., servers, network components, workstations, laptops, smart phones, tablets, removable storage devices, etc. (b) databases, data processing capabilities, automated files and the documents and hardcopy records they represent (c) software such as automated programs, applications and operating systems, communications and collaboration tools (d) network-attached devices, such as storage, copiers, and facsimile machines (e) information technology infrastructure, e.g., network, routers, firewalls, switches (f) Essential public resources including DMV information, whether in hardcopy or electronic format. Personal Information: Any information which identifies or describes an individual and can be used to identify, contact, or locate a person to whom the information pertains. This includes, but is not limited to a first name or first initial and last name of an individual; home address; home phone number; physical description; California driver license number or identification card number; vehicle registration plate number; financial information; Social Security number; medical, employment or education history. Rendering Data Anonymous: the process of replacing identifying information within collected data with substitute data for a temporary time or location.
October 2012
Page - 41 -
Authority/References:
Information Practices Act, Section 1798 et seq. California Public Records Act, Section 6250 Declaration of Rights, Article I, Section I Drivers Privacy Protection Act, Title 18, Part I, Section 2721 et seq. SAM Classification of Information, Section 5320.5 Protection of Information Assets (MM 06-12) Data Resource Managers Data Resource Manager (DRM) Listing Data Resource Manger Handbook
Related Information:
Information Access Confidentiality Requirements Notification of Security Breach Involving Personal Information Public Information, Section 6.100 Information Controls Records Management, Section 4.600
Page - 42 -
October 2012
Title:
Classifying and Handling Information Procedures
Owner:
Information Security Office
Issue Date:
06/2007
Revision Date:
04/2012
POLICY Classifying and Handling Information PROCEDURES General 1. DRMs classify the database information in their Data Resource Manager Handbook and submit to the Information Security Office for inventory. For information on the classification of a specific data resource, contact the appropriate DRM. A list of DRMs and the Information Assets for which they are responsible can be found on the DMVWeb. 2. Deputy Directors and/or designees classify files, materials, other media, and/or printed documents. 3. Each division maintains an inventory of files, materials, and printed documents. 4. During non-working hours, store hardcopy files and documents containing confidential, personal, and sensitive information in locked desks, file cabinets, or other authorized locations. 5. Only store confidential, personal, and sensitive information on an appropriate network drive, not a workstation hard drive and/or local drive. 6. Confidential, personal, and sensitive information may only be removed or stored off-site when authorized in writing by management. 7. Only view or update confidential, personal, and sensitive information based on job related function and need to know basis. 8. Appropriately dispose of confidential, personal, and sensitive information through approved destruction methods. 9. When offices are vacated, containers are disposed of, equipment is discarded, etc., ensure all confidential, personal and sensitive information, either hardcopy or electronic, is properly handled through approved destruction methods. 10. Regularly update address books or other contact information with current recipient information.
October 2012
Page - 43 -
Facsimile 1. 2. 3. 4.
Locate facsimile machines away from public access. Routinely check for faxes. Deliver faxes to the addressee in a secure and timely manner. When sending faxes, confirm the fax number and notify the recipient prior to faxing the document. 5. Do not leave incoming/outgoing faxes containing confidential, personal, and sensitive information unattended. 6. Use DMV Fax Transmission Cover Sheet (DMV 202) for every fax to notify persons receiving the fax in error to contact the sender and destroy the document. Development/Test/Training Environment Production confidential, personal, and sensitive data shall not be used for any development or test purposes unless the data has been rendered anonymous, has been sanitized, or has been masked. Use of anonymous, sanitized or masked production data in a development, test, training or similar environment requires the approval of the Information Security Office. Correspondence Deliver incoming correspondence marked “confidential,” “personal,” “sensitive,” or with like descriptions unopened to the intended recipient unless authorized by management. Ensure that the address on the envelope has been accurately transcribed, and that the inside address and address on the envelope match. When correspondence is sent, received, or delivered, place all documents in the envelope so that the information is not visible. Photocopiers Do not copy confidential, sensitive, and personal information without a clear business justification and authorization. Do not leave documents containing confidential, personal, and sensitive information unattended.
Page - 44 -
October 2012
Verbal Communications All staff are to take reasonable steps to protect the privacy of all verbal exchanges or discussions of confidential, personal, and sensitive information, regardless of where the discussion occurs in enclosed offices and/or interview rooms (telephone, restrooms, break rooms, etc.). Office Closure/Move Managers/Supervisors ensure that privacy and security of confidential, personal, and sensitive information is secured during closure of an office or move. Disposal or Destruction Prior to disposal or off-site removal for repair of electronic media or electronic devices containing confidential, personal, and sensitive information, the media or device must be sanitized in accordance with National Institute of Standards and Technology (NIST) Special Publication 800-88, Guidelines for Media Sanitation. IT Policy, Standards, Instructions and Guidelines References APM Chapter 6.110 Employee Home Address and Home Telephone Numbers SAM 5320.5 Classification of Information SP 800-60
October 2012
Guide for Mapping Types of Information and Information Systems to Security Categories: (2 Volumes) - Volume 1: Guide and Volume 2: Appendices
Page - 45 -
RA-3 Risk Assessment Each DMV application shall undergo a Risk Assessment prior to deployment which identifies all threats, assessment of vulnerabilities and identification of mitigation to eliminate or reduce the vulnerabilities to an acceptable level. IT Policy, Standards, Instructions and Guidelines References SAM 5305.1 Risk Analysis SAM 5305.2 Agency Risk Management Program ITPL
10-13 Security Reporting Scorecards
ITPL
10-08 Infrastructure Consolidation Program Progress Report Scorecards
TL
12-11 Improved Security Risk Assessment Tool
SP 800-98
Guidelines for Securing Radio Frequency Identification (RFID) Systems
SP 800-63
Electronic Authentication Guideline
SIMM 70
IT Security Certifications
SP 800-66 Rev. 1 An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule SP 800-82
Guide to Industrial Control Systems (ICS) Security
SP 800-40
Creating a Patch and Vulnerability Management Program
RA-5 Vulnerability Scanning IT Policy, Standards, Instructions and Guidelines References SP 800-24 PBX Vulnerability Analysis: Finding Holes in Your PBX Before Someone Else Does SP 800-51 Rev. 1
Page - 46 -
Guide to Using Vulnerability Naming Schemes
October 2012
System and Services Acquisition SA-1 System and Services Acquisition Policy and Procedures IT Policy, Standards, Instructions and Guidelines References 2004-01 Desktop Personal Computer Policy 2001-01
Desktop Technology Policy
Desktop Technology Process and Procedures ITPL 11-06
Information Technology Capital Plan Instructions & Templates 2011-12
TL
12-12 Process to Purchase Tablet Devices
SIMM 47A
Tablet Device Purchase Justification
SAM 4819.35 Feasibility Study Report SAM 4819.38 Preparing the Feasibility Study Report- Reporting Exemption Request SAM 4819.41 Procurement Review and Certification SAM 4925
Consistency with Agency Information Management Strategy and IT Capital Plan
SIMM 16 Service Contract Information Technology Certification A Service Contract Information Technology (SCIT) Certification FAQS SIMM 28
Formal Information Technology Solicitation Review
SIMM 60
Agency Information Management Strategy
A AIMS Transmittal Letter (doc) B AIMS Annual Certification Letter (doc) SIMM 110
AIMS Documentation Guidelines
SA-2 Allocation of Resources IT Policy, Standards, Instructions and Guidelines References APM 7.650 Personal Communication Devices and Voicemail IT 2004-02
DMV Personal Communications Devices & Funding Policy
ITPL 10-18
Information Technology Expenditure Reporting and Cost Optimization
ITPL 10-11
Information Technology Capital Plan Instructions, Economic Analysis Worksheet, Revisions, and Reporting Clarifications
ITPL 09-02
Information Technology Capital Planning Process, Forms and Instructions
SAM 4903
Exhibits and Supporting Documents
SAM 4903.2 Information Management Costs October 2012
Page - 47 -
SAM 4904
Information Technology Five-Year Capital Plan
SAM 4920
Purpose
SAM 4921
Feasibility Study Basic Policy
SAM 4922
Feasibility Study Scope
SAM 4923
Feasibility Study Participation
SAM 4924
Feasibility Study Documentation
SAM 4928
Feasibility Study Report
SAM 4930
Project Summary Package
SIMM 15
Departmental Delegated Cost Thresholds
SIMM 20
Feasibility Study Report Preparation Instructions (FSR)
SIMM 30
Special Project Report (SPR) Preparation Instructions
SIMM 40
FSR-Reporting Exemption Request (RER) Preparation Instructions
SIMM 55
Information Technology Cost Report Preparation Instructions
55C Frequently Asked Questions SIMM 57
Information Technology Capital Plan (ITCP) Preparation Instructions
A Segment One, Proposed IT Project Concepts Summary of IT Project Concepts B Segment Two, Approved IT Projects SP 800-65
Recommendations for Integrating Information Security into the Capital Planning and Investment Control Process (CPIC)
SA-3 Life Cycle Support IT Policy, Standards, Instructions and Guidelines References IT 2007-02 Project Management Office Policy SPCB 99-05 DMV Verification and Validation Policy SPCB 99-04 DMV System Development Methodology Policy ITPL 10-07
Project Status Reporting and Enterprise Architecture Reporting
ITPL 10-05
Information Technology Project Oversight Framework
ITPL 09-01
California Project Management Methodology and Other Associated Information
SAM 4910
California Project Management Methodology (CA-PMM)
SAM 4940
Project Oversight and Project Implementation and Evaluation Policy
SAM 4941
Overview
SAM 4942
Compliance Review
Page - 48 -
October 2012
SAM 4944
IT Project Oversight and Reporting
SAM 4945
Special Project Report – General Reporting Requirements
SAM 4945.2 Special Project Report – Content and Format SAM 4947
Post-Implementation Evaluation Report
SAM 4947.2 Post-Implementation Evaluation Report – Content and Format SAM 5345
Information Systems Acquisition, Development, and Maintenance
SIMM 10
Introduction to IT Project Reporting
10A Document Description and Process Flow SIMM 17
California Project Management Methodology (CA-PMM)-Updated
SIMM 18
IT Exemptions
A IT Contract Exemptions Associated with Executive Order S-09-09 SIMM 45
Information Technology Project Oversight Framework
Appendix A Project Management Practices and Processes Appendix D Project Risk List Appendix G Independent Project Oversight Report- Instructions Appendix H Definitions and Terms SIMM 50
Instructions for Completing the Post Implementation Evaluation Report (PIER)
SP 800-64
Security Considerations in the System Development Life Cycle
SP 800-37 Rev. 1 Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach
SA-4 Acquisition Process IT Policy, Standards, Instructions and Guidelines References SP 800-23 Guidelines to Federal Organizations on Security Assurance and Acquisition/Use of Tested/Evaluated Products
SA-5 Information System Documentation IT Policy, Standards, Instructions and Guidelines References ITPL 10-10 Information Technology Accessibility SAM 4833
Information Technology Accessibility Policy
SAM 4833.1 Exceptions to Accessibility SIMM 25 October 2012
IT Accessibility Resources Guide Page - 49 -
SP 800-55 Rev. 1
Performance Measurement Guide for Information Security
SA-6 Software Usage Restrictions Unauthorized Software Unauthorized software is a violation of the DMV Software Management Policy and SAM Section 4846. Periodic network scans for unauthorized software shall be submitted to the Information Security Office. Peer-to-Peer File Sharing Peer-to-Peer file sharing programs allow individual Internet or network users to access infringing materials located on workstations or servers and to download them onto their own equipment without authorization. These programs can be used to transmit copyrighted materials or to obtain information from someone's computer system without permission. The technologies associated with peer-to-peer file sharing are varied and continuously evolving. While there are certain specific legitimate business applications for the use of peer-to-peer technologies for the state, it is acknowledged that this same technology is used for a variety of inappropriate or illegal uses such as exchange of copyrighted music. The Chief Information Officer and the Chief Information Security Officer must approve all peerto-peer file sharing technology. All other uses are prohibited. This includes, but is not limited to, transfer of music, movies, software, and other intellectual property. IT Policy, Standards, Instructions and Guidelines References IT 2003-01 Software Management Policy IT 2003-02
Personal Computer Coordinator Policy
ITPL 10-01
Open Source Software Policy
SAM 4846
California Software Management Policy
SAM 4846.1
Software Management Plan
SAM 4846.2
Software Management Policy Reporting Requirements
SAM 5345.1
Software Licensing Integrity Practices
SIMM 80
California Software Management Policy Annual Statement of Compliance
SIMM 120
Software Management Plan Guidelines
Page - 50 -
October 2012
SA-7 User-Installed Software IT Policy, Standards, Instructions and Guidelines References IT 2003-01 Software Management Policy SAM 4846
October 2012
California Software Management Policy
Page - 51 -
SA-8 Security Engineering Principles
Information Technology Policy Design and Utilization of Reliable Systems Policy # Revised: Issue Date: Owner:
IS 2012-08 Unknown Information Security Office
SAM SIMM: Supersedes:
Policy 5
Purpose:
State Administrative Manual (SAM) Section 5305 states in part, "The state's Information Assets (its data processing –capabilities, information technology infrastructure and data) are an essential public resource. For many agencies, program operations would effectively cease in the absence of key computer systems..." DMV operations are information-dependent. The availability of data that users need to perform their work is fundamental to information processing and/or communications systems. The degree to which users rely on the ongoing availability of the Information Assets increases the need to address this issue at the policy level.
Persons Impacted:
Application developers, system and database administrators and any other staff involved in the system development life cycle.
Policy:
DMV data processing and information technology infrastructure will be designed, developed, and maintained to ensure their reliability. Information assets will be available with the integrity users expect, when and where they are needed.
Procedures:
Procedures to implement this policy are the responsibility of the Information Systems Division.
Roles and Responsibilities:
System managers, developers, and analysts will evaluate and incorporate redundancy, backup, and recovery attributes into the design of critical applications and all other applications that require information availability for users at specific times and locations.
Authority/References:
SAM Section 5315.1
Page - 52 -
October 2012
IT Policy, Standards, Instructions and Guidelines References SP 800-27 Rev. A Engineering Principles for Information Technology Security (A Baseline for Achieving Security)
SA-11 Developer Security Testing
Information Technology Policy Application Security and Secure Coding Policy Policy # Revised: Issue Date: Owner:
IS 2012-02 April 2012 Information Security Office
Purpose:
SAM SIMM: Supersedes:
5305 None
To be most effective, information security must be integrated into the system development lifecycle (SDLC) from system inception. Early integration of security in the SDLC enables the Department to: Identify and mitigate any security vulnerabilities and misconfigurations during the early stages of development, resulting in lower cost of security control implementation and vulnerability mitigation; Be aware of potential design challenges caused by mandatory security controls; Identify shared security services and reuse of security strategies and tools to reduce development cost and schedule while improving security posture through proven methods and techniques.
Background/History:
The Department accepts payment card transactions (credit cards and debit cards) as a form of payment in many applications. Therefore, DMV must follow the Payment Card Industry (PCI) Data Security Standard (DSS). PCI DSS was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. Requirement 6 of PCI DSS addresses the development and maintenance of secure systems and applications. This policy specifically addresses a portion of requirement 6.3 - Incorporate information security throughout the software development life cycle.
Persons Impacted: October 2012
Application Developers (both DMV and contract staff) Page - 53 -
Policy:
All new and updates to existing code written for use within the DMV’s Information Assets (as defined by State Administrative Manual (SAM) Section 5305) must comply with DMV’s Application Security and Secure Coding Standards prior to deploying into a production environment. (Existing production code shall be brought into compliance whenever a significant change is created to the code, or if mandated by DMV policy, or by the direction of the Information Security Office.) This applies to both in-house and/or outsourced code development. This policy does not apply to commercial, off-the-shelf (COTS) applications. Exceptions to this policy will be subject to the written approval of the Chief Information Officer and the Chief Information Security Officer. Exceptions should be requested using the Policy Exception Request (EXEC 205).
Procedures: (must be a separate document)
Refer to the Application Security & Secure Coding Standards Verification Checklist within the Application Security and Secure Coding Standards.
Roles and Responsibilities:
Information Systems Division – must ensure that systems are developed and maintained in accordance with this policy and associated standards. Application Developers – must follow secure software engineering practices as described in DMV’s Application Security and Secure Coding Standards. System Test, Information Security Office, Project Management Office, Information Privacy Office, System Access Infrastructure, and Design will validate, via the Application Security and Secure Coding Standards Verification Checklist, that the standards and procedures are being followed.
Definitions:
Refer to the Application Security and Secure Coding Standards.
Authority/References:
State Administrative Manual (SAM) Section 5305.
Related Information:
Security Considerations in the Systems Development Life Cycle – NIST SP800-64 Rev2 http://csrc.nist.gov/publications/nistpubs/800-64-Rev2/SP800-64Revision2.pdf Guide to Protecting the Confidentiality of Personal Identifiable Information (PII) – NIST SP800-122 http://csrc.nist.gov/publications/nistpubs/800-122/sp800-122.pdf
Page - 54 -
October 2012
Information Technology Policy Application Testing Policy # Revised: Issue Date: Owner:
IS 2012-13 Unknown Information Security Office
Revision Date: SAM/SIMM Supersedes:
Policy 11
This policy, while providing the Department and its information users assurance of the integrity of the information on which they rely by adequately testing the applications that process the data, ensures that those ultimately responsible for DMV's Information Assets, the Data Resource Managers, are aware of and approve changes that affect the information.
Purpose:
The Department and its information users rely heavily on the data processed by DMV's application software. The development and maintenance of these applications will be ongoing due to changes in legislation, user enhancements and other factors. The DMV Data Resource Managers are responsible for all major decisions concerning the information under their control; therefore, any changes that may affect that information must have their approval. This policy recognizes that in some emergency instances, this approval may have to be obtained retroactively. Background/History: Template update: Not applicable or not available. Persons Impacted:
Template update: Not applicable or not available.
Policy:
At the Department of Motor Vehicles, all new or modified applications, including any associated procedures, shall be sufficiently tested to ensure the integrity of the information which they process. Once tested, they shall be approved by the responsible Data Resource Manager, or a designated representative, before release to the production environment.
Procedures:
Change control procedures for the testing and release of applications to production are the responsibility of the Information Systems Division. The Systems Services Section within that division should be contacted for information on the actual procedures.
IT Policy, Standards, Instructions and Guidelines References SPCB 99-03 DMV Software Quality Assurance Policy SP 800-19 October 2012
Mobile Agent Security Page - 55 -
SA-17 Developer Security Architecture Design IT Policy, Standards, Instructions and Guidelines References SP 800-33 Underlying Technical Models for Information Technology Security
Page - 56 -
October 2012
Operational Awareness and Training AT-1 Security Awareness and Training Policy and Procedures
Information Technology Policy Information Security Awareness and Training Policy # Revised: Issue Date:
IS 2012-06 Unknown
SAM SIMM:
Owner:
Information Security Office
Supersedes:
5300.3 70 IT Security Certifications Policy 2
Purpose:
Errors, direct manipulation, or loss of critical or confidential information causes harm and embarrassment to DMV and its customers, causes the unnecessary expense of valuable staff time and can be detrimental to the health and safety of the general public and government employees. Since the Information Security Program depends on all employees understanding their information securityrelated responsibilities, security awareness is a critical component of the program. Information security awareness will be included in new employee orientation and technical training curriculum. Posters, flyers and other security awareness methods will be used to reinforce information users' understanding of their responsibilities.
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
All employees and contract staff.
Policy:
The Department will establish and utilize an Information Security Awareness Program to assure that employees and contract staff are aware of their information security responsibilities and are trained in information security related techniques.
Procedures:
Security pamphlets, manuals, videos, and on-site training are available resources that should be utilized as necessary.
October 2012
Page - 57 -
Roles and Responsibilities:
Program Managers, in cooperation with the Information Security Office, are responsible for ensuring that staff members possess and are provided with the knowledge and skills necessary for the effective use of information processing systems and the storage and disposal of confidential or sensitive information. Periodic employee conformance evaluations will be made to identify and correct security deficiencies or violations. Employees and Contract Staff: Will sign the Acceptable Use Statement (DMV 350) upon employment and annually thereafter. These signed statements will become part of the employee's permanent employment record.
Definitions:
Template update: Not applicable or not available.
Authority/References:
State Administrative Manual (SAM) Section 5300.3
Related Information:
Acceptable Use Classifying and Handling Information
IT Policy, Standards, Instructions and Guidelines References SP 800-50 Building an Information Technology Security Awareness and Training Program SP 800-12
Page - 58 -
An Introduction to Computer Security: The NIST Handbook
October 2012
AT-2 Security Awareness IT Policy, Standards, Instructions and Guidelines References Acceptable Use Statement (DMV350)
AT-3 Security Training IT Policy, Standards, Instructions and Guidelines References SAM 4854 Training and Employee Development SP 800-16 Rev. 1 Information Security Training Requirements: A Role- and PerformanceBased Model
October 2012
Page - 59 -
Page - 60 -
October 2012
Configuration Management1 CM-1 Configuration Management Policy and Procedures Network Administration 1. Databases owned by Data Resource Managers (DRMs) require DRM access authorization and approval. 2. User group managers will identify permissions to be granted to utilities, files, directories, and folders. These managers will also identify when access is to be changed or terminated. 3. All components on the LAN shall have a Primary Administrator and a Backup Administrator. Contact personnel shall be assigned. 4. Access control administration will assign user permissions, reset users' passwords, and establish defaults, directories, and paths for users. 5. Only the Administrator will be allowed to add, change, or delete UserIDs, and change or delete access to files or applications of LAN users, as requested by user group managers or a delegated contact person. 6. The Administrator must be able to determine the status of users connected to the LAN or WAN, by screen display and/or audit report. 7. Administrators must have software capabilities allowing for monitoring and capturing system events, including but not limited to system interrupts or possible tampering. IT Policy, Standards, Instructions and Guidelines References IT 2010-01 Desktop/Laptop Operating Systems Policy Desktop/Laptop Operating Systems Procedures 98-02
DMV Network Server Ownership Policy
SP 800-128
Guide for Security-Focused Configuration Management of Information Systems
CM-2 Baseline Configuration LAN Standards The following standards shall be applied to the DMV LAN(s). 1. The Local Area Network (LAN) must have administration functions that oversee the integrity, confidentiality, and availability of the network. 2. Vulnerabilities identified as a result of a risk analysis will be mitigated to an acceptable level before the network is promoted to production. 3. Software installed on the network must be approved for use (DMV Software Management Policy and SAM 4846). 4. Help Desk functions shall be provided for user assistance.
1
Most of the information in this section was formerly Appendix G - Network Security Standards.
October 2012
Page - 61 -
5. Access control administrative functions shall be performed. 6. Access to the LAN shall be documented in Audit Logs. 7. Changes made to the network infrastructure shall be managed to protect the computing environment from disruption. This includes adequate testing of network changes. 8. System security events shall be monitored, captured and resolved in a timely manner. 9. Uninterrupted Power Sources (UPS) and fail over capability shall be utilized for highavailability components. 10. All networks are required to implement and maintain adequate physical security for DMV records and equipment to prevent access/viewing by unauthorized users. 11. Documentation of the network environment and Information Assets shall be kept current. 12. Written operational procedures shall be maintained. 13. Remote Access Standards shall be followed if remote connections are approved and established. 14. The types of data traversing the network shall be documented and plans developed for backup and recovery. Network Components Standards Standards for network components including, but not limited to, servers, routers, workstations, printers, mobile devices, and firewalls are as follows: 1. Perform system hardening to remove all unnecessary services, default UserIDs and passwords before promoting to production environment. 2. Establish and document baseline configurations. 3. Conduct periodic vulnerability scans, remediation, and system hardening. 4. Perform patch management and assign an elevated priority to security patches. 5. Provide protection from malicious code using anti-virus, spyware, and other mitigation tools. 6. Label and identify network components. 7. Network components shall adhere to access control standards. (See UserID and Password Standards.) 8. Apply routine maintenance and technology upgrades. 9. Perform periodic audits and/or reviews. USB Ports and CD/DVD Drives: Access Limitation Department desktop and laptop workstations are routinely equipped with Universal Serial Bus (USB) mass storage and/or CD/DVD drives. As such, information and data may be transferred via these connections to mobile storage devices. This capability creates a risk of potential abuse and is in violation of the Mobile Devices policy. The Department will automatically disable all USB drives and CD/DVD drives in its standard desktop or laptop workstation build. Authorization may be granted to individuals based on business need via the normal System Access Control Form (ISD 100) process. A temporary need to transfer data via a USB mass storage device or CD/DVD can be handled as needed, with management approval, by your PC coordinator.
Page - 62 -
October 2012
WAN Security Standards WAN security standards are the same as other components in the LAN. In addition, these elements shall be considered: Third party agreements should require compliance with statute and state policy, and document the DMV's ability to conduct audits. The Chief Information Security Officer may recommend an information security review prior to production. IT Policy, Standards, Instructions and Guidelines References SPCB 99-02 DMV Software Configuration Management Policy
CM-3 Configuration Change Control Technology Upgrades Technology upgrades to LAN/WAN components shall be planned and tested before promoting to the production environment. Upgrades shall be acquired from reliable and safe sources. Change control procedures shall be followed. Refer to: Q:\ISD\Change Control\CM Policy.doc
CM-5 Access Restrictions for Change Routers, Switches Only authorized personnel shall have access to routers, switches, and other telecommunication equipment. These components shall be located in a locked area. IT Policy, Standards, Instructions and Guidelines References SP 800-155 BIOS Integrity Measurement Guidelines SP 800-147
Basic Input/Output System (BIOS) Protection Guidelines
CM-6 Configuration Settings IT Policy, Standards, Instructions and Guidelines References SP 800-126 Rev. 2 The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2 SP 800-126 Errata SP 800-126 Rev. 1 The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.1 SP 800-126
October 2012
The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.0
Page - 63 -
SP 800-117 Rev. 1 Guide to Adopting and Using the Security Content Automation Protocol (SCAP) Version 1.2 SP 800-70 Rev. 2 National Checklist Program for IT Products: Guidelines for Checklist Users and Developers SP 800-69
Guidance for Securing Microsoft Windows XP Home Edition: A NIST Security Configuration Checklist
SP 800-68
Guide to Securing Microsoft Windows XP Systems for IT Professionals
SP 800-43
Systems Administration Guidance for Windows 2000 Professional System
CM-8 Information System Component Inventory An up-to-date inventory list of DMV authorized software, hardware, and other Information Assets shall be maintained. A copy of the inventory reports must be available for review and audit. Network maps indicating physical and logical locations, contacts, and component identifiers shall be maintained. Detailed network maps are considered confidential information and shall be handled according to Department procedures. This information must be available upon request from an authorized party such as audits or law enforcement. IT Policy, Standards, Instructions and Guidelines References IT 2008-02 DMV Laptop Tracking Policy
Page - 64 -
October 2012
Contingency Planning CP-2 Contingency Plan IT Policy, Standards, Instructions and Guidelines References SP 800-34 Rev. 1 Contingency Planning Guide for Federal Information Systems (Errata Page - Nov. 11, 2010)
CP-8 Telecommunications Services IT Policy, Standards, Instructions and Guidelines References SP 800-13 Telecommunications Security Guidelines for Telecommunications Management Network
October 2012
Page - 65 -
CP-10 Information System Recovery and Reconstitution
Information Technology Policy Disaster Recovery Plan Policy # Revised: Issue Date: Owner:
IS 2012-10 Unknown Information Security Office
Purpose:
SAM SIMM: Supersedes:
5355.1 Policy 7
The purpose of this policy is to ensure the continued availability of the Department's critical processes so that an event that impacts those processes will not have an unacceptable fiscal, health and safety, public image or legal impact on the Department, the state or the public and to comply with the State Administrative Manual, Section 5355.1 and Government Code, Section 11549.3, which require each State agency to: Establish a Business Continuity Management Program in part to ensure the agency has the ability to continue its essential functions during a business disruption. Develop and maintain a Disaster Recovery Plan (DRP) identifying the computer applications that are critical to the agency's operations, the Information Assets needed for those applications and the agency plan for resuming operations following an unplanned disruption of those applications. Maintain the DRP and provide annual documentation for those updates to the California Technology Agency, Office of Information Security.
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
Management and staff assigned responsibilities in the DRP.
Policy:
The Department of Motor Vehicles will identify, prioritize, develop and maintain a Disaster Recovery Plan (DRP) for its critical processes and supporting data stores. The Department will designate a Disaster Recovery Coordinator who will act as the departmental IT representative in business continuity planning and during recovery of a business disruption.
Page - 66 -
October 2012
Procedures:
The DMV Business Continuity Coordinator in the Administrative Services Division will perform a Business Impact Analysis, identifying and prioritizing the Department’s critical processes and recovery time frames. The Business Continuity Coordinator will provide the Business Impact Analysis to the Disaster Recovery Coordinator for inclusion in disaster recovery planning. The Disaster Recovery Coordinator will coordinate the development and documentation of the DMV Disaster Recovery Plan. The Disaster Recovery Coordinator will be responsible for the maintenance of the Disaster Recovery Plan and with providing an informational copy of the plan to the California Technology Agency, Office of Information Security in accordance with the Agency Disaster Recovery Plan Submission Schedule.
Roles and Responsibilities:
Disaster Recovery Coordinator: (a) Maintain the DRP in accordance with the State Information Management Manual (SIMM) 65A. (b) Provide an informational copy of the plan to the California Technology Agency, Office of Information Security accordance with the Agency Disaster Recovery Plan Submission Schedule. Information Security Office: Fulfill the Department’s compliance with the Agency Disaster Recovery Plan Submission Schedule.
Definitions:
None
Authority/References:
SAM Sections 5355, 5355.1, 5355.2 and 5360
Related Information:
State Information Management Manual (SIMM) 65A
IT Policy, Standards, Instructions and Guidelines References SAM 5355 Disaster Recovery Management SAM 5355.1 Disaster Recovery Planning SAM 5355.2 Agency Disaster Recovery Plan SAM 5360
Compliance
SAM 5360.1 Compliance Summary SIMM 05
Reporting Schedules
05B Disaster Recovery Plan Quarterly Reporting Schedule SIMM 65
Information Security Instructions and Forms
A Disaster Recovery Documentation for Agencies Preparation Instructions B Agency Information Security Incident Notification and Reporting Instructions C Agency Information Security Incident Report D Security Breach Involving Personal Information: Requirements and Decision- Making Criteria for State Agencies October 2012
Page - 67 -
Page - 68 -
October 2012
Identification and Authorization IA-2 Identification and Authorization (Organizational Users) IT Policy, Standards, Instructions and Guidelines References FIPS 191 Guideline for The Analysis of Local Area Network Security FIPS 201-1
Personal Identity Verification (PIV) of Federal Employees and Contractors
FIPS 201-2 DRAFT
Personal Identity Verification (PIV) of Federal Employees and Contractors
Federal-Register-Notice_announcing-draft-FIPS-201-2.pdf Track-Changes_Draft_NIST-FIPS-201-2.pdf Comment-Template_Draft-NIST-FIPS201-2.xls SP 800-153
Guidelines for Securing Wireless Local Area Networks (WLANs)
SP 800-104
A Scheme for PIV Visual Card Topography
SP 800-103
An Ontology of Identity Credentials, Part I: Background and Formulation
SP 800-97
Establishing Wireless Robust Security Networks: A Guide to IEEE 802.11i
SP 800-96
PIV Card to Reader Interoperability Guidelines
SP 800-79-1 Guidelines for the Accreditation of Personal Identity Verification (PIV) Card Issuers (PCI's) SP 800-78-3 Cryptographic Algorithms and Key Sizes for Personal Identification Verification (PIV) SP 800-73-3 Interfaces for Personal Identity Verification (4 Parts) Pt. 1- End Point PIV Card Application Namespace, Data Model & Representation Pt. 2- PIV Card Application Card Command Interface Pt. 3- PIV Client Application Programming Interface Pt. 4- The PIV Transitional Interfaces & Data Model Specification
IA-4 Identifier Management IT Policy, Standards, Instructions and Guidelines References SP 800-119 Guidelines for the Secure Deployment of IPv6 SP 800-85A-2 PIV Card Application and Middleware Interface Test Guidelines
October 2012
Page - 69 -
IA-5 Authenticator Management IT Policy, Standards, Instructions and Guidelines References FIPS 181 Automated Password Generator SP 800-132
Recommendation for Password-Based Key Derivation Part 1: Storage Applications
SP 800-118
Guide to Enterprise Password Management
IA-7 Cryptographic Module Authentication IT Policy, Standards, Instructions and Guidelines References SP 800-135 Recommendation for Existing Application-Specific Key Derivation Functions SP 800-133
Recommendation for Cryptographic Key Generation
SP 800-131 C Transitions: Validating the Transition from FIPS 186-2 to FIPS 186-3 SP 800-131 C Comments SP 800-131 B Transitions: Validation of Transitioning Cryptographic Algorithm and Key Lengths SP 800-131 B Comments SP 800-131 A Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths SP 800-130
A Framework for Designing Cryptographic Key Management Systems
SP 800-89
Recommendation for Obtaining Assurances for Digital Signature Applications
SP 800-29
A Comparison of the Security Requirements for Cryptographic Modules in FIPS 140-1 and FIPS 140-2
SP 800-85 B-1 PIV Data Model Conformance Test Guidelines
IA-8 Identification and Authorization (Non-Organizational Users) IT Policy, Standards, Instructions and Guidelines References FIPS 199 Standards for Security Categorization of Federal Information and Information Systems FIPS 200
Page - 70 -
Minimum Security Requirements for Federal Information and Information Systems
October 2012
Incident Response IR-1 Incident Response Policy and Procedures
Information Technology Policy Information Security Incident Reporting and Follow Up Policy # Revised: Issue Date: Owner:
IS 2012-07 Unknown Information Security Office
Purpose:
SAM SIMM: Supersedes:
5320.3 Policy 4
This policy defines the process for handling and reporting information security incidents. The policy is intended to: 1. 2. 3. 4. 5.
Discourage repetition of incidents; Minimize the impact of the incident to DMV; Assure that perpetrators are prosecuted; Meet all reporting requirements; Provide feedback to management for improvement/changes in the Information Security Program; and 6. Provide the guidelines and policies to ensure the consistent handling, reporting and incident resolution. Background/History:
Template update: Not applicable or not available.
Persons Impacted:
All employees, contractors and Government and Industry Partners.
Policy:
The Department of Motor Vehicles will take prompt action to identify, report, and resolve all information security incidents.
Procedures: (must be a separate document)
Procedures related to this policy are defined in the handbook Handling and Reporting Information Security Incidents, (DMV145). Copies of this guide may be ordered from the DMV Supply Catalog.
October 2012
Page - 71 -
Roles and Responsibilities:
Employees, contractors and Government and Industry Partners: Read, understand and apply the information in the DMV 145. Information Security Office: Publish and maintain the DMV 145.
Definitions:
Government and Industry Partners The term used in this document for external personnel who access the DMV systems performing transactions (including inquiries) for their employer or for DMV. Security Incident: pertains to information in electronic and paper records. A DMV sensitive, personal or confidential information security incident involves: 1. Unauthorized or accidental access and/or use of Department data. 2. Unauthorized disclosure from, modification to, distribution or destruction of departmental automated or hardcopy files, data, or databases. 3. Damage to and misuse of Information Assets, or interference with information technology operations. 4. Attempts (failed or successful) to gain unauthorized access to a system or its data. 5. Unauthorized use of a system for the processing or storage of data. 6. Unauthorized changes to state protected assets, as defined in SAM 5320. 7. Theft, damage, destruction, or loss of state-owned information technology (IT) equipment or any electronic devices containing confidential, sensitive, or personal information. 8. Unauthorized access to confidential, sensitive, or personal information. 9. Theft, loss, damage, unauthorized destruction, unauthorized modification, or unintentional or inappropriate release of any state data (including electronic, paper, or any other medium) classified as confidential, sensitive, or personal. 10. Use of state information in commission of a computer crime. 11. Social engineering and requests for unauthorized information 12. Any other incidents that violate departmental, state or federal policies, regulations, or privacy laws resulting in the unauthorized access to or use of Department data.
Authority/References:
Page - 72 -
SAM Section 5320.3
October 2012
Related Information:
Notification of Security Breach Involving Personal Information Information Security Incident Response Team Manual (ISIRT) – available from the Information Security Office on a need to know basis.
IT Policy, Standards, Instructions and Guidelines References SP 800-86 Guide to Integrating Forensic Techniques into Incident Response SP 800-84 Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities
October 2012
Page - 73 -
IR-4 Incident Handling Lost Mobile Device Procedures Immediate Reporting If a Department-issued mobile device (BlackBerry® or similar PDA, iPhone®, iPad® or other tablet, laptop, mobile phone, IronKey or other secure USB flash drive, etc.) is lost, stolen or misused, immediately contact the following: DMV Enterprise Service Desk – (916) 657-7755 (during normal business hours) DMV Network Operations – (916) 657-7915 (after hours and weekends) This will generate a service ticket and have the equipment remotely turned off. The following information will also be requested: Division/Unit Reporting: Date Incident occurred: Incident Summary (General Description): Did you file a police report? If so, which law enforcement agency was it reported? What was the police report #? (It is required to have a police report number if a BlackBerry® is stolen.) The user’s manager is required to complete a DMV Information Security Incident Report EXEC 206 within three business days. Risks A BlackBerry® or similar PDA is an extension of a DMV e-mail account providing access from anywhere. An unsecured BlackBerry® or similar PDA is easily stolen, either for resale, to reconfigure to take advantage of its functionality or the stored e-mail information. Theft of a BlackBerry® or similar PDA within its time-out period leads to: Information loss: Any e-mail in the associated DMV e-mail account will be available to others. This could include sensitive DMV information and/or personal e-mails that may contain personal contact information, notes and e-mail addresses from personal and DMV address lists. Misuse: Anyone in possession of a BlackBerry® can use it to alter and forward e-mails, and/or send out derogatory e-mails or spam in the user’s name. IT Policy, Standards, Instructions and Guidelines References Handling and Reporting Information Security Incidents (DMV 145) SAM 5350
Incident Management
Information Security Incident Response Team Manual (ISIRT) – available from the Information Security Office on a need to know basis.
Page - 74 -
October 2012
IR-5 Incident Monitoring The Information Security Office maintains statistical data, acts as an executive and media relations advisor, and establishes the incident command procedures and structure. ISO will file the Security Incident Report (SIMM 65C) in accordance with SAM 5350).
IR-6 Incident Reporting
Information Technology Policy Notification of Security Breach Involving Personal Information Policy # Revised: Issue Date: Owner:
IS 2012-32 6/8/2006 Information Security Office
SAM SIMM: Supersedes:
APM 8.070
Purpose:
This policy establishes adherence to California Civil Code Section 1798.29, effective July 1, 2003.
Background/History:
Effective July 1, 2003, California Civil Code Section 1798.29 mandates the following: Upon discovery or notification of a security breach involving unencrypted personal information, any agency that owns or licenses that computerized data must disclose any security breach to the information’s owner or licensee. Any agency that maintains computerized personal data that the agency does not own must immediately notify the information’s owner or licensee of any security breach upon discovery.
Persons Impacted:
October 2012
This policy applies to all Department of Motor Vehicles (DMV) employees, contractors, consultants, and other workers at the DMV, as well as business partners and other external entities who have access to information maintained by DMV, and who become aware of a breach of unencrypted electronic personal information.
Page - 75 -
Policy:
It is the policy of the Department of Motor Vehicles (DMV) to notify victims when a security breach of any system is confirmed which has caused, or is reasonably believed to have caused, specific unencrypted personal information to be acquired by an unauthorized person(s). Unauthorized acquisition of personal information that would trigger notification includes an individual's first name or first initial and last name, in combination with any one or more of the following data elements, when either the name or the data elements are not encrypted: Social Security number. Driver's license number or California identification card number. Financial account number, credit or debit card number, in combination with any required security code, access code, or password that would permit access to an individual's financial account. The DMV reserves the right to expand the list of data elements considered "personal information."
Procedures:
Notification will be expeditious to enable victims to take actions to protect themselves against, or mitigate the damage from, identity theft or other possible harm. Delay in notification may be allowed for the following reasons: Legitimate needs of law enforcement if notification would impede a criminal investigation. Taking necessary measures to determine the scope of the breach and restore reasonable integrity to the system. Notice may be provided in writing, electronically (as consistent with provisions on electronic records and signatures per 15 USC 7001), or by substitute notice. Substitute notice may be used if the cost of providing individual notice is greater than $250,000 or if more than 500,000 people would have to be notified. The substitute notification methods are the following: E-mail when the e-mail address is available. Conspicuous posting on agency web site. Notification by major statewide media.
Page - 76 -
October 2012
Roles and Responsibilities:
Chief Privacy Officer: Works with the affected Data Resource Manager, the Chief Information Security Officer, and the Information Security Incident Response Team (ISIRT) on all verified security breaches. Data Resource Manager (DRM): After an initial investigation, the DRM immediately reports any confirmed breach of security of a system to the Chief Information Security Officer at the DMV and works as a customer liaison to ensure proper customer notification occurs following the breach. Information Security Office (ISO): Works with the affected DRM, the Chief Privacy Officer at the DMV, law enforcement agencies, and the ISIRT on all verified security breaches and reports. The ISO also maintains statistical data, acts as an executive and media relations advisor, and establishes the incident command procedures and structure. ISO will file the Security Incident Report (SIMM Section 65C) in accordance with SAM 5350).
Definitions:
Breach in the Security of the System: Unauthorized acquisition of computerized unencrypted personal information, as defined above, that compromises the security, confidentiality, or integrity of personal information maintained by DMV. Good faith acquisition of personal information by an employer or agent for the Department does not constitute a security breach, provided the personal information is not used or subjected to further unauthorized disclosure. Good Faith: An honest intent to act without taking an unfair advantage over another person.
Authority/References:
Budget Letter 03-03, Notification of Information Technology Incidents and Computer Crimes California State Office of Privacy Protection Website Customer Records, Sections 1798.82 - 1798.84 Handling and Reporting Information Security Incidents (DMV 145) Information Practices Act of 1977, Accounting of Disclosures, Section 1798.29 Information Technology-Code of Practice for Information Security Management, “Compliance, “ Standard 17799.12.1.4 IT Security Reporting Requirements, Chapter 5300, Section 5350.1 Information Security Incident Reporting Requirements
October 2012
Page - 77 -
Related Information:
Additional information is available from the California State Office of Privacy Protection in a document titled Recommended Practices on Notification of Security Breach Involving Personal Information – January 2012”. Information Security Incident Response Team Manual (ISIRT) – available from the Information Security Office on a need to know basis.
IT Policy, Standards, Instructions and Guidelines References APM 6.200 Theft or Misuse of Accountable Items or State Property APM 6.210
Theft or Loss of Sensitive Records and Materials
SAM 5350.1 Information Security Incident Reporting Requirements SAM 5350.2 Criteria for Reporting Incidents SAM 5350.3 Incident Follow-up Report SAM 5350.4 Incidents Involving Personal Information SP 800-61
Page - 78 -
Computer Security Incident Handling Guide
October 2012
Maintenance MA-1 System Maintenance Policy and Procedures IT Policy, Standards, Instructions and Guidelines References SPC 98-01 DMV IntraNet Policy IT 2007-01
October 2012
Information Technology Service and Support Request
Page - 79 -
MA-2 Controlled Maintenance
Information Technology Policy Effective Management of Data Processing and Information Technology Infrastructure Policy # Revised: Issue Date: Owner:
IS 2012-09 Unknown Information Security Office
SAM SIMM: Supersedes:
5320 Policy 6
Purpose:
Attention to the issues in this policy will ensure that the Information Systems Division (ISD) continues to meet its obligation to program managers and Information Asset users.
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
ISD Staff
Policy:
The availability of information to users is dependent upon how effectively data processing and the underlying information technology infrastructure operate. At DMV, ISD managers will establish and utilize operating policies and procedures addressing the following issues: 1. Work identification, project management, and communication processes that identify and classify all application development and maintenance work undertaken and communicate this information to program managers for prioritization and ranking. 2. Change control and migration standards that ensure orderly, coordinated changes to production systems. 3. A program testing policy that assures all programs placed into production have been adequately tested and approved by the responsible Data Resource Manager. 4. Production problem identification, prioritization, and resolution procedures that call for regular review, coordination, and prioritization by the responsible DRM.
Procedures: (must be a separate document)
Page - 80 -
Procedures to implement this policy are the responsibility of the Information Systems Division.
October 2012
Roles and Responsibilities:
ISD Deputy Director: Ensuring policy compliance with managers and staff. ISD Managers: Provide appropriate tools, training, and procedures to facilitate compliance with this policy.
Definitions:
None
Authority/References:
SAM Section 5320
Related Information:
None
IT Policy, Standards, Instructions and Guidelines References SAM 4946 Maintenance and Operations Plan Policy SAM 5001
Equipment Acquisition, Maintenance, and Disposition
SAM 5010
Policy
SAM 5101
Computer Programming Languages
SAM 5175.1 Operating Software, Utilities and Programming Aids SAM 5175.2 Application Packages SIMM 160
October 2012
Maintenance and Operations Plan Guidelines
Page - 81 -
MA-3 Maintenance Tools IT Policy, Standards, Instructions and Guidelines References NIST: SP 800-40 Procedures for Handling Security Patches
Page - 82 -
October 2012
Media Protection MP-1 Media Protection Policy and Procedures IT Policy, Standards, Instructions and Guidelines References Mobile Media Standards (PDF)
MP-6 Media Sanitization IT Policy, Standards, Instructions and Guidelines References MM 11-03 R1 Reduction of Cell Phones, Smartphones, and Cell Devices Pursuant to Executive Order B-1-11 and the Removal of Confidential, Sensitive, or Personal Information. Certification for Computing Media Sanitation SP 800-88
October 2012
Guidelines for Media Sanitization
Page - 83 -
Page - 84 -
October 2012
Personnel Security IT Policy, Standards, Instructions and Guidelines APM Chapter 5 – Safety and Health Management SAM 5325
October 2012
Human Resources Security
Page - 85 -
Page - 86 -
October 2012
Physical and Environmental Protection PE-1 Physical and Environmental Protection Policy and Procedures
Information Technology Policy Physical Security of Information Assets Policy # Revised: Issue Date: Owner:
IS 2012-18 Unknown Information Security Office
SAM SIMM: Supersedes:
Policy 17
Purpose:
The purpose of this policy is to identify methods and/or programs appropriate to establish auditability and accountability. This will help ensure DMVs information and information systems retain accuracy, integrity and confidentiality.
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
Template update: Not applicable or not available.
Policy:
DMV managers will oversee the security of all Information Assets and records within their areas of responsibility and provide for protection from inadvertent or deliberate alteration, disclosure, destruction, loss or theft.
Procedures:
Operational and office managers must identify critical areas at risk and develop procedures to adequately protect their Information Assets. Protective software and locking devices for computer components will be utilized in areas where system hardware or data are vulnerable to loss, manipulation or theft. Locking storage boxes are required for storage of removable media containing confidential or sensitive information. Purchase of the necessary security components may be made through the normal procurement cycle. Other physical security guidelines are: 1. Terminals that are visible to the public will be placed so that information on the screen may not be viewed by the public. 2. Terminals and computers in areas accessible to the public will not be left unattended while active.
October 2012
Page - 87 -
Procedures (continued):
3. Any computer, terminal, or peripheral containing unique identification codes for verification or authentication purposes will be secured against tampering. 4. Terminals and computer components, in areas accessible to the public, will be secured with cabling systems, enclosures, or kept in locked rooms. 5. Employees must have written permission from their supervisor to take computer equipment home. A record of each unit's loaned equipment will be kept on file by the unit manager.
Roles and Responsibilities:
Template update: Not applicable or not available.
Definitions:
Template update: Not applicable or not available.
Authority/References:
Template update: Not applicable or not available.
Related Information:
Security of Desktop and Mobile Computers and Related Materials and Equipment
IT Policy, Standards, Instructions and Guidelines ITPL 10-14 Data Center Assignments and Consolidation ITPL
09-04 Computer Room Construction
SAM 4982
Introduction
SAM 4982.1 Data Center Consolidation and Determination of Agency-Data Center Assignments SAM 4982.2 Policies for Data Center Management SAM 5330
Physical and Environmental Security
SAM 5355.3 Additional State Data Center Requirements SIMM 67
Data Center Consolidation Survey and Assessment
A Data Center Consolidation Survey and Assessment User Guide and Frequently Asked Questions B Data Center Consolidation Survey and Assessment Progress Report Template C Additional Frequently Asked Questions
Page - 88 -
October 2012
PE-2 Physical Access Authorizations Custodians Custodians have physical possession of the Information Assets. The custodians of the Information Assets ensure a secure physical and operational environment for storing and processing Information Assets and for the timely and correct disposal of information. The custodians will utilize hardware, software, and procedural solutions to satisfy the information security needs defined by the Data Resource Managers. The custodian for Information Assets stored on mainframe and departmental network systems is the Deputy Director, Division of Information Systems. The custodian of Information Assets stored on desktop and mobile computers and stand-alone local area networks will be authorized by the DRM and will operate by the security requirements as defined by the DRM. The custodians of non-automated Information Assets will comply with the operational and reporting requirements of the Information Practices Act. (Title 1.8, Chapter 1 of the California Civil Code.) IT Policy, Standards, Instructions and Guidelines SP 800-76-1 Biometric Data Specification for Personal Identity Verification
October 2012
Page - 89 -
PE-3 Physical Access Control
Information Technology Policy Security of Desktop and Mobile Computers and Related Materials and Equipment Policy # Revised: Issue Date: Owner:
IS 2012-38 3/2003 Information Security Office
SAM SIMM: Supersedes:
APM 8.300
Purpose:
Template update: Not applicable or not available.
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
Template update: Not applicable or not available.
Policy:
It is the policy of this Department that data processing equipment, related materials, and programs are the property of the Department and employees shall not use or remove such equipment or materials from DMV facilities for personal use.
Procedures:
Desktop and mobile computers, software, and data files shall be kept in as secure a work area as reasonably possible. Removable media shall be stored in locked files. Also, personnel who have access to software are prohibited from copying software from assigned workstations, except as authorized by contract or licensing agreement.
Roles and Responsibilities:
Deputy Directors and section heads of units utilizing desktop and mobile computers are responsible for providing controls over use of and access to computer equipment, sensitive data, and resources. Employees are to be informed of security measures as appropriate.
Definitions:
Template update: Not applicable or not available.
Authority/References:
Template update: Not applicable or not available.
Related Information:
Physical Security of Information Assets
Page - 90 -
October 2012
Information Technology Policy Desktop and Mobile Computer Security Policy # Revised: Issue Date: Owner:
IS 2012-20 Unknown Information Security Office
SAM SIMM: Supersedes:
APM 8.210, Policy 19
Purpose:
The Department relies heavily on desktop and mobile computers and the files they contain to accomplish critical functions. This makes it essential to protect desktop and mobile computers and the confidential and sensitive data they process.
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
All employees and contract staff using DMV desktop and mobile computers.
Policy:
To protect desktop and mobile computers and the information and programs they contain from theft, misuse, and/or unauthorized modification, alteration and disclosure, the following measures and actions will be taken: 1. Desktop and mobile computers will be located in secure areas where possible, or physically attached to desktops or tables. 2. Desktop computers shall be located in areas not readily accessible to the public wherever possible. Staff are encouraged to question the presence of outsiders in work areas and to report any unusual occurrences. 3. Desktop computers shall remain on the Department's premises and shall not be transported to an employee's home unless specifically approved by divisional management. 4. Only DMV approved and acquired software will be installed on departmental desktop and mobile computers. 5. All DMV desktop and mobile computer users will comply with software copyright laws and licensing agreements. 6. All data files will be regularly backed up.
October 2012
Page - 91 -
Policy (continued):
7. All programs and applications will be backed up whenever changed. 8. Any desktop or mobile computer with embedded storage media, such as a hard disk drive, that contains confidential or sensitive information will utilize a standard access control application to protect the information. 9. If sensitive files must be stored, removable media, such as an encrypted flash drive, is preferable to a non-removable medium. 10. Removable storage media containing confidential or sensityive information will be kept in a locked drawer or cabinet when not in use. 11. Mobile computers shall be kept under lock and key when not in use.
Procedures:
Security issues must be addressed during the needs analysis stage of any Feasibility Study Report (FSR) or Desktop and Mobile Computing Policy, proposing a solution utilizing desktop and mobile computers. Any analysis that proposes a solution that is not consistent with this policy must include a written justification for the exemption and be approved by the Chief Information Security Officer. DMV managers shall periodically review computer utilization in their work areas and ensure that the provisions of this policy are in effect. Conformity to the provisions of this policy will be evaluated as part of any operational review or management audit.
Roles and Responsibilities:
Refer to the relevant FSR or Desktop and Mobile Computing Policy.
Definitions:
Refer to the relevant FSR or Desktop and Mobile Computing Policy.
Authority/References:
None
Related Information:
Physical Security of Information Assets Security of Desktop and Mobile Computers and Related Materials and Equipment
IT Policy, Standards, Instructions and Guidelines References SP 800-116 A Recommendation for the Use of PIV Credentials in Physical Access Control Systems (PACS)
Page - 92 -
October 2012
PE-6 Monitoring Physical Access
Information Technology Policy Access to DMV Work Areas Policy # Revised: Issue Date: Owner:
IS 2012-19 Unknown Information Security Office
SAM SIMM: Supersedes:
Policy 18
Purpose:
DMV maintains confidential and sensitive data, in addition to costly equipment in all areas of the Department. Unauthorized access by the public, vendors, contractors, etc., could jeopardize the integrity of the information and the control of the equipment inventories, and in turn cause harm or embarrassment, loss of valuable time and prove costly to the Department. It is imperative that precautions be taken to prevent unauthorized entry to areas containing vital information and equipment.
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
Template update: Not applicable or not available.
Policy:
Access to all DMV work areas will be safeguarded to protect and preserve the integrity and quality of the Department's assets.
Procedures: (must be a separate document)
Screening of unknown or unauthorized persons in DMV work areas is the responsibility of all employees. Where identification (badges) is employed, enforcement is of extreme importance. Restriction of access to the main computer room and other areas that require access restrictions, such as Human Resources, will be maintained through the use of locking devices and badge reader mechanisms to all entry ways.
Roles and Responsibilities:
Template update: Not applicable or not available.
Definitions:
Template update: Not applicable or not available.
Authority/References:
Template update: Not applicable or not available.
Related Information:
Physical Security of Information Assets
October 2012
Page - 93 -
PE-9 Power Equipment and Power Cabling IT Policy, Standards, Instructions and Guidelines References Power Management and Shutdown Procedures ITPL
10-09 Power Management and Shutdown
Power Management and Shutdown Frequently Asked Questions ITPL
Page - 94 -
10-04 Low Power Office Computing
October 2012
System and Information Integrity SI-1 System and Information Integrity Policy and Procedures
Information Technology Policy Accountability for the Source of Information, Updates and Changes Policy # Revised: Issue Date: Owner: Purpose:
IS 2012-11 Unknown Information Security Office
SAM SIMM: Supersedes:
5320, 5320.1, 5320.3 Policy 8
The purpose of this policy, in conformance with standard, accepted business and audit practices, is to give the Department, and those who rely on its Information Assets, assurance of the integrity of the information utilized. DMV receives and electronically processes a vast amount of information every day. Some of that information starts out in another format prior to entry to the Department's data processing and information technology infrastructure. One example is a paper document entered into the Department's computer system by being scanned or manually keyed. It should be noted that this example is not the only method of updating data to DMV's information technology infrastructure and that careful thought should be given when determining the appropriate business and audit requirements in this area. The Department, other Government and Industry Partners and the public rely heavily on the assurance of the integrity of DMV's Information Assets in order to conduct daily business. A key part of providing that assurance is achieved by: Establishing the point at which information comes into DMV's possession; and Documenting pertinent details about its original form.
October 2012
Page - 95 -
Purpose: (continued)
Providing assurance of information integrity also includes the following: i. Knowing what changes are made; i. Knowing when changes occur; ii. Knowing who is making changes (additions, deletions and modifications); and Keeping the above history information for a time appropriate to business and audit requirements.
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
All employees and Government and Industry Partners that update data to or maintain DMV’s data processing and information technology infrastructure.
Policy:
When required by business needs, the Department shall document adequate information pertaining to the identity of the source of any information introduced to the computing environment and all additions, deletions, and/or changes to the Information Assets to establish individual accountability for those modifications. The documentation shall be retained for a time sufficient to satisfy business and audit needs.
Procedures:
1. When information introduced into DMV's computing environment is not processed in its original form, the following is documented either manually or electronically: Date and time of entry to the DMV system. Who entered information into the DMV system. Original or copy of information prior to entry into the DMV system. 2. Whenever a change, deletion or addition occurs to information that DMV processes or uses in the conduct of daily business, the following details will be documented manually and/or electronically: Date and time of change, deletion or addition. Who made the change, deletion or addition. What was changed, deleted or added.
Roles and Responsibilities:
Data Resource Manager (DRM): Develop and maintain the source data information required by this policy. Audits: Assist the DRM in determining the retention period.
Page - 96 -
October 2012
Definitions:
Government and Industry Partners The term used in this document for external personnel who access the DMV systems performing transactions (including inquiries) for their employer or for DMV.
Authority/References:
SAM Sections 5320, 5320.1, 5320.3
Related Information:
Security Information and Event Management Policy
IT Policy, Standards, Instructions and Guidelines References SAM 5320 Asset Protection SAM 5320.1 Ownership of Information SAM 5335.1 Information Integrity and Data Security SAM 5335.2 Personal Computer Security SP 800-53 Rev.4 Security and Privacy Controls for Federal Information Systems and Organizations SP 800-53 Rev. 3 Recommended Security Controls for Federal Information Systems and Organizations
October 2012
Page - 97 -
SI-3 Malicious Code Protection IT Policy, Standards, Instructions and Guidelines References SP 800-45 Guidelines on Electronic Mail Security SP 800-44
Guidelines on Securing Public Web Servers
SI-4 Information System Monitoring Diagnostic Tools Use of protocol analyzers, sniffers, and other diagnostic tools must be controlled through access controls and / or physical controls. These tools shall only be utilized by System Administrators and Telecommunication personnel and for the sole purpose of trouble shooting a Local Area Network system's problem, unless instructed otherwise by security personnel. IT Policy, Standards, Instructions and Guidelines References SP 800-94 Guide to Intrusion Detection and Prevention Systems (IDPS)
SI-7 Software and Information Integrity IT Policy, Standards, Instructions and Guidelines References FIPS 180—4 Secure Hash Standard (SHS) FIPS 198—1 The Keyed-Hash Message Authentication Code (HMAC) FIPS 197
Advanced Encryption Standard
FIPS 196
Entity Authentication Using Public Key Cryptography
SP 800-102
Recommendation for Digital Signature Timeliness
SP 800-92
Guide to Computer Security Log Management
SP 800-90 A Recommendation for Random Number Generation Using Deterministic Random Bit Generators SP 800-83
Guide to Malware Incident Prevention and Handling
SP 800-41 Rev.1 SP 800-32
Page - 98 -
Guidelines on Firewalls and Firewall Policy
Introduction to Public Key Technology and the Federal PKI Infrastructure
October 2012
SI-12 Information Output Handling and Retention
Information Technology Policy Data Transfer Policy # Revised: Issue Date: Owner:
IS 2012-21 11/24/1992 Information Security Office
Purpose:
SAM SIMM: Supersedes:
Policy 20
At the Department of Motor Vehicles, all applications for downloading or uploading data between microcomputers or network servers and mainframe computers must be reviewed by the Information Security Office and approved by the appropriate Data Resource Manager before being placed into production. The purpose of this policy is to ensure that DMV's Information Assets are uniformly protected appropriate to their classification.
Background/History:
It is crucial that the integrity and accessibility of DMV data be assured. Today's information processing needs often require the sharing and/or transfer of data between different computer systems, locations and organizations. In order to assure the integrity and accessibility of DMV's Information Assets, it is extremely important that the security in the original environment be maintained at the same level or better as the data travels through, and is processed and stored in, different environments. It should be noted that this policy applies to all DMV information on all media, not just electronically stored assets.
Persons Impacted:
Database administrators, testers, Government and Industry Partners and other staff that create, read, update, delete DMV data.
Policy:
A security evaluation and Data Resource Manager approval will be required in instances where information is being moved from its current environment and protections into or through different environments.
Procedures: (must be a separate document)
Microcomputer Data Transfer Application Procedures
October 2012
Page - 99 -
Roles and Responsibilities:
The Information Security Office will periodically review approved data transfer processes to verify user needs are being met and to help assess whether the process should be continued, expanded, or discontinued.
Definitions:
Government and Industry Partners The term used in this document for external personnel who access the DMV systems performing transactions (including inquiries) for their employer or for DMV.
Authority/References:
None
Related Information:
Classifying and Handling Information
Page - 100 -
October 2012
Procedures Title: Microcomputer Data Transfer Application Procedures Owner: Information Security Office Issue Date: SAM/SIMM: Revision Date: POLICY Data Transfer PROCEDURES Request for a New Data Transfer Process or to Change an Existing Process New Computer Data transfer Applications and requests to change an existing process, except for file name or User changes, require review by the Chief Information Security Officer and approval by the appropriate Data Resource Manager (DRM) or Managers. When the hardware or software needed to allow the data transfer is already in place, the completed application must be submitted at least 15 calendar days in advance of the planned implementation date to allow for review and approval and to have ISD make the necessary system or network changes to enable the transfer process. The Computer Data Transfer Application must be approved before any hardware or software needed to support the process can be purchased. If the purchase and installation of hardware or software will be required, the Computer Data Transfer Application must be submitted and approved early enough for the purchase to be processed and the hardware and software installed and tested before implementation.
October 2012
Page - 101 -
Application Process There are two categories of data transfer: The transfer of information between a mainframe computer and network server to permit data manipulation in support of user processing and/or reporting. This category is generally initiated by the Requester. The transfer of information between a mainframe and a network server as part of a Priority Memo based ISD business application development project. This category is generally initiated by ISD Application Development. Approval for each of these types of data transfers is achieved using the following steps: 1. The Requester identifies a data transfer need. A Data Transfer Application and Security Requirements Evaluation is completed. If the application is being submitted prior to the installation of hardware or software needed to perform the data transfer, the hardware and software expected to be used should be listed in Section K or the application. The Requester submits the application to their operational or program manager for approval. If the application is prepared by Application Development staff on behalf of a User, the application will be coordinated through the User's management. If management approves the application, it is forwarded to the Chief Information Security Officer (ISO). 2. The ISO reviews the Data Transfer Application and Security Requirements Evaluation for technical validity and adequacy. If additional information is needed to complete the Security requirements Evaluation, the ISO works with the Requester to complete the evaluation. When the Security Requirements Evaluation is complete, the ISO sends the application to the DRM. 3. The DRM reviews the analysis and either approves the application and forwards it to the ISD System Access Coordination (SAC) Unit or does not approve the application and returns it to the Requester with the reason for nonapproval and also notifies the ISO. 4. SAC makes the necessary system or network changes that enable the data transfer process. If new hardware or software is required, SAC notifies the Requester that the required products can be ordered. When the necessary system or network changes that enable the data transfer have been completed, SAC initials and dates the completed application and sends a copy to the Requester and the DRM(s) as notification that the requested changes have been made. SAC files the completed Data Transfer Application. Adding or Deleting Files or Personnel to an Existing Data Transfer Process When file name changes create the need for newly named or renamed files to be added, or unneeded files are to be deleted from a data transfer process and/or data transfer personnel need to be added or deleted from an existing data transfer process, notification of the changes will be by written memo at least one week before the implementation date. An original request application must be used to expand Data transfer authority to additional files beyond those approved by the DRM.
Page - 102 -
October 2012
Addition and/or Deletion Process The Requester sends a memo, along with a copy of the original Data Transfer approval to SAC with a copy to the DRM(s). The memo must reach SAC at least one week before the planned implementation date. For file changes, the memo will specify the mainframe computer file names to be added to and/or deleted from the Data Transfer process. For personnel changes, the memo will specify the name and UserID of the persons to be added and/or deleted. If personnel need UserIDs assigned or deleted, the form ISD 100 must be competed and appropriately routed. SAC makes the necessary system or network changes. When the necessary system or network changes have been completed, SAC notifies the Requester and the DRM(s). SAC initials, dates, and files the completed request memo. Discontinuing a Data Transfer Process When an existing data transfer process is to be discontinued, written notification must be given at least a week before the termination date. Termination Process The Requester sends a written memo to SAC with a copy to the DRM(s). The memo must reach SAC at least one week before the planned termination date. If hardware or software needs to be removed, the Requester will send a written memo to the appropriate unit (i.e., Telecommunication Planning for terminal removal) for action. SAC makes the necessary system or network changes. When the necessary system or network changes have been completed, SAC notifies the Requester and the DRM(s). SAC initials, dates, and files the completed request memo. All documentation or terminated requests retained by SAC, the DRM, or the Requester can be purged after two years. DEFINITIONS (if different than policy) Not applicable. AUTHORITY/REFERENCES (if different) Not applicable. RELATED INFORMATION (if different) Microcomputer Data Transfer Application
October 2012
Page - 103 -
Page - 104 -
October 2012
Technical Access Control AC-1 Access Control Policy and Procedures
Information Technology Policy Access Control Administration Policy #: Revised: Issue Date: Owner Purpose:
IS 2012-01 03/2012 April 11, 2012 Information Security Office
SAM SIMM Supersedes:
5340 Policy 15
The administration of access control systems at DMV is a primary method for managing system availability and accessibility. Effective access control administration ensures: 1. DMV employs the concept of least privilege, allowing only authorized accesses for users (and processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions. Therefore, users of DMV information receive only information and access necessary to complete daily job related tasks; 2. The confidentiality, integrity and availability of DMV's Information Assets; 3. Accountability for transactions using DMV information; 4. That when the operational needs of the user require quick response to non-technical administration functions, they will be decentralized to divisions or programs; 5. Changes needed by user management can be made without unnecessary delays; and 6. The integrity of access control tables and files. Centralized administration of access control ensures consistent application of policy and procedure, rules out duplication of effort, eliminates the occurrence of users with multiple UserIDs and access authorities, and assures that only experienced, properly trained
October 2012
Page - 105 -
Purpose (continued):
individuals are performing highly technical administrative duties. The integrity of the Department's Information Assets is best assured by a centralized access control administration function. Administration of the technical aspects of access control must be done properly by practiced, knowledgeable personnel. Errors in these functions can jeopardize system availability and accessibility and expose our networks and systems to users who inappropriately have access to information technology infrastructure beyond what is authorized. Non-technical administrative duties, such as resetting passwords and moving users between groups, can be decentralized in some systems.
Background/History:
Persons Impacted:
2012 Revision: Adds the term least privilege to the Purpose section as that is the term to describe limiting users to receive only the information necessary to complete job related tasks. Least privilege is the generally accepted term. It is also one of the security controls identified in the National Institute of Standards and Technology (NIST) Special Publication 800-53: Recommended Security Controls for Federal Information Systems and Organizations. (The State Administrative Manual provides direction for departments to follow the Federal Information Processing Standards (FIPS). State agencies are directed to use FIPS standards, which fall under National Institute of Standards and Technology (NIST) in their information management planning and operations.) This policy affects all employees and others who access, store or transmit DMV information and information resources. This policy applies to persons performing access control administrative functions for enterprise or subsidiary systems, e.g., DMV’s financial systems not administered by the System Access Coordination (SAC) Unit.
Policy:
Page - 106 -
Access control administration will be centralized for DMV's systems and networks. However, some access control functions may be decentralized when these functions can be distributed in a manner that restricts local administrators' capabilities to only the users for whom they are responsible. All access control administrators will ensure that Department information security policies and standards are followed.
October 2012
Procedures:
SAC, in the Information Systems Division (ISD) maintains procedures, i.e., the ISD 100 process, on the departmental network drive. Data Resource Managers (DRMs) will maintain the procedures for their respective systems with decentralized access control. The Communication Programs and Registration Operations Divisions, respectively, will maintain procedures for external entity and business partner access. Standards for administering access control systems at DMV are the responsibility of the Information Security Office (ISO). (UserID and Password Standards.)
Roles and Responsibilities:
SAC will provide the approved access authority to the requester and notify the requester when access is available for centralized access control administration. DRMs authorize access to the information stored in their respective database or files. The Business Partner Automation Program Unit authorizes access for business partners (California Code of Regulations Title 13, Article 3.6) upon completion of an ISO approved application. The Electronic Access Administration Unit (EAAU) is responsible for the enrollment, authorized access, and connectivity of government and commercial account holders that request, renew, or modify online access to the Department.
Definitions:
Least Privilege: allowing only authorized accesses for users (and processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions.
Authority/References:
SAM 5340 Access Control NIST SP 800-53: Recommended Security Controls for Federal Information Systems and Organizations
October 2012
Page - 107 -
Related Information:
Acceptable Use Statement - DMV 350. While Least Privilege gives the user only access to the data or systems that the user needs to perform his legitimate business need, a related fundamental principle of security is Separation of Duties (SOD). The simplest definition of the principle of SOD is to require a different user to perform each step of a sensitive task that is comprised of more than one step. Accounting practitioners have long employed SOD to deter fraud and hinder collusion. NIST SP 800-53 provides the following technology-based definition of SOD: (i) mission functions and distinct information system support functions are divided among different individuals/roles; (ii) different individuals perform information system support functions (e.g., system management, systems programming, configuration management, quality assurance and testing, network security); (iii) security personnel who administer access control functions do not administer audit functions; and (iv) different administrator accounts for different roles.
Page - 108 -
October 2012
UserID and Password Standards2 Roles and Responsibilities 1. Data Resource Managers authorize access to DMV information based on the requester's need for this information. 2. Users will only access DMV systems and networks using assigned user identifiers and passwords and take reasonable precautions to maintain the secrecy of their passwords. 3. The System Access and Control unit tracks and provisions requests for access. General i. Individuals authorized for accessing a DMV administered system will be assigned a User ID. ii. Normally, each user will be issued only one User ID. iii. More than one User ID may be assigned to users performing functions such as testing and server administration. If a user is issued more than one User ID, the User ID must only be used for the purpose for which it was assigned. For example, a server administration account may not be used to access e-mail, access the Internet, etc. iv. User IDs will be assigned to individuals not job locations. v. "Group" User IDs will not be issued. vi. User IDs may only be used for DMV network access, not as a UserID for another log in account, such as a web-based subscription. Issuing User ID User IDs for DMV employees will begin with the "MV" or "MW" prefix, based on job function, followed by the initials of the individual's first, middle, and last name. Individuals with identical initials will be differentiated with a numeric suffix. A "default" password, known only to the user (such as mother's maiden name) will be established for purposes of resetting a password. (For RACF only.) User IDs will not change regardless of an individual's marriage, divorce, name changes etc. Non-Use A user account will be disabled after 90 days of non-use. A user account will be deleted after 150 days of non-use. User IDs may be reassigned after 4 years of non-use.
2
Previously Appendix F.
October 2012
Page - 109 -
DMV Password Standards Network Access Password Standards General Users All user accounts must have expiring passwords. Passwords must be at least 8 characters in length. The password contains characters from at least three of the following four categories: English uppercase characters (A - Z) English lowercase characters (a - z) Base 10 digits (0 - 9) Non-alphanumeric (For example: !, $, #, or %) The password does not contain three or more characters from the user's account name. Passwords used to access DMV network resources may not be used to access non-DMV resources in combination with the user’s DMV-issued e-mail account. System Administrators Also known as x-accounts. Passwords must be at least 14 characters in length. Remaining General User requirements still apply. Service Accounts All service accounts must have expiring passwords. Service account passwords must be updated annually or with changes in key personnel, whichever occurs first. Unsuccessful Logon User accounts will be locked out after 5 unsuccessful password attempts. A locked user account will be automatically reset after 30 minutes. Changes Passwords must be changed at least every 45 days. Passwords cannot be reused for 24 iterations. After a password change, that password cannot be changed again for 2 days. However, if necessary an administrator can override and reset the password.
Page - 110 -
October 2012
Password Standards RACF until deployment of the z/OS Platform Password Enhancement Project General Passwords must be at least 5 characters in length. All user accounts must have expiring passwords. Passwords must be changed at least every 35 days. Passwords can be any combination of alpha, numeric or special characters. Unsuccessful Logon User accounts will be locked out after 3 unsuccessful password attempts. A locked account must be reset by an administrator. Changes After a password change, that password cannot be changed again for 2 days. However, if necessary an administrator can override and reset the password. Passwords cannot be reused for 32 iterations. Password Standards RACF after deployment of the z/OS Platform Password Enhancement Project General Passwords must be exactly 8 characters in length. Passwords must be case sensitive and must include three of the following four characters: a) one alpha uppercase b) one alpha lowercase c) one numeric d) one special character (# @ or $) Passwords must begin with an alphabetic character. Passwords cannot be reused for 32 iterations. Unsuccessful Logon User ID must be disabled after three (3) consecutive unsuccessful password attempts. Reset A locked user account must be reset by an administrator. Changes Passwords must be changed at least every 90 days. Password change interval is 15 days minimum. Non-Use Inactive user IDs must be automatically disabled after 90 consecutive days of non-use.
October 2012
Page - 111 -
Strong Password Tips General Tips to Creating Strong Passwords An ideal password is long and has letters, special characters, and numbers. Whenever possible, use at least 14 characters or more. The greater the variety of characters in your password, the better (even spaces, if allowed). Use the entire keyboard, not just the letters and characters most often used or seen. Create a strong password you can remember There are many ways to create a long, complex password. Here are some ways to make remembering it easier: What to do
Suggestion
Example
Start with a sentence or two (about 10 words total).
Think of something meaningful Long and complex passwords to you. A song lyric, lines from are safest. I keep mine secret. a poem, speech, or other (10 words) favorite saying.
Turn your sentences into a row of letters.
Use the first letter of each word.
Add complexity.
Make only the letters in the first lACpAsIKMs half of the alphabet uppercase. (10 characters)
Add length with numbers.
Put two numbers that are lACpAs56IKMs meaningful to you between the (12 characters) two sentences.
Add length with special characters.
Put a special character at the beginning.
lacpasikms (10 characters)
!lACpAs56IKMs (13 characters)
Common password pitfalls to avoid Dictionary words in any language. Words in all languages are vulnerable. Words spelled backwards, common misspellings, and abbreviations. Sequences or repeated characters. Examples: 12345678, 222222, abcdefg, or adjacent letters on your keyboard (qwerty). Personal information.
Page - 112 -
October 2012
Your name, birthday, driver's license, passport number, or similar information Passwords associated to you or your interests. Examples: Hobbies, professional associations, clubs, favorite artist/singer/actor. Protect Your Password Avoid writing it down. Add a “contact” to your contact list or cell phone that includes a clue to your password. For example, in the “Note” field for the contact, add “Saint Patrick’s Day” if your password is $ta1ntPatr1ck$Day. Passwords to Avoid According to an article in InfoWorld on November 22, 2011, organizations need to steer users away from common, weak passwords, including such standbys as '123456' and seemingly random names. The top 25 list is below. 111111 654321 123123 abc123 123456 ashley 1234567 bailey 12345678 baseball Create Multiple Passwords
dragon football iloveyou letmein master
michael monkey passw0rd password qazwsx
qwerty shadow sunshine superman trustno1
Using one universal password to open all personal accounts may be convenient and easy to manage -- but extremely unsafe. Consider the absurdity of using a single key to open our home, our car, or our gym locker. Likewise we should consider creating different passwords for different activities. For example, create one password for each grouping type: Work related Financial (on-line banking, financial files on your personal computer) On-line shopping On-line subscriptions Social networks Free e-mail services, such as Yahoo and Google. Low security applications, such as reading on-line newspapers and accessing entertainment web sites. Related Information (Links) Acceptable Use Statement (DMV 350) DMV’s Password Station Payment Card Industry Data Security Standard (PCI DSS)
October 2012
Page - 113 -
IT Policy, Standards, Instructions and Guidelines References ITPL 10-17 Establishment of the Identify and Access Management (IdAM) Policy FIPS 185
Escrowed Encryption Standard
FIPS 190
Guideline for the Use of Advanced Authentication Technology Alternatives
SAM 4804
Access to Information by the Office of the Legislative Analyst
SAM 4806
Access to Information by the California State Auditor
SAM 5340
Access Control
SP 800-146
Cloud Computing Synopsis and Recommendations
SP 800-145
A NIST Definition of Cloud Computing
SP 800-144
Guidelines on Security and Privacy in Public Cloud Computing
SP 800-77
Guide to IPsec VPNs
Page - 114 -
October 2012
AC-2 Account Management Access Control Delegated Administration Standards3 Delegated Administration Definition: For the purpose of this standard, Delegated Administration (DA) is defined as the secure distribution of provisioning tasks, whether manual or automatic among various divisions or organizations. Delegated Administration allows the responsibilities for using and changing certain access privileges to be pushed down the Department's hierarchy in a secured controlled manner, and on a need to know basis. Non-technical administrative duties, such as access requests, create and disable user accounts, resetting passwords and moving users between groups, can be assigned to individuals within the framework created by the Department. Delegated Administration Requirements: These requirements are designed to protect the DMV information resources and effectively minimize their potential exposure. The following requirements shall be implemented to ensure the necessary protection. 1. There shall be a centralized identity management and policy enforcement system that reduces the risks of unauthorized users or applications receiving inappropriate access to specific systems or resources. 2. There shall be a strong authentication process across client-server, Web, and Web services environments to identify the user, devices or applications. 3. There shall be secure audit and workflow capabilities for business approval processes and to identify managers who are accountable for these approvals. 4. The architecture shall be flexible enough to enable the Department to easily add incremental security to further enhance information confidentiality, integrity, accountability, and access controls. 5. The establishment of Delegated Security Administration capability must be based upon a complete "contractual agreement" to ensure the appropriate level of trust by providing confidentiality, integrity, availability and accountability of DMV information systems and resources in every step of the business process. 6. There shall be processing workflows which enforce business rules and identify appropriate division of roles and responsibilities. 7. Trusted Identification Methods shall be standardized and consistently applied to all DMV User Accounts.
3
Formerly Appendix J.
October 2012
Page - 115 -
8. All Administrative Roles, Application Owners, and Entitlement Delegated Administrators will use special accounts which are created solely for the purpose of DA. All DMV administration accounts are unique and are assigned to individuals, not groups. 9. There shall be appropriate tools and database design to support multiple Delegated Administrator roles, enforcing multiple authorization business processes and multiple levels of policy enforcement depending upon the different business audiences involved. 10. There shall be appropriate audit logging and audit log querying to monitor and investigate the effectiveness and integrity of the delegated administration capability and its compliance with the "Contractual Agreement" for business transactions.
AC-4 Information Flow Enforcement
Information Technology Policy Information Access Policy # Revised: Issue Date: Owner:
IS 2012-12 Unknown Information Security Office
Purpose:
SAM SIMM: Supersedes:
Policy 10
Availability and reliability of DMV information are essential elements in the Department's business strategy to support governmental and business information processing environments. Authorized access to DMV's information records will not unnecessarily restrict this strategic objective. Information is classified "confidential" when it should be protected against unauthorized access (access not consistent with state and federal law or departmental policy). The specific user accessing the information must be positively identified and authorization to access the data must be verified before access is granted. Access control may be assured through a combination of hardware, software, system security or application based solutions. Sensitive information requires a higher than normal assurance of accuracy and completeness that necessitates special precautions to protect against unauthorized modification or deletion.
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
Data Resource Managers System Access Coordination
Page - 116 -
October 2012
Policy:
Access to DMV information will be authorized by the appropriate Data Resource Manager and will be based on the requester's need for this information. The controls required to authorize access to a database resource will be based on the classification structure of the data resource. Access control to public information through any telecommunications or other network will be administered through the use of a UserID, a password, and positive verification by the Department that the user's group (unit, agency, business, etc.) is authorized to access the information. Confidential and sensitive information access will also be authorized by the appropriate Data Resource Manager (or designee) to selected individuals or groups who (1) are legally entitled to the information, and (2) need the information to complete job related tasks.
Procedures:
Procedures for authorizing access to DMV information will follow the process described below except for Information Services Branch customers. The Data Resource Manager has delegated access approval for the Government and Industry Partners. The ISD 100 (System Access Control), will be used for all requests to access DMV Information Assets. The request will be approved by the manager responsible for the requester and forwarded to the appropriate Data Resource Manager for approval. The Data Resource Manager may delegate approval authority to subordinates or specific user managers. Upon approval, the Systems Access Coordination (SAC) Unit, in the Information Systems Division, will provide the approved access authority to the requester and notify the requester when access is available.
Roles and Responsibilities:
Data Resource Manager (DRM): Classify and authorize access to data. System Access Coordination (SAC) Unit: Provide the approved access authority to the requester and notify the requester when access is available. SAC also will maintain a file of approved requests.
Definitions:
Template update: Not applicable or not available.
Authority/References:
SAM Sections 5320-5320.5
Related Information:
Access Control Administration Classifying and Handling Information
October 2012
Page - 117 -
IT Policy, Standards, Instructions and Guidelines References FIPPS 188 Standard Security Label for Information Transfer SAM 5320.2 Responsibility of Owners of Information SAM 5320.4 Responsibility of Users of Information SP 800-123
Guide to General Server Security
AC-5 Separation of Duties Network drops, outlets, etc. Only authorized personnel and devices shall be connected to a network outlet. This includes wireless access ports. IT Policy, Standards, Instructions and Guidelines References SP 800-142 Practical Combinatorial Testing
AC-17 Remote Access Modems If dial-in/dial-out function (modems) is required for Local Area Networks, a three-part security standard is mandatory. A three-part security standard is a combination of a UserID, a password and a token or dial back type of technology. The token or dial back type of technology requirement should be incorporated into the Desktop and Mobile Computing Form. Remote Access Standards4 Remote Access Definition For the purpose of this standard, remote access is defined as the ability to access the DMV network from a remote location. The remote device or computer system connected to the Department's network becomes an extension of the DMV network, and shall be subject to the same or similar protective measures. Protective measures include, but are not limited to: system hardening, using firewall technology, keeping the computer's operating system and applications updated with the most current patch levels or security updates, use of effective anti-virus protection, eliminating the use of file sharing, and removing unnecessary services, open ports, etc. Remote access devices include, but are not limited to: workstations, servers, printers, portable computers, Personal Digital Assistants (PDAs), smart phones, tablets, and any other existing or future device that can be used to connect to the DMV network.
4
Formerly Appendix H.
Page - 118 -
October 2012
Remote Access Requirements These requirements are designed to protect the DMV information resource and effectively minimize the potential exposure. The following requirements shall be implemented to ensure the necessary protection. 1. Individuals requiring remote access to DMV will complete the ISD 325, Secure Token for Remote Access form and obtain approval from their unit manager, their division Deputy Director, the Chief Information Security Officer, and the ISD Assistant Deputy Director. 2. The remote access session shall be authenticated with a two-factor scheme. For example, the SecureID token and the UserID/password is the typical connection model. Another example is a VPN using a certificate and the UserID/password. 3. Electronic transmissions shall be reasonably protected. Examples include using direct connect lines, Citrix using ICA protocol, and VPN encrypted tunnels. 4. A DMV employee must use DMV-owned equipment, unless the access is via the Citrix model. For other remote access users, the preferred method is DMV-owned equipment; however, reasonable accommodations can be made where compliance is verified. 5. Access shall be restricted according to existing business rules and in accordance to existing access control policy. The access control can include restricting the hours and days of the week that remote access is authorized. 6. All remote access hosts shall comply with existing statute and policy pertaining to software licenses and copyright material. For further details, see the Software Management Policy (IT Policy #2003-01) and the July 2004 Advisory regarding Sound and Audio-Visual Copying. 7. Non-authorized wireless connections and communications are prohibited. 8. Individuals or external entities not using the Citrix model shall comply with the following requirements.5 i. All remotely connected devices, including DMV-owned devices, personal devices, and third- party owned devices, shall meet the requirements. ii. The remotely connected device shall have anti-virus software installed, set to scan automatically, and reside in memory at all times. The most recent virus update shall be employed prior to remote access connection. iii. The remote device shall have undergone protective system hardening measures. For example, all unneeded services and ports shall be removed or secured, and vulnerability scans with corrective actions must take place. Detailed information for particular devices can be researched on the internet (e.g. www.sans.org). iv. The remote device shall continue to maintain the most current patch levels and security updates for its operating system and applications. Since the updates cannot occur remotely, the user must bring in the laptop and plug it into the DMV network. Laptops shall be updated at least once a month. v. All computing devices remotely connected to the DMV network must use firewall technology. A single device connecting to DMV must utilize, at a minimum, a personal firewall. Networked devices, such as those on a home or other remote networks, must
5
Although not required for user-owned equipment, these safeguards are also prudent for home use.
October 2012
Page - 119 -
utilize either personal firewall software on each device, or perimeter hardware/software firewall devices. See the Firewall Security Policy for more detailed information. vi. Operating shielding product shall be installed to protect against errant behavior and infectious spread of newly introduced malware to connecting systems. Note: The operating shield and the firewall technology can be incorporated into one product. vii. Spyware blocker in protective mode. 9. Remote access accounts are for active employees, vendors, contractors, or employees of authorized external entities only and must be disabled upon employment/ contractual termination. 10. Remote access shall be logged in accordance with the Transaction Auditability policy. 11. Remote users shall be made aware of acceptable use and confidentiality practices. Prior to access authorization, remote users complete the Telework/Remote Access Security Standard Training. 12. Split tunneling to the Internet is not allowed. Therefore, the client cannot connect one open session to the Internet; and then, with another open session, log onto the DMV network. 13. Split tunneling to the Local Area Network (LAN) is allowed on an "as needed" basis. The LAN resource that the workstation must interface with shall be explicitly defined (e.g. IP address) in the connection rule set. Therefore, the client is limited to the LAN while it is logged onto the DMV network. Third Party Access6 Third party is defined as an entity that needs physical and/or remote access to the DMV network to provide services for DMV and is not a formal or subsidiary part of DMV. The security objective is to maintain the confidentiality, integrity, and availability of DMV information processing facilities and Information Assets accessed by third parties. Access to DMV's network by third parties shall be controlled and monitored. Where there is a business need for such third party access and procedures are not in place, a risk assessment shall be carried out to determine security implications and control requirements. Controls should be agreed upon and all aspects of third party access shall be clearly defined in a contract with the third party. Third party access may also involve other participants. Contracts conferring third party access should include allowance for designation of other eligible participants and conditions for their access. This standard could be used as a basis for such contracts and when considering the outsourcing of information processing. Information might be put at risk by access from third parties with inadequate security management. Where there is a business need to connect to a third party location, a risk assessment shall be carried out to identify any requirements for specific controls. It should take into account the type of access required, the value of the information, the controls employed by the third party, and the implications of this access to the security of the DMV's information and network system.
6
ISO/IEC 17799:2000(E) Section 4.2--Security of third party access
Page - 120 -
October 2012
On-site Contractors Third parties that are located on-site for a period as defined in their contract may also give rise to security weaknesses. Examples include: 1. hardware and software maintenance and support staff; 2. building facilities, utility support, cleaning, security guards, and other outsourced support services; 3. student placement, retired annuitants, and other short term appointments; 4. consultants. All third parties shall comply with the Remote Access Requirements as previously specified. In addition, third parties bringing laptops and other devices into the DMV network shall also comply with the existing policies and standards. (See the Mobile Media Standards for more detailed information.) Third party requests to provide remote access from the DMV network to third party network shall be authorized by the contracting agent and approved by the DMV Chief Information Officer and the Chief Information Security Officer. All security requirements resulting from third party access or internal controls should be reflected by the third party contract. The DMV contract administrator shall have the responsibility to ensure the requirements and controls are included in the contract, MOU (Memorandum of Understanding), or similar agreement document. Access to information and information processing facilities by third parties should not be provided until the appropriate controls have been implemented and a contract has been signed defining the terms for the connection or access. Tele-Workers DMV employees authorized to telecommute using the DMV network must adhere to ITPL 10-03 Telework and Remote Access and Telework and Remote Access Security Standard. A DMV employee must use DMV-owned equipment, unless the access is via the Citrix model. Suitable protection of the telecommuting site must be in place against vulnerabilities such as theft of equipment and information, unauthorized disclosure of information, unauthorized remote access to the organization's internal systems, or misuse of facilities. The DMV will only authorize telecommuting activities if appropriate security arrangements and controls are in place and that comply with the organization's security policy. The following physical security concepts should be considered at the telecommuting site: The physical security of the building and the local environment. The proposed telecommuting environment. The communications security requirements, the need for remote access to the organization's internal systems, the sensitivity of the information that will be accessed and passed over the communication link, and the sensitivity of the internal system. The threat of unauthorized access to information or resources.
October 2012
Page - 121 -
Remote Access Procedures Procedures Title:
Remote Access Procedure
Owner:
Information Security Office
Issue Date:
February 10, 2011
SAM/SIMM:
ITPL 10-03
Revised:
July 26, 2011
Step 1
When requested, the manager determines if an employee needs remote access to perform his or her job duties.
Step 2
Once approved, the employee must complete the Telework/Remote Access Security Standard Training; no remote connections will be allowed until this training is completed and the verification forwarded to the divisional training coordinator.
Step 3
Pursuant to divisional procedures, an ISD 325 form to receive a secure token must be completed and submitted to the System Access Coordination (SAC) Unit. If the remote access is for Outlook Web Access (OWA) only, then an ISD 100 (System Access Control) must be completed and submitted to the SAC Unit. SAC will contact the employee to pick up the secure token when it is ready; at that time, the employee will receive instructions for remote access connectivity.
Step 4
If remote desktop, and/or any other applications are also approved, follow divisional procedures and complete an ISD 100 (System Access Control) to be added to the Remote Desktop Users AD Group. Submit the completed form to the System Access Coordination (SAC) Unit.
Step 5
If the employee needs a DMV-owned computer, a remedy ticket must be started
Step 6
The employee must adhere to the Laptop Tracking Policy, and Remote Access Standards established by the DMV, and the policies and standards established by the California Technology Agency. Any violation of these policies and standards will result in the loss of the employee’s remote access privilege.
Note:
Exceptions must be submitted in writing via the Policy Exception Request (EXEC 205) form and signed by the divisional Chief of Staff, for approval by the DMV Information Security Office.
Page - 122 -
October 2012
IT Policy, Standards, Instructions and Guidelines References ITPL 10-19 Smartphone and Other Mobile Computing Device Security ITPL
10-03 Telework and Remote Access
SIMM 66
Information Security Standards
A Telework and Remote Access Security Standard SP 800-137
Information Security Continuous Monitoring for Federal Information Systems and Organizations
SP 800-114
User's Guide to Securing External Devices for Telework and Remote Access
SP 800-113
Guide to SSL VPNs
SP 800-95
Guide to Secure Web Services
SP 800-46
Guide to Enterprise Telework and Remote Access Security
AC-18 Wireless Access Wireless technology is prohibited on the DMV LAN/WAN unless specifically authorized by the DMV Chief Information Officer and the DMV Chief Information Security Officer except in the following instances: Wireless access may be enabled on State issued devices to allow the use of a VPN client (e.g., CISCO VPN Client) or comparable protocol. Users that access the Internet on a State issued device may only do so through the VPN. Wireless access may be allowed on a non-State issued device (e.g., laptop, tablet, PDA) to remotely access DMV's network resources using currently authorized secure web connection. (E.g., Citrix with SSL) Cellular routers (e.g., Digi Connect® WAN cellular/WiMAX routers) may be used to remotely access DMV's network resources when used in combination with other authorized equipment (e.g. thin client, printer, monitor, keyboard, mouse) to conduct routine or one time outreach. The authorized equipment must be appropriately hardened to meet or exceed current security standards (e.g., port, firewall and switch settings.) IT Policy, Standards, Instructions and Guidelines References SP 800-127 Guide to Securing WiMAX Wireless Communications SP 800-121
Rev. 1 Guide to Bluetooth Security
SP 800-120
Recommendation for EAP Methods Used in Wireless Network Access Authentication
SP 800-111
Guide to Storage Encryption Technologies for End User Devices
SP 800-48
Guide to Securing Legacy IEEE 802.11 Wireless Networks
October 2012
Page - 123 -
AC-19 Access Control for Mobile Devices
Information Technology Policy Mobile Devices Policy # Revised: Issue Date: Owner:
IS 2012-36 Planned for 2012 6/2006 Information Security Office
SAM SIMM: Supersedes:
APM 8.160
Purpose:
The purpose of this policy is to establish an authorized method for controlling mobile computing and storage devices that contain or access information resources at the Department of Motor Vehicles (DMV).
Background/History:
With advances in computer technology, mobile computing and storage devices have become useful tools to meet the business needs at the DMV. These devices are especially susceptible to loss, theft, hacking, and the distribution of malicious software because they are easily portable and can be used anywhere. As mobile computing becomes more widely used, it is necessary to address security to protect information resources at the DMV. DMV employees, consultants, vendors, contractors, students, and others who use mobile computing and storage devices on the network at the DMV.
Persons Impacted:
Policy:
It is the policy of the Department of Motor Vehicles (DMV) that mobile devices containing or accessing the information resources at the DMV must be approved prior to connecting to the information systems at the DMV. This pertains to all devices connecting to the network at the DMV, regardless of ownership. A risk analysis for each new media type shall be conducted and documented prior to its use or connection to the network at the DMV unless the media type has already been approved by the Desktop Standards Committee.
Page - 124 -
October 2012
Procedures:
The Desktop Standards Committee will maintain a list of approved mobile computing and storage devices. Mobile computing and storage devices are easily lost or stolen, presenting a high risk for unauthorized access and introduction of malicious software to the network at the DMV. These risks must be mitigated to acceptable levels. Portable computing devices and portable electronic storage media that contain confidential, personal, or sensitive DMV information must use encryption or equally strong measures to protect the data while it is being stored. Unless written approval has been obtained from the Data Resource Manager and Chief Information Security Officer, databases or portions thereof, which reside on the network at the DMV, shall not be downloaded to mobile computing or storage devices. Employees and contract staff shall have knowledge of, sign, and adhere to the Acceptable Use Statement (DMV 350). Compliance with the Remote Access Standards, the Mobile Media Standards, and other applicable policies, procedures, and standards is mandatory. 1. To report lost or stolen mobile computing and storage devices, call the Information Systems Division (ISD) Enterprise Service Desk at (916) 657-7755. For further procedures on lost or stolen handheld wireless devices, please see the Lost Mobile Device Procedures. 2. The DMV Desktop Standards Committee shall approve all new mobile computing and storage devices that may connect to information systems at the DMV. 3. Any non-departmental owned device that may connect to the DMV network must first be approved by technical personnel such as those from the DMV Desktop Support. Refer to the Mobile Media Standards for detailed information. 4. Submit requests for an exception to this policy to Enterprise IT Planning, Policy and Governance via the Policy Exception Request form (EXEC 205).
October 2012
Page - 125 -
Roles and Responsibilities:
Users of mobile computing and storage devices must diligently protect such devices from loss of equipment and disclosure of private information belonging to or maintained by the DMV and they must annually complete the DMV 350. Before connecting a mobile computing or storage device to the network at DMV, users must ensure it is on the list of approved devices issued by the ISD. The ISD Enterprise Service Desk must be notified immediately upon detection of a security incident, especially when a mobile device may have been lost or stolen. The Information Security Office is responsible for the mobile device policy at the DMV and shall conduct a risk analysis to document safeguards for each media type to be used on the network or on equipment owned by the DMV. The Information Systems Division is responsible for developing procedures for implementing this policy. The Desktop Standards Committee will maintain a list of approved mobile computing and storage devices and will make the list available on the intranet.
Definitions:
CD: A compact disc (sometimes spelled disk) is a small, portable, round medium made of molded polymer for electronically recording, storing, and playing back audio, video, text, and other information in digital form. DVD: The digital versatile disc stores much more than a CD and is used for playing back or recording movies. The audio quality on a DVD is comparable to that of current audio compact discs. A DVD can also be used as a backup media because of its large storage capacity. Flash Drive: A plug-and-play portable storage device that uses flash memory and is lightweight enough to attach to a key chain. The computer automatically recognizes the removable drive when the device is plugged into its USB port. A flash drive is also known as a keychain drive, USB drive, or disk-on-key. Handheld wireless device: A communication device small enough to be carried in the hand or pocket and is also known as a Personal Digital Assistant (PDA). Various brands are available, and each performs some similar or some distinct functions. It can provide access to other internet services, can be centrally managed via a server, and can be configured for use as a phone or pager. In addition, it can include software for transferring files and for maintaining a built-in address book and personal schedule.
Page - 126 -
October 2012
Definitions (continued):
Media Type: For the purpose of this policy, the term “media type” is interchangeable with “mobile device.” Not to be confused with media makes, models, or brands. Media Type Model: Refers to the brand of media device such as iPhone, iPad, Android or Droid, Sony, Treo, or IBM. Mobile Devices: Include, but are not limited to: laptop computers, personal digital assistants (PDAs), plug-ins, Universal Serial Bus (USB) port devices, Compact Discs (CDs), Digital Versatile Discs (DVDs), flash drives, modems, handheld wireless devices, wireless networking cards, and any other existing or future mobile computing or storage device, either personally owned or state owned, that may connect to or access the information systems at the DMV. Modems: A device that modulates and demodulates information so that two computers can communicate over a phone line, cable line, or wireless connection. The connection talks to the modem, which connects to another modem that in turn talks to the computer on its side of the connection. The two modems talk back and forth until the two computers have no further need of either modem’s translation services. PDA: The Personal Digital Assistant is also known as a handheld. It is any small mobile hand-held device that provides computing and information storage and retrieval capabilities for personal or business use, often for keeping schedule calendars and address book information handy. Plug-In: Programs that can easily be installed and used as part of your Web browser. A plug-in application is recognized automatically by the browser, and its function is integrated into the main HTML file that is being presented. Among popular plug-ins is Adobe's Acrobat, a document presentation and navigation program that provides a view of documents just as they look in the print medium. There are hundreds of plug-in devices. Wireless Networking Cards: Mobile device for wireless internet connectivity from a laptop. This card allows mobile users the ability to access a secured connection to the internet via a specified vendor.
October 2012
Page - 127 -
Authority/References:
Statewide Information Management Manual (SIMM), Section 140 Security Incident Report (SIR) Desktop/Mobile Computing (DMC) Policy (PDF) Mobile Media Standards (PDF) Remote Access Standards Acceptable Use Statement (DMV 350) State Administrative Manual, Chapter 5335.1 - Information Integrity and Data Security International Organization for Standardization (ISO) Standard 17799.9.8.1 - Mobile Computing
Related Information:
Desktop Standards Committee - Desktop Technology (DT) Procedures and Processes Lost Mobile Device Procedures Policy Exception Request (EXEC 205) (PDF)
IT Policy, Standards, Instructions and Guidelines References Desktop/Mobile Computing (DMC) Policy SAM 4989
Desktop and Mobile Computing Policy
SAM 4989.1 Definition of Desktop and Mobile Computing SAM 4989.2 Exclusions SAM 4989.3 Agency Roles and Responsibilities SAM 4989.8 Policy Compliance SP 800-124
Guidelines on Cell Phone and PDA Security
SP 800-101
Guidelines on Cell Phone Forensics
SP-800-72
Guidelines on PDA Forensics
Page - 128 -
October 2012
AC-20 Use of External Information Systems
Information Technology Policy Off-Shift Processing Policy # Revised: Issue Date: Owner:
IS 2012-23 Unknown Information Security Office
SAM SIMM: Supersedes:
Policy 22
Purpose:
DMV provides database information to many different Government and Industry Partners whose access needs vary greatly. When evaluating a user's requirements, it is necessary to consider the period of time in which the business needs can be accomplished while concurrently having the least impact on the Department's mission critical functions. For example, a user whose business needs can be met by providing information or update within one or two days of the request, will not be best served by real-time access. A more appropriate method might be to stage the transactions for processing during off-shift hours. This approach will also reduce the impact on the performance of the on-line system during business hours.
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
Template update: Not applicable or not available.
Policy:
When providing access to Department of Motor Vehicles (DMV) database records, processing during off-shift hours (non-primetime) will be utilized whenever the user's business needs will not be impaired.
Procedures:
This policy will be implemented by program and operational staff on an ad hoc basis as new applications are developed and new customer and client bases are identified and implemented.
Definitions:
Government and Industry Partners The term used in this document for external personnel who access the DMV systems performing transactions (including inquiries) for their employer or for DMV.
Authority/References: None Related Information: October 2012
Template update: Not applicable or not available. Page - 129 -
Information Technology Policy Internet Resource Use Policy # Revised: Issue Date: Owner:
IS 2012-35 4/2010 Information Security Office
SAM SIMM Supersedes:
APM 8.110, Policy 23
Purpose:
This policy establishes parameters for departmental use of Internet resources. The Internet provides a reliable, cost-effective mechanism for communication and information exchange with others, an avenue to extensive research resources and the potential for electronic transactions. DMV plans to use these resources to enhance departmental operations and customer service delivery.
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
All employees and contract staff using DMV network resources to access the Internet.
Policy:
Internet use is a privilege granted by DMV management to facilitate, support and enhance the user's ability to accomplish approved business functions. All Internet activity originating from, passing through, or terminating at a DMV site will adhere to the following policies: 1. Internet access will be granted on an individual basis through the existing access control procedures (e.g. ISD 100 (System Access Control)). Each authorized user is responsible for all activity occurring through their Internet connection. To protect the individual approved user and maintain the integrity of security logs, desktop computers or workstations used for Internet access shall be protected by software to control access to Internet applications and sites. Authorized users will, at least annually, sign an Acceptable Use Statement (DMV 350). 2. Information retrieved or downloaded from the Internet shall be related to the user's job duties, as defined by the user’s Manager or Supervisor. DMV Internet users will not knowingly access, view, retrieve, transmit or store information, images or sounds that are not necessary to accomplish approved business functions with the exception of an incidental or minimal use of a state resource.
Page - 130 -
October 2012
Policy (continued):
3. Internet sites posing a security risk shall be blocked. Internet sites such as social networking sites (e.g. YouTube, MySpace, etc.) pose an inherent risk associated with videos, streaming media, instant messaging, and other activities. Limited access may be granted to blocked sites where a business need exists by submitting an ISD 100 (System Access Control) to Information Systems Division signed by the requesting Deputy Director or designee(s) and Chief Information Security Officer. 4. There will be no Internet connections, servers or applications directly connected to any mission critical databases and systems. 5. Internet access will be made only through the Department's network infrastructure using software approved, installed and configured by the Department. Direct dial-up or wireless access to the Internet from a DMV facility is generally prohibited. Exceptions to this policy will be reviewed on a case-by-case basis. 6. All Internet activities and communications shall be treated as official departmental business. 7. Any information published, posted or uploaded to the Internet is considered official departmental correspondence. Information intended for the general public must be approved by the Director's designee. 8. No user will knowingly initiate an activity that negatively impacts a computer workstation, degrades network performance or interferes with the work of others. Internet traffic will be logged and monitored. Suspected incidents, violations and inappropriate usage will be reported to the Chief Information Security Officer for investigation and disposition. Confirmed misuse of Internet access will result in criminal, and/or administrative actions using current Human Resources standards and guidelines.
Procedures: (must be a separate document) Roles and Responsibilities: Definitions:
Internet Resource Use Procedures
Authority/References:
SIMM 66B Social Media Standard
Related Information:
Template update: Not applicable or not available.
October 2012
Template update: Not applicable or not available. Template update: Not applicable or not available.
Page - 131 -
Procedures Title: Internet Resource Use Procedures Owner: Information Security Office Issue Date: 4/2010 SAM/SIMM: Revision Date: POLICY Internet Resource Use PROCEDURES Approval: Internet access is granted to individual users based upon their specific business needs. Individuals requiring Internet access shall submit an ISD 100 (System Access Control).Access will be granted only after the user has read and signed the DMV 350, Acceptable Use Statement. The ISD 100 (System Access Control) shall indicate the following. 1. 2. 3. 4.
If request is for multiple employees, include list of names and workstation IDs. Provide justification for access to blocked websites, if necessary. If applicable, include start and end date. Add end user(s) to groups such as the DMV YouTube User Group as appropriate.
Installation: Upon approval, ISD will notify the appropriate support staff to install the necessary software and configure the user's workstation if needed. Before installing the software, support staff will ensure that virus scanning and access control software is installed and active on the workstation. Monitoring: The need to continue an individual user's Internet access will be periodically reviewed by management. Reports of Internet usage will be available to each Deputy Director for review and evaluation. Termination: The Deputy Directors or their designees will determine whether a user's access should be continued or terminated. Access rights shall be discontinued when: Access is no longer justified by a business need; The employee no longer works within the unit; A policy violation has occurred. To terminate access, the user's supervisor will submit an ISD 100 (System Access Control).
Page - 132 -
October 2012
IT Policy, Standards, Instructions and Guidelines References ITPL 10-02 Social Media Memoranda: Changes to Facebook Standard Terms of Service SIMM 66B
Social Media Standard
SAM 5179
Compliance with United States Postal Service, Optical Character Recognition Guidelines
SAM 5180
United States Postal Service ZIP + 4 Guidelines
AC-22 Publicly Accessible Content IT Policy, Standards, Instructions and Guidelines References APM 6.100 Public Information
October 2012
Page - 133 -
Audit and Accountability AU-1 Audit and Accountability Policy and Procedures
Information Technology Policy Automated Update and Change Requirements Policy # Revised: Issue Date: Owner:
IS 2012-16 Unknown Information Security Office
SAM SIMM: Supersedes:
Policy 14
Purpose:
The integrity of the information in DMV's records depends upon the assurance that any and all changes to the information occur through known and tested methods. Additionally, Penal Code Section 502 makes individuals accountable for the commission of crimes that involve the use of computers or information obtained through computer resources. For these reasons, the Department must be able to specifically identify each individual who updates or changes information in DMV records.
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
All employees and contract staff.
Policy:
Updates or changes to information in DMV records will only be accomplished through tested and approved production applications. Access to transactions that update or change information in DMV records will require positive identification and authentication of the user making the update or change.
Procedures:
Any time an individual or unit has a legitimate business need to update or change information in DMV's records without utilizing a tested and approved production application, the action can only be accomplished with the written approval of the appropriate Data Resource Manager. The procedure for authorizing users to update or change information in DMV's records will follow the process described in Information Access.
Page - 134 -
October 2012
Roles and Responsibilities:
Template update: Not applicable or not available.
Definitions:
None
Authority/References:
None
Related Information:
Information Access
October 2012
Page - 135 -
Information Technology Policy Transaction Auditability Policy # Revised: Issue Date: Owner:
IS 2012-14 Unknown Information Security Office
SAM SIMM: Supersedes:
Policy 12
Purpose:
DMV's databases contain confidential, sensitive, and public information. The auditability of transactions performed by both internal and external users is critical to ensure DMV's Information Assets are used appropriately.
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
Database Administrators and Data Resource Managers.
Policy:
Each transaction made to a production DMV database that contains confidential or sensitive information must create an audit record. The audit record must be retained for a sufficient period of time to satisfy business and audit needs.
Procedures:
At a minimum, for each transaction the audit record must contain a UserID code, the transaction code, the requester code, the terminal ID, the node ID, and the date and time of the transaction. Every DMV system that accesses confidential or sensitive information must include a journal log program or interactive monitor that permits the creation of audit records. The system must include the ability to write the audit records to long term storage media where they can be retained and made available for a prescribed period. Data Resource Managers may grant exemptions to this policy until systems currently in use can be modified to be in conformance with this policy.
Roles and Responsibilities:
Template update: Not applicable or not available.
Definitions:
Template update: Not applicable or not available.
Authority/References:
Template update: Not applicable or not available.
Related Information:
Information Access
Page - 136 -
October 2012
IT Policy, Standards, Instructions and Guidelines References SAM 4943 Audit of Information Technology Projects ITPL
11-03 Review of Formal Information Technology Solicitations
AU-3 Content of Audit Records Audit Logs and Reporting Requirements Local Area Networks must have the ability to create and print audit logs and/or reports. Minimally, they must indicate time, date, files, and users accessing (logon and logoff) the Local Area Network. Business owners and/or Data Resources Managers will define any additional data necessary for audit logs or reports. Refer to Transaction Auditability Procedures.
October 2012
Page - 137 -
AU-6 Audit Review, Analysis, and Reporting
Information Technology Policy Security Information and Event Management Policy # Revised: Issued: Owner:
DRAFT Draft 08/2012 Information Security Office
Purpose:
SAM: SIMM: Supersedes:
N/A
Establish and maintain a successful Security Information and Event Manager (SIEM) infrastructure for the Department of Motor Vehicles (DMV) to comply with DMV’s Information Security Program Policy purpose, specifically the use of standardized audit trails for all financial, sensitive, and confidential record transactions. In addition, define standards for a shared infrastructure that will capture and analyze sources of event logs (audit logs) and comply with the Payment Card Industry Data Security Standard (PCI-DSS).
Background/History:
The DMV is required by policy and industry best practices (e.g., PCI-DSS, National Institute of Standards and Technology (NIST)) to adhere to certain event log management best practices and configurations. In addition, DMV’s Access Control Delegated Administration Standards found in the Information Security Policy Manual require appropriate audit logging and audit log querying to monitor and investigate the effectiveness and integrity of the delegated administration capability. DMV’s Information Assets have long provided event, message and audit log collection and analysis capabilities (e.g., the California Motor Vehicle Data Switch – CAMVDCS journal files and the Department of Motor Vehicle Automation - DMVA Technician Daily Journals (TDJ)). The event log information is utilized for systems monitoring and usage auditing. The deployment of DMV’s Secure Access Infrastructure (SAI) for Web based user authentication has created additional sources of event log data.
Page - 138 -
October 2012
Persons Impacted:
This policy will impact those identified in the Roles and Responsibilities section.
Policy:
The DMV will establish a consistent, centralized enterprise infrastructure for the capture, retention, analysis, and reporting of event logs generated by network hardware, databases and applications managed by DMV. To accomplish this, a Security Information and Event Manager (SIEM) will be utilized for automated event log analysis and event correlation. All network hardware, databases and applications managed by DMV and connected to the DMV network shall be configured to provide event logs electronically to a SIEM. Single purpose SIEM’s shall report Events of Interest to the enterprise SIEM. When available, Events of Interest from non-DMV managed network hardware, databases and applications shall report either to a single purpose SIEM or the enterprise SIEM. Exceptions to this policy will be subject to the written approval of the Chief Information Officer and the Chief Information Security Officer. Request exceptions requested using the Policy Exception Request.
Procedures: (must be a separate document)
Security Information and Event Management Procedures
Roles and Responsibilities:
Application Developers: Develop applications to provide event logs in accordance with this policy and associated standards. This role will be assigned to the Information Systems Division (ISD). Audits Office: Access event log data when performing audits. Confirm that the SIEMs are reporting according to policy. Confirm that the established roles and responsibilities are followed. Enterprise Security Administrators: 1. Manage and monitor the event log management infrastructures. 2. At least weekly, confirm that all devices are reporting appropriately to the enterprise SIEM. 3. Assist others with configuring logging. 4. Configure events that are correlated between SIEMs. Refer to the Events of Interest Matrix. Alert appropriate parties of misconfigurations. 5. Perform event log analysis.
October 2012
Page - 139 -
6. Review and analyze SIEM audit records daily for indications of inappropriate or unusual activity. 7. Report the results of event log management activities. 8. Report findings to the ISO and other designated entities as identified on the Events of Interest Matrix. 9. Provide monthly reports to SIEM users, e.g., ISO, Audits Office This role has been assigned to Network Security Team (NST). Information Security Incident Response Team (ISIRT): Access event log data to gather forensics evidence in a manner consistent with evidentiary rules and best practices and the Reference Guide to Handling and Reporting Information Security Incidents (DMV 145). Information Security Office (ISO): 1. Oversee the SIEM infrastructure. This includes read access to logs for validation purposes. 2. Maintain the Events of Interest Matrix. 3. Define events that are correlated between SIEMs. Refer to the Events of Interest Matrix. 4. Perform event log analysis and correlation on suspected or confirmed security events. 5. Report security incidents to appropriate parties. 6. Convene an ISIRT as appropriate. 7. Generate pre-defined and ad hoc reports for ISIRTs, requesting users, and for its own use to monitor security policy compliance. 8. Adjust the level of audit review, analysis, and reporting within the SIEM when there is a change in risk to organizational operations, organizational assets, individuals, other organizations, or the State based on law enforcement information, intelligence information, or other credible sources of information or for compliance purposes. Investigations: Access event log data for investigative purposes. Server, Desktop and Network Administrators and System and Application Administrators: 1. Configure logging on individual systems and network devices. 2. Configure logging on security devices (e.g., firewalls, networkbased intrusion detection systems, antivirus servers). 3. Confirm that all devices are logging appropriately. 4. Analyze logs at least weekly. 5. Configure events that are correlated between SIEMs. Refer to the Events of Interest Matrix. Page - 140 -
October 2012
6. Report Events of Interest to the enterprise SIEM. 7. Perform regular maintenance of the logs (e.g., back-up, archive) and logging software. Definitions:
Audit Trail: The chronological logging of activity from event logs for a particular activity\time frame. This may come from different devices. Correlated Event: A chronological record of system activities to enable the reconstruction and examination of the sequence of events and/or changes in an event. Event Log: The records that document the activities occurring to the data resource. A chronological sequence of records containing evidence directly pertaining to and resulting from the execution of a business process or system function. Synonymous with Audit Log. Information Assets: (a) Computing hardware, e.g., servers, network components, workstations, laptops, smart phones, tablets, removable storage devices, etc., databases, automated files and the documents and hardcopy records they represent, automated programs, and application software. (b) Essential public resources which include DMV information, whether in hardcopy or electronic format; its data processing capabilities; and information technology infrastructure. Payment Card Industry Data Security Standard (PCI DSS): A multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. This comprehensive standard is intended to help organizations proactively protect customer account data. The DMV is required to comply with the PCI DSS to accept payment cards (credit and debit cards). Secure Access Infrastructure (SAI): The documented vision of the Department’s architectural plans for providing secure web based access for employees and Government and Industry Partners. SIEM - Security Information and Event Management, describes the product capabilities of gathering, analyzing and presenting information from network and security devices; identity and access management applications; vulnerability management and policy compliance tools; operating system, database and application logs; and external threat data.
Implementation Timeframe:
October 2012
This policy must be implemented as soon as practical but no later than within one year of approval.
Page - 141 -
Authority/References:
Transaction Auditability Policy Public Key Infrastructure & Certificate Policy NIST SP 800-53 Recommended Security Controls NIST SP 800-92 Guide to Computer Security Log Management PCI DSS (PCI Data Security Standard)
Related Information:
Security Information and Event Management Standards Information Protection Standards Policy Successful SIEM and Log Management Strategies for Audit and Compliance The Information Security Incident Response Team (ISIRT) Manual has a limited distribution. Contact the ISO.
Revision History
Page - 142 -
The draft was presented to the Information Technology Advisory Committee (ITAC) on August 9, 2012. Before presenting this policy for formal adoption, the ISO will work with the impacted persons to fully populate the Events of Interest Matrix. After six months, the ISO will present for formal adoption.
October 2012
Procedures Title: Security Information and Event Management Owner: DMV Information Security Office Issue Date: DRAFT SAM/SIMM: Revision Date: POLICY Security Information and Event Management PROCEDURES General: 1. In order to establish correlation between events, all network hardware, databases and applications managed by DMV shall be configured to report to a SIEM. 2. The SIEM shall produce event logs that contain sufficient information to, at a minimum, establish what type of event occurred, when (date and time) the event occurred, where the event occurred, the source of the event, the outcome (success or failure) of the event, and the identity of any user/subject associated with the event. 3. The SIEM shall be configured in a manner that will support Role Based Access Control to enforce Separation of Duties. 4. Devices will be configured by their responsible administrators to log all applicable Events of Interest listed in the Events of Interest Matrix. Enterprise SIEM The enterprise SIEM will be configured to alert based on the Events of Interest Matrix. Events of Interest The Information Security Office (ISO), with input from the organization, reviews and updates the Events of Interest Matrix quarterly or as needed. Execution of privileged functions (e.g., authorizing a new user root level access, access to production data without using an approved production application, or access to restricted areas of an operating system) will be included in the Events of Interest Matrix reported to the enterprise SIEM.
October 2012
Page - 143 -
Event Log Review 1. SIEM s will be monitored, maintained and audited for maintenance changes, performance and security events. 2. Logs for all system components must be reviewed at least daily. Log harvesting, parsing, and alerting tools may be used for this purpose. 3. Log reviews must include those servers that perform security functions like intrusion detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS). 4. Follow-up to exceptions is required as outlined in the Events of Interest Matrix. DEFINITIONS (if different than policy) Role Based Access Control: An approach to restricting system access to authorized users. Within an organization, roles are created for various job functions. The permissions to perform certain operations are assigned to specific roles. Members of staff (or other system users) are assigned particular roles, and through those role assignments acquire the permissions to perform particular system functions. Since users are not assigned permissions directly, but only acquire them through their role (or roles), management of individual user rights becomes a matter of simply assigning appropriate roles to the user; this simplifies common operations, such as adding a user, or changing a user's department. Separation of Duties (SOD): The simplest definition of the principle of SOD is to require a different user to perform each step of a sensitive task that is comprised of more than one step. Accounting practitioners have long employed SOD to deter fraud and hinder collusion. NIST SP 800-53 provides the following technology-based definition of SOD: (i) mission functions and distinct information system support functions are divided among different individuals/roles; (ii) different individuals perform information system support functions (e.g., system management, systems programming, configuration management, quality assurance and testing, network security); (iii) security personnel who administer access control functions do not administer audit functions; and (iv) different administrator accounts for different roles. AUTHORITY/REFERENCES (if different) RELATED INFORMATION Security Information and Event Management Standards
Page - 144 -
October 2012
Standards Title: Security Information and Event Management Standards Owner: Issue Date: DRAFT SAM/SIMM: Revision Date: POLICY Security Information and Event Management STANDARDS General The following standards must be followed for any Security Information and Event Management infrastructure: 1. The SIEM infrastructure must map dissimilarly structured event log entries into a standardized format that can be retained in a common data store. 2. The SIEM infrastructure must be agnostic with respect to the platforms, operating systems, and SAI frameworks deployed by DMV. 3. The SIEM infrastructure must capture all authentication and authorization events or service request failures generated by DMV’s Information Assets. 4. The SIEM infrastructure must capture event logs that trace database access and update. For performance reasons, it is acceptable for this type of event log record to be created offline. For instance, the event log files generated by the database management system could be the source. 5. The SIEM infrastructure will provide the capability to alert operations staff to trends observed in the event log entries. 6. The SIEM infrastructure will provide message integrity checking (for example, hash-based message coding) to assure that no tampering has occurred to the original event. 7. The SIEM infrastructure must provide tools for near real-time and overall trend analysis as well as ad-hoc and scheduled reports. 8. The SIEM infrastructure storage must provide data compression and event log indexing to aid searching and analysis activities. 9. The SIEM infrastructure must be architected to prevent the loss of event logs due to component failure or other outages. 10. The SIEM infrastructure will provide capabilities to capture additional event log file sources (for example, Web application events, or database logs). October 2012
Page - 145 -
Event Log Content 1. The event log shall contain, at a minimum, the following: Source, such as MAC address, IP, etc. Node ID Date and time 2. The event log shall not contain any personally identifiable information (PII). Audit Trail History The SIEM will retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from back-up) to provide support for after-the-fact investigations of security incidents and to meet regulatory and organizational information retention requirements. Network Time Protocol To facilitate event correlation, all Information Assets shall synchronize to the DMV’s standard Network Time Protocol. All SIEMS must obtain time from same source. DEFINITIONS California Department of Motor Vehicles Data Control System (CAMVDCS): A DMV designed and developed message switch which manages message traffic between the DMV and other networks as well as access to the various DMV database systems. Department of Motor Vehicles Automation (DMVA): The user interface that provides DMV Field Office staff on-line access to the Department’s vehicle and driver databases. Least Privilege: Allowing only authorized accesses for users (and processes acting on behalf of users) which are necessary to accomplish assigned tasks in accordance with organizational missions and business functions.
Page - 146 -
October 2012
AUTHORITY/REFERENCES California Technology Agency IT Policy Letter – Establishment of the Identity and Access Management (IdAM) Policy ITPL 10-17. State Identity Credential and Access Management (SICAM) – Roadmap and Implementation Guidelines. NIST SP 800-53 Recommended Security Controls for Federal Information Systems and Organizations, specifically, AC-6: Least Privilege and AC-5: Separation of Duties. NIST SP 800-92 Guide to Computer Security Log Management PCI DSS (PCI Data Security Standard), specifically, Requirement 10 RELATED INFORMATION Security Information and Event Management Procedures DMV Identity and Access Management Task Force Final Report – Audit Logs Section
October 2012
Page - 147 -
Events of Interest Matrix
Activity Monitored 1. Login by User 2. Login by unauthorized user7 3. Failed Login by User 4. Login by Administrator 5. Failed Login by Administrator 6. Failed Login - Total – x/hour during business hours (0700 – 1800) M-F, except holidays 7. Failed Login - Total – x/hour Saturdays, Sundays, holidays (0700 – 1800) 8. Failed Login - Total – x/hour during business hours (1801 – 0659) 9. Configuration Changes 10. New User Creation 11. New User Added to Active Directory Group
Area DBA DBA DBA DBA8
Severity (Low, Source Medium, (Device) High)
Action Taken Log only
Required By:
Log only Email to ISD DBAs (
[email protected])
DBA9 Email to enterprise SIEM administrators Email to enterprise SIEM administrators
DBA DBA
Email to enterprise SIEM administrators Log only Email to ISD DBAs (
[email protected])
12. New Administrator Created 13. Permission Changes 14. Malware Detected
7
May need to be a correlated event: compare user to AD group. May need to be a correlated event. 9 May need to be a correlated event. 8
Page - 148 -
October 2012
Activity Monitored 15. Intrusion Detected 16. Application Events 17. All individual accesses to cardholder data 18. All actions taken by any individual with root or administrative privileges 19. Access to All audit Trails 20. Invalid logical access attempts 21. Use of identification and authentication mechanisms 22. Initialization of the audit logs 23. Creation and deletion of system-level objects 24. Auditing based on Audit Access Control Entries is enabled for the system. 25. Auditing for Break-in events is enabled for all relevant login types. 26. Auditing of access via DOWNGRADE privilege is enabled for all access types. 27. Auditing of access via READALL privilege is enabled for all access types. 28. Auditing of access via the BYPASS privilege is enabled for all access types.
October 2012
Area
Severity (Low, Source Medium, (Device) High)
Action Taken
Required By:
PCI DSS 10.2.1 PCI DSS 10.2.2 PCI DSS 10.2.3 PCI DSS 10.2.4 PCI DSS 10.2.5 PCI DSS 10.2.6 PCI DSS 10.2.7 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2
Page - 149 -
Activity Monitored 29. Auditing of access via the GRPPRV privilege is enabled for all access types. 30. Auditing of access via the SYSPRV privilege is enabled for all access types. 31. Auditing of access via UPGRADE privilege is enabled for all access types. 32. Auditing of Authorization events is enabled. 33. Auditing of Connection events is enabled. 34. Auditing of failed access is enabled for all access types. 35. Auditing of Failed Use of Privilege is enabled. 36. Auditing of Forced Image Exits based on Privilege is enabled. 37. Auditing of Granting Identifiers to a Process based on Privilege is enabled. 38. Auditing of ill-formed audit calls is enabled. 39. Auditing of Installation events is enabled. 40. Auditing of Login Failure events is enabled for all relevant login types. 41. Auditing of Login Success events is enabled for all relevant login types.
Page - 150 -
Area
Severity (Low, Source Medium, (Device) High)
Action Taken
Required By: NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2
October 2012
Activity Monitored Area 42. Auditing of Logout events is enabled for all relevant login types. 43. Auditing of modifications to the audit settings is enabled. 44. Auditing of Mount events is enabled. 45. Auditing of Network Configuration is enabled. 46. Auditing of Other Successful Use of Privilege is enabled. 47. Auditing of Persona Creation is enabled. 48. Auditing of Persona Deletion is enabled. 49. Auditing of Persona Modification is enabled. 50. Auditing of Process Deletions is enabled. 51. Auditing of Revoking Identifiers from a Process based on Privilege is enabled. 52. Auditing of Setting Process Priority based on Privilege is enabled. 53. Auditing of Setting System Time is enabled. 54. Auditing of System Parameter Modification is enabled.
October 2012
Severity (Low, Source Medium, (Device) High)
Action Taken
Required By: NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2 NIST 800-53 AU-2
Page - 151 -
Activity Monitored 55. Auditing of use of an Identifier as a privilege is enabled. 56. The Audit Server is running.
Area
Severity (Low, Source Medium, (Device) High)
Action Taken
Required By: NIST 800-53 AU-2 NIST 800-53 AU-2
IT Policy, Standards, Instructions and Guidelines References ITPL 10-18 Memoranda: Amendment to the California Public Records Act
Page - 152 -
October 2012
Security Assessment and Authorization CA-2 Security Assessments IT Policy, Standards, Instructions and Guidelines References SP 800-115 Technical Guide to Information Security Testing and Assessment SP 800-53 A Guide for Assessing the Security Controls in Federal Information Systems and Organizations, Building Effective Security Assessment Plans SP 800-30 Rev. 1
Guide for Conducting Risk Assessments
CA-3 Information System Connections IT Policy, Standards, Instructions and Guidelines References SP 800-59 Guideline for Identifying an Information System as a National Security System SP 800-54
Border Gateway Protocol Security
SP 800-47
Security Guide for Interconnecting Information Technology Systems
CA-6 Security Authorization IT Policy, Standards, Instructions and Guidelines References SP 800-36 Guide to Selecting Information Technology Security Products SP 800-35
October 2012
Guide to Information Technology Security Services
Page - 153 -
Page - 154 -
October 2012
System and Communications Protection SC-1 System and Communications Protection Policy and Procedures
Information Technology Policy Confidentiality Requirements Policy # Revised: Issue Date: Owner:
IS 2012-15 Unknown Information Security Office
SAM SIMM: Supersedes:
Policy 13
Purpose:
DMV records contain a broad range of information that is classified "confidential." This information must be strictly controlled to ensure that the privacy of our customers and employees is protected such as guaranteed in Article 1: Declaration of Rights of the California State Constitution.
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
Template update: Not applicable or not available.
Policy:
Confidential information in DMV records will be used and protected in a manner that will prevent unauthorized access, disclosure, or dissemination, and assure it is disposed of properly.
Procedures:
Roles and Responsibilities:
October 2012
The need for special precautions will be addressed during the Needs Assessment stage of the feasibility study and documented in the Functional Requirements Section of all Feasibility Study Reports for any system to protect confidential information. Any special precautions related to DMV staff handling transactions, records or files containing confidential information will be addressed during technical training and in procedure manuals. The processing, storing and disposal of any records containing confidential information by DMV contractors will be addressed in specific contract language. Template update: Not applicable or not available.
Page - 155 -
Definitions:
None
Authority/References:
None
Related Information:
Classifying and Handling Information
Page - 156 -
October 2012
Information Technology Policy Confidential or Sensitive Information on Desktop or Mobile Computers Policy # Revised: Issue Date: Owner:
IS 2012-37 6/2007 Information Security Office
SAM SIMM: Supersedes:
5320.2 APM 8.223
Purpose:
Template update: Not applicable or not available.
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
Template update: Not applicable or not available.
Policy:
It is the policy of this Department that proposals to use a desktop or portable computer to maintain or access files containing confidential or sensitive data as defined in SAM Section 5320.2 or by statute must be approved by the Department's Chief Information Security Officer. The Chief Information Security Officer must determine that the proposal complies with DMV policies regarding the protection of confidentiality and security of sensitive information. Desktop or portable computers used to maintain or access sensitive data must be identified as such in the Department's Information Systems Plan.
Procedures:
Template update: Not applicable or not available.
Roles and Responsibilities:
Template update: Not applicable or not available.
Definitions:
Template update: Not applicable or not available.
Authority/References:
Template update: Not applicable or not available.
Related Information:
Template update: Not applicable or not available.
October 2012
Page - 157 -
Information Technology Policy Network Security Policy # Revised: Issue Date: Owner:
IS 2012-17 Unknown Information Security Office
SAM SIMM: Supersedes:
Policy 16
Purpose:
DMV information users utilize and rely on a variety of network resources to accomplish their work. These networks must be structured and administered in a manner that provides both information users and the Department's Data Resource Managers assurance that DMV's information security standards and guidelines are followed.
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
Template update: Not applicable or not available.
Policy:
Networks used or approved for use by DMV will provide users with a secure processing environment so the integrity, availability and accessibility of information can be assured. This assurance will be achieved by adherence to departmental network security standards and guidelines.
Procedures:
1. Networks administered by DMV will comply with departmental information security standards. Because of the logical limitations in the networks and the need to maximize connectivity options for users, access to individual applications in DMV networks may be administered and controlled at either the network operating system or the application level. Where the technology permits, the user authentication process at network entry can be used to establish authorization to specific applications on the network. 2. Because networks are shared production data processing environments, access to the operating systems and any system level resources will be limited to only formally assigned system administration, system support, and database administrator staff. Any other user requiring system level resource access will request access from the appropriate Data Resource Manager.
Page - 158 -
October 2012
Procedures (continued):
3. Unattended network terminals or computers will be deactivated by the system through either a password protected screen saver program or an automatic timed logoff. When network monitors detect attempted or actual misuse of network resources, these events will be handled as if they are hacker incidents in accordance with the Information Security Incident Reporting and Follow Up policy.
Roles and Responsibilities:
Template update: Not applicable or not available.
Definitions:
Template update: Not applicable or not available.
Authority/References:
None
Related Information:
LAN Standards Network Components Standards WAN Security Standards
October 2012
Page - 159 -
Information Technology Policy Intranet Security Policy # Revised: Issue Date: Owner:
IS 2012-24 Unknown Information Security Office
Purpose:
SAM SIMM: Supersedes:
Policy 25
This policy defines the security measures that will be utilized to secure the DMV Intranet. Access to DMVWeb resources will be granted to all DMV employees who can benefit from its use. Resources on the DMVWeb will be adequately protected to ensure their confidentiality, integrity and availability. Providers of DMVWeb resources may declare specific resources secure and limit access to approved employees. The DMVWeb Administrator will authorize designated individuals to update web site content. All DMVWeb sites will be approved by the DMVWeb Project Manager.
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
Employees and contract staff that maintain and access Intranet related information technology resources.
Policy:
The Department of Motor Vehicles will implement and maintain adequate security of Intranet related information technology resources made available to accomplish the Department's mission.
Procedures: (must be a separate document)
Intranet Security Procedures
Roles and Responsibilities:
Template update: Not applicable or not available.
Page - 160 -
October 2012
Definitions:
Intranet: The computer networks within DMV to provide DMV employees specific information to improve their ability to conduct department business. The Intranet will not be available to the public. DMV will refer to its Intranet as the DMVWeb. Internet: The world-wide system of large computer networks joined together over high speed data links that provides connections through the use of standardized protocols. DMV makes information and services available to external customers through the Internet.
Authority/References:
None
Related Information:
DMVWeb Requirements: 1. A secure authentication process, using at least encrypted passwords, is required to prove the identity of each person who either accesses secure Intranet resources or originates or conducts a business process using the Intranet. 2. Any records, files or message packets containing confidential or sensitive information used by, stored within, or transmitted by a resource accessible from the Intranet will be encrypted to prevent unauthorized access or alteration. 3. Any known security breaches, weaknesses, or evidence of unauthorized intrusion will be immediately reported in accordance with the Handling and Reporting Information Security Incidents (DMV 145) pamphlet. 4. Business processes initiated or conducted on the Intranet will be identifiable to the individual initiator or user and stored in a way that permits departmental management review and audit. 5. Any electronically stored information used to identify, authenticate, authorize, or acknowledge any payment or exchange of value on the Intranet will be stored in a location or manner that prevents unauthorized access, alteration or deletion.
October 2012
Page - 161 -
Title:
Intranet Security Procedures
Owner:
Information Security Office
Issue Date:
Unknown
Revision Date: POLICY Intranet Security Policy PROCEDURES The following procedures will be used to manage DMVWeb use: 1. Access to Intranet resources will be granted to all DMV employees who can benefit from its use; no additional UserID or password will be required for general use. 2. Access to secure or confidential resources will require a DMV issued UserID and password and the approval of the DMV Data Resource Manager for the requested resource. An ISD 100 (System Access Control) will be used to obtain this approval. 3. Confidential and or sensitive data used by, stored within or transmitted by the DMVWeb will be encrypted using a protocol at least as effective as Secure Sockets Layer 3.0. 4. The DMVWeb home page will contain a logon banner to inform users that the Intranet is for departmental business purposes only. 5. All home pages on the DMVWeb will be approved by the DMV Content Manager/Coordinator. No personal home pages or web sites will be placed on the DMV Intranet. 6. All DMVWeb site servers will be configured to disallow FTP, Telnet, Remote Login, and Gopher services. 7. DMVWeb site servers will be regularly backed-up and the data applications, systems, and configuration files stored off site for recovery and restoration purposes. 8. Only users from within DMV's Web network domain will be allowed access to DMVWeb resources. 9. The system used to manage UserIDs and passwords must comply with DMV standards for UserID and password administration. IT Policy, Standards, Instructions and Guidelines References ITPL 10-16 Server Virtualization SAM 4834
Information Technology Infrastructure Policy
SP 800-125
Guide to Security for Full Virtualization Technologies
Page - 162 -
October 2012
SC-7 Boundary
Information Technology Policy Firewall Security Policy # Revised: Issue Date: Owner:
IS 2012-25 Unknown Information Security Office
Purpose:
SAM SIMM: Supersedes:
Policy 26
This policy enables DMV management to implement effective policies, standards and guidelines for use of the Internet for business purposes including: Access Control Antivirus Scanning Authentication Content Security Intrusion Detection Monitoring Internet Use Transaction Processing URL Filtering Virtual Private Networking
Background/History:
Template update: Not applicable or not available.
Persons Impacted:
Template update: Not applicable or not available.
Policy:
Communication within DMV's data network (DMVNet) and from this network to other networks will be through a firewall configured to protect DMV resources. The firewall will also enforce DMV's Internet Resource Use policy.
Procedures: (must be a separate document)
Firewall Security Procedures
Roles and Responsibilities:
Template update: Not applicable or not available.
October 2012
Page - 163 -
Definitions:
Firewall: A firewall is a computer system or set of computer systems, that controls and reports on activities that are permitted to take place between two networks or parts of a network. A firewall is typically installed between a private network (such as DMVWeb) and the Internet, although firewalls can be used to control traffic between parts of a private network (such as between LAD's subnet and the rest of DMVWeb).
Authority/References:
None
Related Information:
None
Page - 164 -
October 2012
Procedures Title: Firewall Security Procedures Owner: Issue Date: Unknown SAM/SIMM: Revision Date: POLICY Firewall Security Policy PROCEDURES The following procedures will be used to manage firewalls: 1. All DMV firewalls are configured to disallow all incoming and outgoing protocols unless a justified business need exists. 2. An opening of a firewall protocol is authorized by the Chief Information Security Officer. A risk assessment should accompany the request stating the benefits gained and recommended controls to mitigate the risk. 3. ISD shall maintain authorization documentation for all firewall business rules and corresponding business users. 4. Mission critical applications passing through a firewall shall ensure that time to recovery is within the business recovery guidelines set by the business owners. 5. The technology platform for firewalls will be maintained to reflect a high level of security. Underlying operating systems will incur all the latest patches to eliminate known security vulnerabilities. 6. System logs shall be maintained and audited for maintenance changes, performance, and security events. 7. Confidential and or sensitive data used by, stored within or transmitted by the firewall will be encrypted meeting or exceeding the standards published by the Information Security Office. 8. Critical transmissions are given a high priority status for quicker time to deliver than noncritical DMV business. 9. A Universal Resource Locator (URL) filter shall be maintained by the firewall administration staff in ISD. Designated locations and categories are authorized or forbidden by the Chief Information Security Officer. 10. Security monitoring and periodic audits shall be performed on all firewalls. Management and audit reports are available upon request from the Information Security Office, Audits, and Investigations. The purpose of these reports is to monitor security compliance, system performance, individual Internet usage, or forensics. 11. Transmission content shall be scanned for malicious code activities such as viruses and trojan horses. ActiveX code and JAVA applets should also be scanned for known adverse effects. Antivirus protection updates to definition tables shall meet or exceed Department standards. Firewall Requirements: 1. All transmissions from within the DMV network to other networks shall incorporate Network Address Translation (NAT) when passing through the firewall. 2. DMV firewall administration will be performed from a centralized location using centralized October 2012
Page - 165 -
policy-based management. 3. Each firewall must provide the ability to perform real-time alerts in the form of pager calls, send e-mail, and predefined blocking actions including shutdown. 4. The firewall must provide audit, accounting, and management reports. 5. The firewall must be able to prioritize transmissions based on business rules and objectives determined by the Department.
SC-12 Cryptographic Key Establishment and Management IT Policy, Standards, Instructions and Guidelines References SP-800-108 Recommendation for Key Derivation Using Pseudorandom Functions SP 800-67
Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher
SP 800-57
Recommendation for Key Management: Part 1: General (Part 1) Comments Received
SP 800-56 C Recommendation for Key Derivation through Extraction-then-Expansion SP 800-56B
Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography
SP 800-56A
Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography
SP 800-20
Modes of Operation Validation System for the Triple Data Encryption Algorithm (TMOVS): Requirements and Procedures
SP 800-17
Modes of Operation Validation System (MOVS): Requirements and Procedures
Page - 166 -
October 2012
SC-13 Use of Cryptography
Information Technology Policy Encryption Policy # Revised: Issue Date: Owner:
IS 2012-31 12/2008 Information Security Office
SAM SIMM: Supersedes:
APM 8.020
Purpose:
The purpose of this policy is to establish management direction, procedures, and requirements to ensure the appropriate protection of Department of Motor Vehicles (DMV) Information Assets by the employment of encryption techniques. The DMV uses encryption technology to ensure data integrity, statutory and regulatory compliance, as well as provide robust access control mechanisms.
Background/History:
This document is a new document and sets forth the DMV’s policy regarding the proper use of encryption from day forward for new and modified processes and system development. This policy affects all employees, retired annuitants, students, external entities, vendors, consultants, contractors, and all others who access, store or transmit DMV information and information resources.
Persons Impacted:
Policy:
It is the policy of the Department of Motor Vehicles (DMV) to prohibit unauthorized access, disclosure, duplication, modification, diversion, destruction, loss, misuse, or theft of DMV information. In addition, it is the policy of the DMV to protect information entrusted to it by third parties (State, Federal, Private entities) in the same manner as the DMV information is protected, consistent with existing agreements. The DMV will safeguard all its Information Assets stored, processed, accessed or transmitted. 1. DMV information must be protected commensurate with the sensitivity of the information and the risk associated with its disclosure. 2. Encryption is a controlled technology that is used for the purpose of securing certain DMV information. 3. Only encryption processes approved by the DMV Information Security Office (ISO) of the Office of the Chief Information Officer (OCIO) are to be used to encrypt DMV information.
October 2012
Page - 167 -
Policy (continued):
4. All information classified as Confidential, Personal, or Sensitive must be encrypted when transmitted over public, private/semi private, or virtual private networks to provide enhanced security for systems that process, store, or transmit this DMV information. 5. All information classified as Confidential shall be encrypted in storage or at rest. Violation of this policy could result in the loss or limitation of access to systems and information resources, as well as disciplinary and/or legal action, including termination of employment or referral for criminal prosecution. The Chief Information Security Officer of the OCIO must approve exceptions to this policy. Submit requests for exceptions to this policy via the Policy Exception Request form (EXEC 205).
Procedures:
Template update: Not applicable or not available.
Roles and Responsibilities:
DMV Management: Ensure that encryption technology is used prudently, properly and in a manner consistent with any DMV standards and procedures. Managers: Ensure that all personnel in his or her area understand and comply with policy, standards, and procedures. Managers are also are responsible for informing customers, vendors, and suppliers of this policy before allowing them access to DMV information systems. Office of the Chief Information Officer (OCIO): With advisement of the Information Services Division, research encryption products and processes. The OCIO consults with ISO to select and approve the encryption products and processes used at the DMV.
Definitions:
Template update: Not applicable or not available.
Authority/References:
Federal Information Security Management Act of 2002 (FISMA), PL 107-347, December 17, 2002 Federal Information Processing Standard (FIPS) 140-2 , Security Requirements For Cryptographic Modules The Privacy Act of 1974, 5 U.S.C., Section 552a
Related Information:
Page - 168 -
Template update: Not applicable or not available.
October 2012
IT Policy, Standards, Instructions and Guidelines References SAM 5345.2 Cryptography FIPS 140—3 Security Requirements for Cryptographic Modules (Revised Drafts) FIPS 140—2 Security Requirements for Cryptographic Modules FIPS 1402 FIPS 1402 Annex A FIPS 1402 Annex B FIPS 1402 Annex C FIPS 1402 Annex D FIPS 140—1 Security Requirements for Cryptographic Modules FIPS 186—3 Digital Signature Standard (DSS) SP 800-107
Recommendation for Applications Using Approved Hash Algorithms
SP 800-106
Randomized Hashing for Digital Signatures
SP 800-49
Federal S/MIME V3 Client Profile
SP 800-38 F Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping SP 800-38 A Recommendation for Block Cipher Modes of Operation - Methods and Techniques SP 800-38 AAddendum
Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode
SP 800-38-B Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication -Updated CMAC Examples SP 800-38 C Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality SP 800-38 D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC SP 800-38 E Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices SP 800-25
Federal Agency Use of Public Key Technology for Digital Signatures and Authentication
SP 800-22 Rev. 1A A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications SP 800-21 2nd Ed. October 2012
Guideline for Implementing Cryptography in the Federal Government Page - 169 -
SC-17 Public Key Infrastructure Certificates
Information Technology Policy DMV Public Key Infrastructure & Certificate Policy Policy # Revised: Issue Date: Owner:
IS 2011-01 01/2011 Information Security Office
SAM SIMM: Supersedes:
None
Purpose:
The use of public key certificates will provide for electronic authentication methods to verify the identity of the sender (user or machine) and the integrity of the electronic content.
Background/History:
As stated in DMV’s Information Protection Standards Policy, the DMV adopts the American National Standards Institute (ANSI) management information standards and the Federal Information Processing Standards (FIPS) and the National Institute of Standards and Technology (NIST) as baseline security standards and best practices to increase the confidentiality, integrity, and availability of DMV’s Information Assets. As recommended by NIST, the adoption of a scalable public key infrastructure (PKI) provides a comprehensive solution for data integrity, identification and authentication, and non-repudiation security services in DMV. DMV is currently poised, from a hardware and software perspective, to issue certificates. This document also describes the issuance, management, and use of public key certificates and associated cryptographic technology, generally referred to as the Certificate Policy (CP).
Persons Impacted:
Server administrators, data resource managers, and external entities accessing DMV resources.
Policy:
The DMV shall adopt a public key infrastructure (PKI) as an electronic authentication method to verify the identity of a sender (user or machine) and the integrity of the electronic content.
Procedures
Refer to the accompanying Public Key Infrastructure and Certificate Policy Procedures.
Page - 170 -
October 2012
Roles and Responsibilities
This CP states the roles and obligations of the Certification Authority (CA) Administrator’s and other entities issuing, managing, and using certificates and related cryptographic materials. Trusted Roles: A trusted role is one whose incumbent performs functions that can introduce security problems if not carried out properly, whether accidentally or maliciously. The people selected to fill these roles must be extraordinarily responsible, or the integrity of the CA will be will be weakened. The functions performed in these roles form the basis of trust for the entire PKI. Two approaches are taken to increase the likelihood that these roles can be successfully carried out. The first ensures that the person filling the role is trustworthy and properly trained. The second distributes the functions among more than one person, so that any malicious activity would require collusion. The primary trusted roles defined in this policy are CA Administrator, Registration Authority (RA), Auditor, and Operator. Individual personnel shall be specifically designated to the four roles defined below. CA Administrator: The administrator role shall be responsible for: Installation, configuration, and maintenance of the CA and certification status server (CSS) (where applicable); Establishing and maintaining CA and CSS system accounts; Configuring certificate profiles or templates; Configuring CA, RA, and CSS audit parameters Configuring CSS response profiles; and Generating and backing up CA and CSS keys. Administrators do not issue certificates to subscribers. Registration Authority: This role shall be responsible for issuing certificates, that is: Registering new subscribers and requesting the issuance of certificates; Verifying the identity of subscribers and accuracy of information included in certificates; Approving and executing the issuance of certificates; and Requesting, approving and executing the revocation of certificates
October 2012
Page - 171 -
Auditor: The auditor role shall be responsible for: Reviewing, maintaining, and archiving audit logs; and Performing or overseeing internal compliance audits to ensure that the CA, associated RAs, and CSS (where applicable) are operating in accordance with its CPS. Operator: The operator role shall be responsible for operations such as system backups and recovery or changing recording media. Number of Persons Required per Task
Two or more persons are required for the following tasks: CA key generation; CA signing key activation; CA private key backup. Where multiparty control is required, at least one of the participants shall be a CA Administrator. All participants must serve in a trusted role. Multiparty control shall not be achieved using personnel that serve in the Auditor trusted role.
Identification and Authentication for Each Role
An individual shall identify and authenticate him/herself before being permitted to perform any actions set forth above for that role or identity.
Roles Requiring Separation of Duties
Individuals may only assume one of the CA Administrator, Registration Authority, and Auditor roles, but any individual may assume the Operator role. The CA and RA software and hardware shall identify and authenticate its users and shall ensure that no user identity can assume both the CA Administrator and Registration Authority roles, assume both the CA Administrator and Auditor roles, or assume both the Registration Authority and Auditor roles. No individual shall have more than one identity.
Definitions:
Authentication: Security measure designed to establish the validity of a transmission, message, or originator, or a means of verifying an individual's authorization to receive specific categories of information. Certificate: A digital representation of information which at least (1) identifies the certification authority issuing it, (2) names or identifies its subscriber, (3) contains the subscriber's public key, (4) identifies its operational period, and (5) is digitally signed by the certification authority issuing it. Certification Authority (CA) An authority trusted by one or more users to issue and manage X.509 Public Key Certificates and CARLs or CRLs. Certification Authority Administrator (CAA): An entity responsible for issuing, signing (certifying), and managing public
Page - 172 -
October 2012
key certificates (sometimes referred to as a certificate authority.) Certificate Policy (CP): A Certificate Policy is a specialized form of administrative policy tuned to electronic transactions performed during certificate management. A Certificate Policy addresses all aspects associated with the generation, production, distribution, accounting, compromise recovery and administration of digital certificates. Indirectly, a certificate policy can also govern the transactions conducted using a communications system protected by a certificate-based security system. By controlling critical certificate extensions, such policies and associated enforcement technology can support provision of the security services required by particular applications. Certification Authority Revocation List (CARL) or Certificate Revocation List (CRL): A signed, time-stamped list of serial numbers of CA public key certificates, including cross-certificates, that have been revoked. Data integrity: Assurance that the data are unchanged from creation to reception. Encryption certificate: A certificate containing a public key that is used to encrypt electronic messages, files, documents, or data transmissions, or to establish or exchange a session key for these same purposes. End Entity (EE): An end entity is a subscriber, a relying party, or both. Entity: A CA, RA, or end entity. Identity certificate: A certificate issued for the purpose of binding the identity of the subject (as stated in the certificate) to a public key issued to that subject. In X.509 certificates, the identity of the subject is equivalent to the Distinguished Name of the subject. Key: A value supplied to a cryptographic algorithm to encrypt or decrypt data. Key materials: A tangible representation of a key. Examples include a key stored in computer memory, computer disk, smart card, or other key carrier. Private Key: (1) The key of a signature key pair used to create a digital signature. (2) The key of an encryption key pair that is used to decrypt confidential information. In both cases, this key must be kept secret. Public key: an encryption key pair that is used to encrypt confidential information. In both cases, this key is made publicly available normally in the form of a digital certificate. October 2012
Page - 173 -
Public key algorithm: A cryptographic algorithm in which the encryption and decryption functions are divided between a pair of mathematically related keys. In some common public key algorithms (e.g., RSA), the encryption/decryption functions are reciprocal, i.e., either key of the pair can be used to encrypt or decrypt, with the other key able to decrypt or encrypt respectively. Public key infrastructure (PKI): A set of policies, processes, server platforms, software and workstations used for the purpose of administering certificates and public-private key pairs, including the ability to issue, maintain, and revoke public key certificates. Registration Authority (RA): An entity that is responsible for identification and authentication of certificate subjects, but that does not sign or issue certificates (i.e., a Registration Authority is delegated certain tasks on behalf of an authorized CA). Session key: A key, typically for a symmetric algorithm, established between communicating parties for subsequent encryption/decryption of electronic messages, files, documents, data transmissions, etc. Its use is generally limited to that purpose and a single transaction or session. Signing private key: A private key used to create digital signatures. Subscriber A Subscriber is an entity that (1) is the subject named or identified in a certificate issued to that entity, (2) holds a private key that corresponds to the public key listed in the certificate, and (3) does not itself issue certificates to another party. This includes, but is not limited to, an individual or network device Symmetric algorithm: A cryptographic algorithm in which data is encrypted and decrypted using the same key. Abbreviations:
CA
Certification Authority
CAA Certification Authority Administrator CRL
Certificate Revocation List
FIPS
Federal Information Processing Standard
NIST National Institute of Standards and Technology
Page - 174 -
PKI
Public Key Infrastructure
RA
Registration Authority
October 2012
Authority/References:
Information Protection Standards Policy10 State Administrative Manual 5100 - Policy (Revised 09/08)11 National Institute of Standards and Technology (NIST) Special Publication (SP) 800-32 (26 February 2001) Federal Information Processing Standards (FIPS) Publication 196 (1997 February 18)
10
The DMV adopts the American National Standards Institute (ANSI) management information standards and the Federal Information Processing Standards (FIPS) and the National Institute of Standards and Technology (NIST) as baseline security standards and best practices to increase the confidentiality, integrity, and availability of DMV’s Information Assets. DMV must use the ANSI, FIPS, and NIST standards in their information management planning and operations. Adoption of these standards will facilitate the interorganizational sharing and exchange of equipment, data, software and personnel. Use of these standards will also facilitate communication (1) among state agencies; (2) between the state and its IT vendors; and (3) between the state and its IT information providers/recipients. This policy is in accordance with the State Administrative Manual Policy 5100. 11 The OCIO embraces the American National Standards Institute (ANSI) management information standards and the Federal Information Processing Standards (FIPS). The ANSI standards are national consensus standards which provide guidance on a variety of issues central to the public and industrial sectors. The FIPS standards are adopted and promulgated under the provision of Public Law 89–306 (Brooks Act) and Part 6 of Title 15, Code of Federal Regulations, and serve to improve the utilization and management of computers and automated data processing in the Federal Government. State agencies must use the ANSI and FIPS standards in their information management planning and operations. Adoption of these standards will facilitate the interorganizational sharing and exchange of equipment, data, software and personnel. Use of these standards will also facilitate communication (1) among state agencies; (2) between the state and its IT vendors; and (3) between the state and its IT information providers/recipients.
October 2012
Page - 175 -
Related Information:
The following information pertains to this policy:
Security Management Services
A PKI that uses this CP will provide the following security management services: Key generation/storage Certificate generation, modification, re-key, and distribution Certificate revocation list (CRL) generation and distribution Directory management of certificate related items Certificate token initialization/programming/management System management functions (e.g., security audit, configuration management, archive.)
Ownership
All keys, key materials, and certificates issued under this policy are the property of the DMV. Activities of the certification authority administrator and other entities, and all certificates issued and used under this CP, are intended solely for the conduct of DMV business and must conform to applicable DMV policies, Government regulations, and site policies.
References to this Certificate Policy
Persons or organizations within the DMV community operating a CA may issue public key certificates that reference this CP, provided that the CA conforms to the stipulations of this CP and operates in compliance with all other applicable DMV policies, regulations and standards. CAs that do not support the CP, but conform in all other ways to this CP may also issue certificates. Such CAs shall operate under this CP exclusively, so that all certificates issued by the CA can be presumed to be compliant with this CP.
Violations
Exceptions
Page - 176 -
Violation of this policy could result in the loss or limitation of access to systems and information resources, as well as disciplinary and/or legal action, including termination of employment or referral for criminal prosecution. The ISO of DMV’s OCIO must approve exceptions to this policy. Submit requests for exceptions to this policy via the Policy Exception Request form (EXEC 205).
October 2012
DMV Public Key Infrastructure & Certificate Policy Procedures Owner:
Information Security Office
Issue Date:
08/2011
Revision Date: Public Key Infrastructure & Certificate Policy Overview Certificate Types and Intended Use Identity Certificates
Certificates issued under this CP are identity certificates. They are issued for the purpose of binding the identity of the subscriber’s public key to the subject and other information contained in the certificate. They are not intended to convey information about the subscriber’s role, authority, clearance to access data, or authorization to perform business functions. Even though authorization may be implicit in these certificates simply because they exist in certain environments, it is not recommended that these certificates be used in that manner.
Separation of Certificates and Keys by Intended Use
Under this CP, certificates and related private keys used for creating and verifying digital signatures and/or authentication shall be separate from those used for encrypting and decrypting electronic messages, files, data transmissions, etc. The CA may issue one or both certificate types to an end entity.
Digital Signature and Authentication Use
Signing private keys and signature verification certificates may be used for creating and verifying digital signatures. Through the use of appropriate protocols, they may also be used as credentials for authentication. Requirements elsewhere in this CP state that the signing private keys shall never be made available to any party other than the subscriber. This provides the basis for nonrepudiation of digital signatures and positive authentication, and also makes signing keys and verification certificates unacceptable for encryption/decryption use because of the conflicting requirement to archive decryption private keys for possible data recovery use.
October 2012
Page - 177 -
Encryption Use
Encryption certificates and decryption private keys may be used for encrypting electronic messages, files, documents, data transmissions, etc., or establishing session keys for that purpose. Requirements elsewhere in this CP state that decryption private keys shall be archived by the CA, providing a mechanism for recovery of encrypted data in emergency situations. Because private keys are potentially available to more than one entity, they are not suitable for digital signature or authentication use.
Community and Applicability Community
The community applicable to this CP is certificate holders whose certificates have been issued under this CP. These will most always be affiliates of DMV whose certificates were issued by a DMV CA.
Applicability
Certificates and keys issued in accordance with this CP are intended for use in processing DMV information as stated below. 1. To permit public key encryption or session key establishment for the purpose of protecting all confidential, personal, or sensitive information, including personally identifiable information (PII) from unauthorized disclosure. The use of any encryption including public key is subject to the requirements of DMV polices, standards, and regulations. 2. To verify the data integrity of electronic messages, files, documents, data transmissions, etc., through the use of digital signatures. 3. To verify the identity affiliation of the signer of electronic messages, files, documents, data transmissions, etc., through the use of digital signatures. 4. To verify the identity of client computers, servers, and other computer systems. 5. To verify the identity of recipients of DMV information, including confidential, personal, or sensitive information, whose authorization to receive such information has been preestablished.
Registration of CA Names
Page - 178 -
To ensure unambiguous assignment of CA names within the DMV community, CA names that appear as part of subscriber distinguished names in certificates shall be registered with the DMV Policy Certification Authority for exclusive use within the community by the CA organization.
October 2012
Cross Certification Summary
Prior to using certificates issued by a cross-certified CA, it is the responsibility of the subscriber CA to inspect the CP of the crosscertified CA and determine what, if any, restrictions must be placed on the use of certificates issued by that CA. The subscriber CA may negotiate enhancements or assurances regarding operational procedures, facility, operations, administration, restrictions on certificate usage, certificate validity period, volume of transactions between subscribers, liability issues, etc.
Specification Administration Minimum Assurance Level
DMV has adopted a medium assurance level Certificate Policy with respect to measures specified for assuring trust: identification and authentication, key lengths, physical and computer security protections, etc.
Certificate Term (Validity Period)
Root CA certificate term will be no longer than twenty years. Policy CA certificate term will be no longer than ten years. Certificate term will be set at the minimum term necessary for the business function, but no more than that of the issuing CA. For example, a subscriber CA certificate may be set to term concurrent with the contract term for which it is associated.
Key Length
Refer to the Information Security Key Management Standards.
CA Server Location
Root level and policy level CA servers will be housed off-site in a State managed Tier 3 data center.
October 2012
Page - 179 -
General Provisions Additional CAA and RA Obligations Introduction
Refer to the Information Security 8.5 for the initial information on the roles and responsibilities of the entities responsible for issuing, managing, and using certificates and related cryptographic materials.
Certification Authority Administrator (CAA or CA)
Certification authorities are responsible for issuing and signing (certifying) public key certificates. They are also responsible for many aspects of managing these certificates, associated key materials, and other PKI services as specified elsewhere. 1. Accuracy of Representations By publishing a certificate that references the Certificate Policy (CP) in a repository accessible by members of the community, or otherwise conveying a certificate to a relying party, the CA certifies to all who reasonably rely on the information contained in the certificate that it has: issued the certificate to the named subscriber in accordance with the CP, and that the subscriber has accepted the certificate, and that the CA was operating in compliance with the CP at the time the certificate was issued and through the end of the validity period of all CRLs and ARLs issued by the CA. 2. CA Discretion to Issue Certificates Certificates are issued at the discretion of the CA. The CA shall reject any certificate request that does not appear to comply with all the stipulations of the CP. 3. Protection of CA Private Keys The CA shall protect its private keys. 4. CA Private Key Use The CA’s private key can be used for signing end entity/subscriber certificates, cross-certificates, CRLs, ARLs, other certificate types, and for CA management functions such as signing response messages confirming that requested actions have been accomplished. 5. Separation of Signature and Encryption Certificates The CA shall issue separate certificates for digital signature or authentication functions and for encryption/decryption functions. The CA shall be capable of separating certain management functions (e.g., key recovery, certificate revocation, expiration and renewal) for each certificate type, as detailed elsewhere in the CP.
Page - 180 -
October 2012
Additional CAA and RA Obligations (continued) Certification Authority Administrator (CAA or CA) (continued)
Revocation of Certificates The CA shall provide a mechanism to insure that compromised or otherwise invalidated certificates are promptly revoked. The revocation mechanism shall allow certificate users to obtain timely and unambiguous knowledge of the revocation status of any certificate issued by the CA. Key Recovery and Escrow The CA shall archive the private decryption key associated with any public encryption certificate issued by the CA, and maintain the capability to recover that key. This does not apply to those issued for digital signature and authentication use. Symmetric keys are not required to be escrowed.
Registration Authority
The CA may delegate or employ one or more Registration Authorities (RAs) for identification and authentication of certificate subjects, forwarding authentication results to the CA, relaying CA key generation passwords (not the keys themselves) to the user, conveying the CA’s public key certificate, and other administrative functions. 1. Requirement for Written Approval from CA Each RA operating within the domain of the subject CA shall have written approval for operation from the CA. The CA shall maintain a list of approved RAs. 2. Accuracy of Representations By performing duties as a registration authority for the subject CA, the RA certifies that he or she has accepted this responsibility and has agreed to operate in compliance with the CP. 3. Use of Private Keys for RA Functions Persons operating as RAs may use their normal end entity/subscriber private keys for RA functions.
October 2012
Page - 181 -
Publication and Repositories Introduction
The CAA may publish its CP. The DMV CA Root will be maintained and managed within the Information Services Division.
Method of Publication
CAs may publish the following information specified by conveying the information to entities reasonably requiring the information or by publishing the information in a repository accessible by those entities. Such repositories may be operated by the CA or by a separate organization (i.e., a third party). In the latter case, the subject CA shall retain adequate control to insure that the requirements of the CP are met. Copies of the CP. Copies of all Intersite Assurance Agreements, Intersite Trust Agreements, and cross-certification agreements entered into by the CA. Copies of public key certificates issued by the CA. Copies of all CRLs and ARLs issued by the CA.
Frequency of Publication
The CA shall publish certificates and other information promptly upon issuance or acceptance by the CA.
Access Controls
The CA shall insure that appropriate access controls are in place to prevent unauthorized writing, modifying, or deleting certificates, policy documents, CRLs, and other items placed in the repository.
Page - 182 -
October 2012
Confidentiality Normal Operation
In normal operation, CAAs shall not have access to the private keys of entities they certify. RAs and subscribers shall not have access to the private keys of any other end entity/subscriber. The previous statement is not intended to exclude an individual from being the subject of more than one entity certificate, in which case that individual would have access to the private keys for each of those entities.
Exceptions for Encrypted Data Recovery
Exceptions shall be made for cases in which the CAs and/or RAs must have access to the private decryption keys of the entities they certify or support for the purpose recovering encrypted data. These keys shall not be disclosed to any other party without the prior consent of the subscriber or authorized staff, or as required by law.
Exceptions for Conveying Private Keys to Subscribers
Exceptions to may be made for cases in which it is impossible or impractical to have the end entity/subscriber generate their own signing private keys. In such cases, the CA or authorized CA representative may generate the end entity/subscriber signing private keys and other key material and convey them to the end entity/subscriber. These keys shall be protected not disclosed to any other party. The CA shall document all such exceptions for each occurrence.
Exceptions for Diagnosing and Troubleshooting Problems
Exceptions may be made for cases in which it is impossible or impractical for a CA or RA to troubleshoot, diagnose, or repair system or user problems without access to the private keys of an end entity/subscriber. In such cases, the entity may disclose their private keys or activation data to the CA or authorized CA representative. These keys shall be protected not disclosed to any other party. In all such cases, the end entity/subscriber shall give informed, signed consent to the disclosure of their private keys or activation data. As soon as the problem is resolved, the CA shall take immediate measures to resume secure operation (such as revoking and re-issuing end entity/subscriber certificates, requiring the end entity/subscriber to change the activation data, etc.). The CA shall document all such exceptions for each occurrence, to include the signed statement of the subject entity.
October 2012
Page - 183 -
Certificate Processing Request Authentication of Individual Identity
Need to Present in Person In normal operations, the applicant must personally appear before the RA and be visually authenticated for the purpose of certificate issuance. Exceptions to the above may be made for cases in which it is impossible or impractical to have the end entity/subscriber appear in person. In such cases, the CA may issue a certificate based on the signed statement of a key executive affirming he or she personally knows the certificate subject and accepting responsibility for compliance with the CP. Minimum Credential(s) Required The CA or RA shall verify the applicant's identity by examination of an official badge issued by the DMV. If the applicant does not possess an official DMV badge, the CA or RA may verify the applicant's identity based on two other forms of identification, at least one of which shall be a photographic credential issued by the State of California.
Subject Naming in Certificates
In an effort to insure clarity in subject names, subject naming in certificates shall conform as closely as practical to subject naming guidelines utilized by DMV for its Active Directory services. If the end entity/subscriber is a person, the form of the distinguished name shall be officially recognized by the issuing entity. If that name differs from the name which appears on the credential used by the CA or RA to establish the subject's identity, the difference must be resolved by the issuing official through consulting an officially authoritative source (badge office, etc.)
Uniqueness of Subject Names
The CAA shall ensure that the distinguished name is unambiguous for all subjects within the domain of the CA.
Method to Prove Possession of Private Key
The registration/issuance process shall involve a stage in which the applicant demonstrates possession of the private signing key and a stage in which the applicant demonstrates possession of the private decryption key.
Page - 184 -
October 2012
Request (continued) Authentication of Computers and Machines as Subscribers
Certificates may be issued to named computer systems or machines incorporating a computer system, provided that a person is designated as the responsible party for assuring appropriate control and use of private keys and certificates issued. The CA or RA shall document this designation. The designated party shall be issued a certificate in compliance with the CP, except that the identification information in the certificate shall identify the subject computer system or machine. It is the responsibility of the designated person to insure that the keys and certificates are securely conveyed to the subject computer system or machine. The CA shall document the form(s) of identification used to verify this information.
Issuance Summary
The issuance of a certificate by a CA indicates a complete and final approval of the certificate application by the CA.
Installation Summary
The certificate issuance process shall include a step in which the subscriber explicitly indicates acceptance of the certificate as evidenced by installation. By accepting a certificate containing the identifier of the subscriber in the certificate, the subscriber agrees to the terms and conditions contained in the CP.
Renewal Summary
October 2012
Certificates and associated private keys issued to subscribers shall be replaced at specified intervals and a new certificate issued. In the case of a forgotten password, authentication shall be effected as for initial requests.
Page - 185 -
Revocation Overview
A revocation request may be authenticated on the basis of a valid digital signature recognized by the issuing CA or by a signed written request. Revocations can be made at the request of the subject or other authorized persons.
Reasons for Revocation
1. Key Compromise Certificates shall be revoked when the private key or activation data associated with the certificate is compromised. Key compromise includes unauthorized access to private keys or activation data, loss of private keys or activation data, stolen keys, or destroyed keys, or reasonable suspicion that any of these have occurred. 2. Subscriber Failure to Meet Obligations A certificate may be revoked by a CA upon failure of the subscriber to meet its obligations under the CP, DMV, State of California, or applicable Federal regulations, site policies, or any other agreement or regulation that may be in force. 3. Termination of Need for Certificate Subscriber certificates may be revoked when a valid need no longer exists for the certificate.
Revocation Requests
Entities that may request revocation of a certificate: i. ii. iii. iv.
the end entity/subscriber/certificate holder the issuing CA, the RA, on behalf of the end entity/subscriber, authorized organizational elements such as the subject’s Human Resources Department, or v. other authorized persons including DMV and law enforcement officials. All revocation requests, reasons for revocation, and the resulting actions taken by the CA shall be documented. Revocation requests shall be promptly forwarded to the CA or an RA following suspicion or detection of a compromise or any other event necessitating revocation.
Page - 186 -
October 2012
Revocation (continued) Re-Key after Revocation
Authentication of a subject for re-key following revocation depends upon the revocation reason. With a non-compromise revocation, re-key may be performed upon request. In an actual, suspected, or potential compromise situation, authentication shall be effected as for initial requests.
Certificate Verification Certificate Revocation List -Based Verification
Where CRLs are used as the basis of certificate verification, CAs shall issue CRLs on a regular basis. CRLs for certificates issued under the CP shall have a lifetime of no more than 25 hours. The CRL validity period or expiration time shall be stated within the body of the CRL. An end entity/subscriber that obtains a CRL from a repository (or other source) shall verify the authenticity of the CRL by checking its digital signature and the associated certification path. Certificates and CRLs may be stored locally on a relying party's system but, before use, each such certificate and CRL shall be validated to insure that it is still in effect and has not expired. A revoked certificate shall remain on the CRL until the certificate validity period expires.
Time-of-Use Verification
Time-of-use (“on-line”) certificate verification is not acceptable under the CP at this time.
Customization/Templates Process
The description of the certificates, CRLs and the directory schema should indicate which certificate and CRL extensions are present, whether they are marked critical or non-critical, which optional fields are included, what value ranges are allowed, and what action is expected of verifiers in response to any non-standard extensions. The location of these attributes in the directory shall be described.
Version
It is recommended that CAs issue X.509 Version 3 certificates, in accordance with the IETF PKIX certificate profile definition.
October 2012
Page - 187 -
Certificate Services Auditing Compliance Audit
The site PKI operating in accordance with the CP, including operational CAAs and RAs, will be subject to periodic review and audit, as required. Certification authorities operating under the CP shall be subject to periodic review and audit as specified by DMV.
Security Audit Procedures
The CA shall log or otherwise document for audit purposes the following information relating to the CA Workstation(s): 1. Creation of operating system accounts (privileged or not) 2. Installation of new software or software updates 3. Time and date of backups, shutdowns, and restarts of the system 4. Hardware changes, repairs, or upgrades 5. Audit log dumps (resets) 6. Transaction archive dumps (resets) 7. Audit logs shall be appropriately protected and time-stamped. Non-electronic audit records shall be signed and dated by appropriate personnel.
Backup and Recovery Summary
The CA facility shall also provide storage for backup and distribution media in a manner sufficient to prevent loss, tampering, or unauthorized use of the stored information. Backups shall be kept both for data recovery and for the archival of important information. At least one copy of backup material shall be stored at a location apart from the CA workstation, with equivalent security, to permit restoration in the event of a disaster to the primary facility. Backup media shall be adequately protected from access by unauthorized personnel.
Operational Requirements This part describes the operating requirements imposed by the CP Summary on CAs, RAs, and subscribers. It includes handling of certificate revocations, audit logs, and transaction archives. Records Archival Summary
CAs shall archive, and make available on authorized request, documentation of CA compliance with the CP. For each certificate and CRL, the records shall include the creation, issuance, use, suspension, revocation, expiration, and renewal activities Archives shall be retained and protected against modification or destruction for reasonable retention period, for example, three
Page - 188 -
October 2012
years, but no less than the lifetime of end entity/subscriber certificates. The CA shall ensure availability of the archive even if the CA operations are interrupted, suspended or terminated. Key Lifetimes and Changeovers Certificate Authority Keys
CAs have a single signing key with which they do all CA signing functions. CAs may not issue certificates that extend beyond the expiration dates of their own certificates and public keys; therefore, their certificate validity periods must be greater than those for users. To minimize risk to the CA through compromise of an authority’s key, those keys will be changed more frequently, and only the new key will be used for authority signing purposes from that time. The older, but still valid, certificate will be available to verify old signatures until all of the user certificates signed under it have also expired. For this medium assurance policy, CA signing keys shall have a validity period of 20 years and a lifetime of 8 years.
End entity/subscriber Keys
Prior to the expiration of the usage period of a key pair, a subscriber may request issuance of a new certificate, provided the previous certificate has not been revoked and a requirement for the certificate still exists. Up to two such renewals/re-keys may occur on-line at intervals not to exceed 25 months, without the need for the subject to reappear in person. Revoked or expired certificates shall not be renewed.
October 2012
Page - 189 -
CA Compromise and Disaster Recovery Summary
In case of a CA key compromise, the CA’s certificate shall be revoked (if possible by the CA signing the compromised key). Subsequently, the CA installation shall be re-established from the beginning by first re-establishing the CA equipment and re-issuing the CA certificate, then re-issuing all cross-certificates and all end user certificates. If, due to a disaster, the CA keys or archived end entity/subscriber keys are compromised, or there is reasonable suspicion that compromise may have been possible during the disaster or subsequent activities, then the CA shall be re-built as in the case of key compromise, above. All breaches or suspected breaches of CA integrity or security shall be reported promptly to DMV’s Chief Information Security Officer.
CA Termination Summary
Operation of the CA may be terminated for convenience, contract expiration, re-organization, or other non-security related reason. In this case, the CA shall attempt to notify all certificate subjects and relying parties of the termination. Certificates may continue to be considered valid at the discretion of the relying party. At or prior to termination, the CA must provide for disposition of audit, archive, and data recovery material from the terminated CA. The ISO must be notified immediately of the intent to terminate an operating CA.
Physical, Procedural, and Personnel Security Controls This part describes the physical, procedural, and personnel security Purpose controls required of CAs, RAs, and subscribers to protect their operations. Background
In considering the CA, RA, and end entity/subscriber security environment, increased exposure of data through the use of crosscertificates (for example, extending security services provided by the CA to users at remote sites), whether intended or not, must be included.
Related Information
Security measures and controls required by the CP are already in place as part of existing DMV policy, site security policy, computer protection plans, or other applicable policy.
Page - 190 -
October 2012
Physical Security Controls Physical Security Controls for Certification Authorities
Physical security controls shall be implemented to control access to CA hardware and software. This includes the CA workstation(s) (and servers), and any external cryptographic hardware modules or tokens. Physical access to the CA workstation(s) shall be limited to those personnel performing the appropriate role. Access control may be provided by keeping the CA workstation and related equipment in a locked room or a locked equipment cabinet (“CA facility”) with access only available to those personnel. Alternatively, the CA may be co-located in an area approved by DMV for housing other equipment of equivalent security and trust implications with access limited to appropriate personnel. Security checks for the CA facility shall be provided on a regular basis. The security check shall include: visual verification that cryptographic devices/tokens are securely stored if not in use that the doors and locks are properly secured, and that there have been no attempts at forceful entry.
October 2012
Page - 191 -
Physical Security Controls (continued) Physical Security Controls for Certification Authorities (continued)
The CA facility shall also provide storage for backup and distribution media in a manner sufficient to prevent loss, tampering, or unauthorized use of the stored information. Backups shall be kept both for data recovery and for the archival of important information. At least one copy of backup material shall be stored at a location apart from the CA workstation, with equivalent security, to permit restoration in the event of a disaster to the primary facility. Backup media shall be adequately protected from access by unauthorized personnel.
Physical Security Controls for Registration Authorities
For RAs, the only mandatory physical security control is use of a lockable file cabinet or other repository for storing records of end entity/subscriber issuance requests.
Physical Security Controls for Subscribers
End entity/subscriber private keys, activation data, and hardware tokens (if used) shall be protected in accordance with DMV or site policies for protection of data of equivalent security and trust implications. End entity/subscriber private keys may be stored in encrypted form on removable media, computer hard drive, or other unsecured medium, provided that the private key information is encrypted with an approved encryption algorithm, protected by the subject’s password or passphrase, and that access to the end entity/subscriber workstation is limited when the subject is not present (e.g., through the use of boot-up passwords, locking screen savers, etc.). The PIN or password used to unlock the private key protection or hardware cryptographic token shall never be stored in the same location as the private key or token itself. Preferably, PINs, passwords, etc., should be memorized and not written down. If a PIN or password must be written down, it shall be protected as above. The Information Security Incident Response Team Manual specifies certain emergency roles and conditions for storage, retrieval, and handling of this information by other persons. The CA shall document the use of such emergency procedures for each occurrence. Subscribers shall not leave their workstations unattended when the cryptography is in an unlocked state such that it could be utilized by an unintended party.
Page - 192 -
October 2012
Procedural Controls No procedural controls are prescribed at this time.
Summary Personnel Security Controls Personnel Security Controls for Certification Authorities
All CA personnel in sensitive positions, including, at least, the CAA and ISO positions shall have received proper training in the performance of their duties.
Personnel Security Controls for Registration Authorities
The CA organization shall ensure that each individual performing RA tasks has been trained in the operation of RA software and in the registration/issuance policies and practices of this guide. All RA appointments shall be documented by the CA.
Personnel Security Controls for Subscribers
Subscribers shall be made aware of any additional security practices they need to follow in the protection of their workstations and cryptographic devices when accessing their private keys.
IT Policy, Standards, Instructions and Guidelines References SP 800-15 Ver. 1 MISPC Minimum Interoperability Specification for PKI Components
SC-18 Mobile Code IT Policy, Standards, Instructions and Guidelines References SP 800-28 Ver. 2 Guidelines on Active Content and Mobile Code
SC-19 Voice Over Internet Protocol IT Policy, Standards, Instructions and Guidelines References SP 800-58 Security Considerations for Voice Over IP Systems
SC-20 Secure Name/Address Resolution Service (Authoritative Source) IT Policy, Standards, Instructions and Guidelines References SP 800-81 Secure Domain Name System (DNS) Deployment Guide
October 2012
Page - 193 -
SC-23 Session Authenticity IT Policy, Standards, Instructions and Guidelines References SP 800-52 Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations
Page - 194 -
October 2012
Glossary12 Understanding the responsibilities described in this manual requires a clear definition of the unique terminology used in this manual. For this reason a Glossary is provided here for reference. Acceptable Use Statement: A policy document that a user must agree to sign and comply with in order to be provided with access to personal, sensitive, and confidential information belonging to or maintained by an organization, access to the network of an organization, or access to the Internet. Also referred to as an annual security disclosure statement or a confidentiality agreement. Access: A person or process's ability to use a data resource. Accessibility: The state in which information is available for its intended use. Access Control: The ability to grant or deny to a user permission to access all or part of a data resource. Access Control Administrator: The person(s) or unit(s) responsible for implementing and maintaining the permissions granted by the Data Resource Manager. Accountability: The principle under which individual users will be held responsible for actions that occur within a system. Administratively Directed Access Control: Access control in which administrators control who can access Information Assets. Annual Security Disclosure Statement: See Acceptable Use Statement definition. Application Owner: The point of contact for a DMV Application or system. The individual can also be identified as the Data Resource Manager (DRM). Application: A computer program or a set of programs that accomplish a business function or task. Audit Log: The records that document the activities occurring to the data resource. Auditing: The process of making and keeping the records necessary to support accountability. Authentication Method: The authentication mechanism used at the time of user account login. Authentication: (a) Security measure designed to establish the validity of a transmission, message, or originator, or a means of verifying an individual's authorization to receive specific categories of information. (b) Providing assurance regarding the identity of a user or a data resource.
12
Incorporates definitions is previous version, Appendix A.
October 2012
Page - 195 -
Authenticity: The state of being a true, valid, and unquestionably acceptable representation of that which it is intended to represent. Authorization: The process of determining whether a user is allowed access to a data resource. Automated File: Electronically stored data. Availability: The concept that a given data resource will be usable when and where it is needed. Base Line Information Security Controls: Measures generally accepted in the industry to ensure information security for business applications similar to that under consideration. Breach in the Security of the System: Unauthorized acquisition of computerized unencrypted personal information, as defined above, that compromises the security, confidentiality, or integrity of personal information maintained by DMV. Good faith acquisition of personal information by an employer or agent for the Department does not constitute a security breach, provided the personal information is not used or subjected to further unauthorized disclosure. CD: A compact disc (sometimes spelled disk) is a small, portable, round medium made of molded polymer for electronically recording, storing, and playing back audio, video, text, and other information in digital form. Certificate Policy (CP): A Certificate Policy is a specialized form of administrative policy tuned to electronic transactions performed during certificate management. A Certificate Policy addresses all aspects associated with the generation, production, distribution, accounting, compromise recovery and administration of digital certificates. Indirectly, a certificate policy can also govern the transactions conducted using a communications system protected by a certificate-based security system. By controlling critical certificate extensions, such policies and associated enforcement technology can support provision of the security services required by particular applications. Certificate: A digital representation of information which at least (1) identifies the certification authority issuing it, (2) names or identifies its subscriber, (3) contains the subscriber's public key, (4) identifies its operational period, and (5) is digitally signed by the certification authority issuing it. Certification Authority (CA) An authority trusted by one or more users to issue and manage X.509 Public Key Certificates and CARLs or CRLs. Certification Authority Administrator (CAA): An entity responsible for issuing, signing (certifying), and managing public key certificates (sometimes referred to as a certificate authority.) Certification Authority Revocation List (CARL) or Certificate Revocation List (CRL): A signed, time-stamped list of serial numbers of CA public key certificates, including cross-certificates that have been revoked. Page - 196 -
October 2012
Classification: An access control management tool in which files or databases are assigned labels whose definitions state the appropriate level of public access, sensitivity, and criticality, and the justification for restrictions. Confidential Information: Information, the unauthorized disclosure of which could cause harm to an individual or organization. Confidentiality Agreement: See Acceptable Use Statement definition. Confidentiality: The state in which data that requires privacy, either due to legislation or to protect personal information, is guaranteed accessible only to authorized persons. Correctness: The property of meeting certain criteria, such as a program being consistent with a specification. Critical Information: Information that is so important to an agency that its loss or unavailability is not acceptable Even short term unavailability of the information would have significant impact on the health and safety of the public or State workers, on the fiscal or legal integrity of State operations, or on the continuation of essential agency programs. Data Custodian: An employee or organizational unit, such as the Division of Information Systems, acting as the physical caretaker of a database or automated file. Data integrity: Assurance that the data are unchanged from creation to reception. Data Resource Manager Summary: The portion of the DRM Handbook that is completed by the DRM and inventoried in the Information Security Office. It contains information regarding database classification, database component parts, and the resources (hardware, software, and personnel) necessary for the database to function. Data Resource Manager (DRM): The individual responsible for making decisions on behalf of the Department regarding use, identification, classification, and protection of a specific data resource. Data Subjects: Individuals whose sensitive and/or personal information is reviewed or requested. Database: A method, in the form of one or more computer programs, for collecting and indexing data for multiple users and/or multiple purposes, storing the data in such a way that there is only one copy. The word "database" is frequently used to refer to the data itself Delegated Administrator: An administrator account, either a Participating Organization (PO) Delegated Administrator or an Entitlement Administrator. Denial of Service: Reducing the availability of a data resource below the level needed to support DMV's mission. Dependability: The factor of reliability that a system will operate correctly.
October 2012
Page - 197 -
Disaster: A condition in which an Information Asset is unavailable as a result of a natural or human-induced occurrence that is of sufficient duration to cause significant disruption in the accomplishment of an agency's mission, as determined by agency management. Disaster Recovery Plan: A documented plan that allows an organization to recover its critical applications within acceptable time frames in the event of a loss of service. DMV Directory Services (DMVDS): The infrastructure run by DMV which enables the centralization of authentication and access control for applications on the DMVeNet, and which provides single sign-on functionality for applications on the DMVeNet. DVD: The digital versatile disc stores much more than a CD and is used for playing back or recording movies. The audio quality on a DVD is comparable to that of current audio compact discs. A DVD can also be used as a backup media because of its large storage capacity. Electronic Devices: Devices that contain long term electronic memory, including, but not limited to, hard drives, facsimile machines, scanners, copiers, printers, cell phones and digital cameras. Electronic Media: Removable storage devices that include, but not limited to disks, CDs, cassettes, USB drives. Encryption certificate: A certificate containing a public key that is used to encrypt electronic messages, files, documents, or data transmissions, or to establish or exchange a session key for these same purposes. End Entity (EE): An end entity is a subscriber, a relying party, or both. Entitlement Administrator: An administrator account which is able to grant and remove DMV application entitlements to user accounts, potentially across POs. Entity: A CA, RA, or end entity. Firewall: A firewall is a computer system or set of computer systems, that controls and reports on activities that are permitted to take place between two networks or parts of a network. A firewall is typically installed between a private network (such as DMVWeb) and the Internet, although firewalls can be used to control traffic between parts of a private network (such as between LAD's network and the rest of DMVWeb). Flash Drive: A plug-and-play portable storage device that uses flash memory and is lightweight enough to attach to a key chain. The computer automatically recognizes the removable drive when the device is plugged into its USB port. A flash drive is also known as a keychain drive, USB drive, or diskon-key. Good Faith: An honest intent to act without taking an unfair advantage over another person. Page - 198 -
October 2012
Government and Industry Partners: The term used in this document for external personnel who access the DMV systems performing transactions (including inquiries) for their employer or for DMV. Handheld wireless device: A communication device small enough to be carried in the hand or pocket and is also known as a Personal Digital Assistant (PDA). Various brands are available, and each performs some similar or some distinct functions. It can provide access to other internet services, can be centrally managed via a server, and can be configured for use as a phone or pager. In addition, it can include software for transferring files and for maintaining a built-in address book and personal schedule. Hardware: Computers, printers, disk drives, and other machinery and the connections used in electronic data processing. Identity certificate: A certificate issued for the purpose of binding the identity of the subject (as stated in the certificate) to a public key issued to that subject. In X.509 certificates, the identity of the subject is equivalent to the Distinguished Name of the subject. Information Assets: (a) Computing hardware, e.g., servers, network components, workstations, laptops, smart phones, tablets, removable storage devices, etc. (b) databases, data processing capabilities, automated files and the documents and hardcopy records they represent (c) software such as automated programs, applications and operating systems, communications and collaboration tools (d) network-attached devices, such as storage, copiers, and facsimile machines (e) information technology infrastructure, e.g., network, routers, firewalls, switches (f) Essential public resources including DMV information, whether in hardcopy or electronic format Information Integrity: The condition in which information or programs are preserved for their intended purpose, including the accuracy and completeness of information systems and the data maintained within those systems. Integrity is assured when data can be changed only in a specified and authorized manner. Information Security: The people, procedures, policies and technological measures used to protect Information Assets from destruction, unauthorized modification, unauthorized access or disclosure, and misuse. Secure Information Assets are those whose availability, accessibility, authenticity, utility, and confidentiality, where required, are ensured. Internet: A private network of computers that communicate using a standard protocol suite to selectively share information with trusted network partners.
October 2012
Page - 199 -
Intranet: The computer networks within DMV to provide DMV employees specific information to improve their ability to conduct department business. The Intranet will not be available to the public. DMV will refer to its Intranet as the DMVWeb. Internet: The world-wide system of large computer networks joined together over high speed data links that provides connections through the use of standardized protocols. DMV makes information and services available to external customers through the Internet. Key materials: A tangible representation of a key. Examples include a key stored in computer memory, computer disk, smart card, or other key carrier. Key: A value supplied to a cryptographic algorithm to encrypt or decrypt data. Local Area Network (LAN) Typically, a LAN is owned, operated, and managed locally rather than by a common carrier. A LAN, through a common network operating system, can connect servers, workstations, printers, and mass storage devices, enabling users to share resources, applications and functionality. The types of applications provided by a LAN include distributed file storing, remote computing, and messaging. Malicious Code: Hardware, software, of firmware that is intentionally included in a system for an unauthorized purpose. Monitoring: Recording of relevant information about each operation by a user on a data resource that is maintained in an audit log. National Institute of Standards and Technology (NIST): Provide standards and technology to protect information systems against threats to the confidentiality of information, integrity of information and processes, and availability of information and services in order to build trust and confidence in Information Technology (IT) systems. Network Address Translation (NAT): Network Address Translation (NAT) is the translation of an Internet Protocol (IP) address used within one network to a different IP address known within another network. This mapping process helps ensure security since each outgoing or incoming request must go through a translation process that also offers the opportunity to qualify or authenticate the request or match it to a previous request. Network: Associated electronic components interconnected for communication and resource sharing. Owner of Information: An organizational unit or individual having responsibility for making security decisions regarding an automated file or database. At DMV, this is the Data Resource Manager. Participating Organization (PO): The State Government entity, political subdivision of the State, corporation, trust, estate, incorporated or unincorporated association, or other legal entity that establishes and maintains user accounts on the DMVDS, and/or provides applications which use the DMVDS. Page - 200 -
October 2012
Password: A sequence of characters chosen by and known only to the user that is entered into a system for purposes of identification. Patch: A patch (sometimes called a "fix") is a quick-repair job for a piece of programming. During a software product's test distribution or try-out period and later after the product is formally released, problems (called bugs) will almost invariably be found. These bugs can result in functionality problems and/or make the programming vulnerable to security breaches. A patch is the immediate solution that is provided to users to fix the bug and eliminate a problem or mitigate the security vulnerability. The patch is not necessarily the best solution for the problem and the product developers often find a better solution to provide when they package the product for its next release. Personal Information: Any information which identifies or describes an individual and can be used to identify, contact, or locate a person to whom the information pertains. This includes, but is not limited to a first name or first initial and last name of an individual; home address; home phone number; physical description; California driver license number or identification card number; vehicle registration plate number; financial information; Social Security number; medical, employment or education history. Personally Identifiable Information: Any information that is maintained by an agency that identifies or describes an individual, including, but not limited to, his or her name, social security number, DL/ID number, physical description, home address, home telephone number, financial matters, and medical or employment history. (Source: California Civil Code Section 1798.3 (a)) Private Key: (1) The key of a signature key pair used to create a digital signature. (2) The key of an encryption key pair that is used to decrypt confidential information. In both cases, this key must be kept secret. Proprietary Information: Computer programs, files, and data owned by a company or government agency. These programs need protection from disclosure and alteration by unauthorized persons. Public Information: Any information prepared, owned, used, or retained by a State agency and not specifically exempt from the disclosure requirements of the California Public Records Act or other applicable State or Federal laws, and which does not fall under the definitions of Confidential or Proprietary Information. Public key algorithm: A cryptographic algorithm in which the encryption and decryption functions are divided between a pair of mathematically related keys. In some common public key algorithms (e.g., RSA), the encryption/decryption functions are reciprocal, i.e., either key of the pair can be used to encrypt or decrypt, with the other key able to decrypt or encrypt respectively.
October 2012
Page - 201 -
Public key infrastructure (PKI): A set of policies, processes, server platforms, software and workstations used for the purpose of administering certificates and public-private key pairs, including the ability to issue, maintain, and revoke public key certificates. Public key: an encryption key pair that is used to encrypt confidential information. In both cases, this key is made publicly available normally in the form of a digital certificate. Registration Authority (RA): An entity that is responsible for identification and authentication of certificate subjects, but that does not sign or issue certificates (i.e., a Registration Authority is delegated certain tasks on behalf of an authorized CA). Rendering Data Anonymous: the process of replacing identifying information within collected data with substitute data for a temporary time or location. Requirement: An aspect of system behavior needed to enforce a given policy. Risk: The likelihood that a vulnerability may be exploited, or that a threat may become harmful. Security Incident: pertains to information in electronic and paper records. A DMV sensitive, personal or confidential information security incident involves: 1. Unauthorized or accidental access and/or use of Department data. 2. Unauthorized disclosure from, modification to, distribution or destruction of departmental automated or hardcopy files, data, or databases. 3. Damage to and misuse of information assets, or interference with information technology operations. 4. Attempts (failed or successful) to gain unauthorized access to a system or its data. 5. Unauthorized use of a system for the processing or storage of data. 6. Unauthorized changes to state protected assets, as defined in SAM 5320. 7. Theft, damage, destruction, or loss of state-owned information technology (IT) equipment or any electronic devices containing confidential, sensitive, or personal information. 8. Unauthorized access to confidential, sensitive, or personal information. 9. Theft, loss, damage, unauthorized destruction, unauthorized modification, or unintentional or inappropriate release of any state data (including electronic, paper, or any other medium) classified as confidential, sensitive, or personal. 10. Use of state information in commission of a computer crime. 11. Social engineering and requests for unauthorized information 12. Any other incidents that violate departmental, state or federal policies, regulations, or privacy laws resulting in the unauthorized access to or use of Department data.
Page - 202 -
October 2012
Sensitive Information: Information maintained by State agencies that requires special precautions to protect it from unauthorized modification or deletion. Sensitive information may be public, proprietary, or confidential, and requires a higher than normal assurance of accuracy and completeness. The controlling factor for sensitive information is that of integrity. Separation of Duties: A principle of design that separates functions with differing requirements for security or integrity into separate protection domains. Session key: A key, typically for a symmetric algorithm, established between communicating parties for subsequent encryption/decryption of electronic messages, files, documents, data transmissions, etc. Its use is generally limited to that purpose and a single transaction or session. State Administrative Manual. (SAM): A reference source for statewide policies, procedures, regulations and information developed and issued by authoring agencies such as the Governor's Office, Department of General Services (DGS), Department of Finance (DOF), and Department of Personnel Administration. In order to provide a uniform approach to statewide management policy, the contents have the approval of and are published by the authority of the DOF Director and the DGS Director. Signing private key: A private key used to create digital signatures. Subscriber A Subscriber is an entity that (1) is the subject named or identified in a certificate issued to that entity, (2) holds a private key that corresponds to the public key listed in the certificate, and (3) does not itself issue certificates to another party. This includes, but is not limited to, an individual or network device Symmetric algorithm: A cryptographic algorithm in which data is encrypted and decrypted using the same key. System: An interdependent collection of components that can be considered as a unified whole that, given a specific state and input, yields a set of outputs. Token: A physical device or logical code for user identification and authentication. Trojan Horse: In computers, a Trojan horse is a program in which malicious code (Viruses) is contained inside apparently harmless programming or data in such a way that it can get control and do its chosen form of damage, such as ruining the file allocation table on your hard disk. A Trojan horse can be considered a virus if it is widely redistributed. Trust: Belief that a system meets its specifications. User of Information: An individual having specific limited authority, granted by the appropriate Data Resource Manager, to view, change, add to, disseminate, or delete such information for authorized business purposes. User Provisioning: User provisioning refers to the creation, maintenance and deactivation of user objects and user attributes, as they exist in one or
October 2012
Page - 203 -
more systems, directories or applications, in response to automated or interactive business processes. UserID: A non-private code or designation that automated systems use to identify a person who or process that can be authorized to access Information Assets or can make statements affecting access control decisions. Utility: The state of being useful or fit for some purpose and designed for use or performing a service. Virus: A set of computer instructions, typically hidden, that attaches itself to executable programs and has the ability to reproduce itself, spread, and damage other programs or data. Vulnerability: A system weakness that can be exploited to alter the system's intended behavior. Wide Area Network (WAN) Definition: A wide area network (WAN) is a geographically dispersed telecommunications network. The term distinguishes a broader telecommunication structure from a local area network (LAN). A wide area network may be privately owned or rented, but the term usually connotes the inclusion of public (shared user) networks. IT Policy, Standards, Instructions and Guidelines References SAM 4819 General SAM 4819.2 Definitions SAM 5300.4 Definitions
Page - 204 -
October 2012
Acronyms APM
(DMV’s) Administrative Policy Manual
CA
Certification Authority
CAA
Certification Authority Administrator
CRL
Certificate Revocation List
DA
Delegated Administrator
DRM
Data Resource Manager
DRMC
Data Resource Managers Council
FIPS
Federal Information Processing Standard
ITPL
Information Technology Policy Letter
LAN
Local Area Network
NAT
Network Address Translation
NIST
National Institute of Standards and Technology
PKI
Public Key Infrastructure
RA
Registration Authority
SAM
State Administrative Manual
SPC
Strategic Planning and Control
SPCB
Strategic Planning Control Branch
WAN
Wide Area Network
October 2012
Page - 205 -
Commonly Referenced Forms Policy Exception Request – EXEC 205 Internal users, click here to link to the EXEC 205 on the DMV Web.
Page - 206 -
October 2012
Acceptable Use Statement – DMV 350 Internal users, click here to link to the DMV 350 on the DMV Web.
October 2012
Page - 207 -
Page - 208 -
October 2012
Acceptable Use Statement (DMV 350) Procedures Introduction As stated in the Acceptable Use policy, the Acceptable Use Statement at the DMV helps ensure that all individuals accessing the DMV network understand their responsibilities as they pertain to the information security policies and procedures of the Department. Initialing each statement and signing both sides of an acceptable use statement is a training tool to remind all users of the commitment of the Department to protect personal, sensitive, and confidential information at the DMV from inappropriate disclosure or misuse. These procedures will assist managers, supervisors, employees and other users comply with the Acceptable Use policy. Procedures New Employees and Other Users As indicated on the New Employee Orientation (ADM 1304), supervisors shall provide the Acceptable Use Statement to new employees. Supervisors shall discuss the individual statements as necessary so that the employee understands how the Acceptable Use Statement applies to the employee’s scope of duties. DMV staff that manages vendors or contractors shall ensure these users have completed an Acceptable Use Statement. Change in Scope of Duties Supervisors shall provide the Acceptable Use Statement to an employee with a change in scope of duties (new assignment, promotion, transfer, for example) so that the employee understands how the Acceptable Use Statement applies to his/her new scope of duties. Annual Recertification Staff Meeting: Supervisors are encouraged to set aside time during a staff meeting or call a meeting specifically to review the Acceptable Use Statement with their staff. This allows the supervisors to provide examples for each statement that is relevant to the scope of duties of their staff. General Process: The Information Privacy Office is responsible for the annual training component related to the proper use and protection of Information Assets as required by State Administrative Manual (SAM) 5300.3. 1. In November/December of each year, employees receive annual memo directing them to: Complete refresher training, such as a video or computer-based training. Sign the Acceptable Use Statement. 2. An updated Protecting Personal Information (Lesson Plan) is made available for supervisors on the DMVWeb. 3. The Information Privacy Office works with the Chiefs of Staff of the various divisions to validate all users have a current completed Acceptable Use Statement in the supervisor’s October 2012
Page - 209 -
working file and a list of users trained (Protecting Personal Information Training Report, ADM 6030). 4. Once all users have completed the annual process, the Information Security Office will submit the Agency Risk Management and Privacy Program Compliance Certification (SIMM 70C) to the State Chief Information Officer (OCIO). DMV staff that manages vendors or contractors shall ensure recertification for these users. What if one of the statements does not apply? One of the objectives of the Acceptable Use Statement is user awareness. While one of the statements may not apply at the time an employee signs the Acceptable Use Statement, the employee’s scope of duties may change during the year. If one of the statements on the Acceptable Use Statement (DMV 350) does not apply to a particular employee’s scope of duties, for example, Access #9 regarding remote access, then the employee may indicate “N/A” and initial the statement. Supervisors should identify which statements do not apply to their staff based on their scope of duties to ensure consistency. Assistance is available from the Information Security Office (916) 657-5830 or the Information Privacy Office (916) 657-0201 or (
[email protected]). What if an employee refuses to sign? As stated in the Acceptable Use Policy and on the Acceptable Use Statement itself, all users that have access to information maintained by the DMV must agree in writing to perform their work according to the information security policies and procedures. If an employee refuses to sign the Acceptable Use Statement, the employee’s supervisor may do one of the following: A. Meet with the Employee 1. Read each statement to the employee. 2. After each statement is read, ask the employee if the employee understands how the statement applied to his/her scope of duties. If the employee does not understand, discuss statement with the employee providing examples applicable to the employee’s scope of duties that illustrate the relevance of the statement. Refer also to the supporting documentation in the DMV 350 References. Once the employee understands the statement, either the employee or the supervisor may initial the statement. 3. After all statements are initialed, ask the employee to sign both sides of the Acceptable Use Statement.
Page - 210 -
October 2012
4. If the employee still refuses to sign, the supervisor shall: i. Document that the supervisor read each statement to the employee; ii. Document that the employee understood each statement as it pertains to the employee’s scope of duties; iii. Indicate Employee refuses to sign on both sides of the Acceptable Use Statement; iv. Sign and date both sides of the Acceptable Use Statement; v. Give the employee a copy of the signed and dated Acceptable Use Statement ;and vi. File the Acceptable Use Statement in the supervisor’s working folder. B. Consult with Upper Management The supervisor shall consult with his/her chain of command for appropriate next steps. If needed, the supervisor may also contact the Compensation and Performance Management unit in the Human Resources Branch (HRB) and/or the Labor Relations Office both in the Administrative Services Division (ASD) for assistance.
October 2012
Page - 211 -
Acceptable Use Statement Embedded References When employees and supervisors have questions regarding the statements on the Acceptable Use Statement (DMV 350), this section provides the significant policies, standards, or other references in support of those statements.
Introduction The Department of Motor Vehicles (DMV) Information Security Awareness Program requires all individuals who access DMV information to sign this statement before beginning work and annually thereafter. State Administrative Manual (SAM) Section 5300.3: Agency Responsibilities
Failure to comply with information security and privacy policies, standards, and practices can have financial, criminal, and/or employment consequences for the general public, the DMV, and for you personally. All information must be treated carefully including information: On paper, within the DMV network, or other Information Assets (e.g., workstation, server, laptop, copier, smart phone, tablet, USB drive, software) Describing how systems operate or are protected, and Classified as confidential, sensitive, personal, or proprietary To maintain the confidentiality, integrity, and availability of DMV’s Information Assets and protect confidential, sensitive personal or proprietary information from unauthorized use, access, release, viewing by others, change, loss or deletion, I will comply with the following: IS 2012-03 IS 2012-37 IS 2012-15 IS 2012-20 IS 2012-34 IS 2012-26 IS 2012-06 IS 2012-36 IS 2012-38
Classifying and Handling Information Confidential or Sensitive Information on Desktop or Mobile Computers Confidentiality Requirements Desktop and Mobile Computer Security Electronic Mail Information Controls Information Security Awareness and Training Mobile Devices Security of Desktop and Mobile Computers and Related Materials and Equipment Administrative Policy Manual (APM) 7.680 Personal Communication Devices and Voicemail Desktop/Mobile Computing (DMC) Policy Mobile Devices/Media Standards Privacy Policy
Page - 212 -
October 2012
Access 5. I will only access DMV Information Assets using my assigned UserID and password and take reasonable safeguards to protect my password. For example, I will not write down my password or share it with others. IS 2012-24 Intranet Security and Procedures UserID and Password Standards
6. I will not leave my unlocked workstation unattended beyond a reasonable time or distance. IS 2012-17 IS 2012-22
Network Security Responsible Computing
7. I will scan files stored on any removable media for viruses prior to using on the DMV network. IS 2012-25 Firewall Security IS 2012-35 Internet Resource Use Procedures Information Security Policy Manual: Network Component Standards and Remote Access Requirements
8. I will not intentionally send confidential, sensitive, personal, or proprietary DMV information or files so that I can later access the information or files remotely or off-site. IS 2012-03 Classifying and Handling Information IS 2012-34 Electronic Mail Procedures Information Policy 6.100: Public Information Privacy Policy
9. I will not deliberately interfere with another user’s network access. IS 2012-35 IS 2012-22
Internet Resource Use Responsible Computing
10. I will not intentionally cause an interruption or denial of service, or interfere with normal software functions. IS 2012-35
Internet Resource Use
11. I understand that the State may monitor its Information Assets and retrieve any information contained in the network, the workstation I use, information stored locally on the hard drive, on removable media or other portable devices to ensure that the work of the DMV is conducted in an approved and efficient manner. IS 2012-11 IS 2012-34 IS 2012-35 IS 2012-14
October 2012
Accountability for the Source of Information, Updates and Changes Electronic Mail Internet Resource Use Transaction Auditability
Page - 213 -
12. I understand that I have no reasonable expectation of privacy when using DMV Information Assets. IS 2012-34
Electronic Mail
13. I will follow the DMV’s Remote Access Standards and the California Technology Agency Telework and Remote Access Security Standard (SIMM 66A) for remote connection, security training, and use of Outlook Web Access. IS 2012-35 Internet Resource Use IS 2012-36 Mobile Devices Mobile Devices/Media Standards Remote Access Standards
14. I will obtain written approval before connecting a non-State device (personal or contract staff laptop for example) to the DMV network. IS 2012-36
Mobile Devices
Disclosure 15. I will take reasonable precautions to protect all confidential, sensitive, personal, or proprietary DMV information (e.g. credit card number, social security number, particularly those verified by the Social Security Administration) and all portable devices. For example, use a privacy screen or secure in a locked cabinet. IS 2012-03 IS 2012-15 IS 2012-20 IS 2012-36 IS 2012-18 IS 2012-38
Classifying and Handling Information Confidentiality Requirements Desktop and Mobile Computer Security Mobile Devices Physical Security of Information Assets Security of Desktop and Mobile Computers and Related Materials and Equipment Mobile Devices/Media Standards
16. I will obtain written approval before transporting or storing confidential, sensitive, personal, or proprietary information in a vehicle, private storage or other off-site location. For example, attorneys and investigators may have written approval as part of their duty statement or office procedures to take documents to a hearing. IS 2012-03 IS 2012-04
Page - 214 -
Classifying and Handling Information Procedures Data Resource Managers
October 2012
17. I will only disclose DMV information, however communicated or transferred, to individuals authorized to lawfully receive it through appropriate government statutes and departmental policies and procedures. For example, using secure email or authorized encrypted media. IS 2012-03 Classifying and Handling Information Procedures IS 2012-34 Electronic Mail Procedures IS 2012-35 Internet Resource Use APM 6.100 Public Information Privacy Policy SAM 5345.2 Cryptography Driver’s Privacy Protection Act (Title 18, U.S. Code sections 2721-2725)
Use 18. I will only download, copy, and/or store DMV authorized software, audio (sound, music) or video files. IS 2012-20 IS 2012-35
Desktop and Mobile Computer Security Internet Resource Use
19. I agree to use DMV Information Assets only for the State of California’s business purposes. This includes state business with the federal government and any city, county, or other public agency. IS 2012-34 IS 2012-35 IS 2012-24 IS 2012-38 APM 7.680 Privacy Policy
Electronic Mail Internet Resource Use Intranet Security Security of Desktop and Mobile Computers and Related Materials and Equipment Personal Communication Devices and Voicemail
20. I will not make copies of DMV information for personal use nor remove materials or equipment from any DMV premises without approval. IS 2012-03 IS 2012-36 IS 2012-18 IS 2012-22 Privacy Policy
Classifying and Handling Information Procedures Mobile Devices Physical Security of Information Assets Responsible Computing
21. Any private or personal use of DMV Information Assets will be incidental and minimal consistent with Government Code Section 8314. IS 2012-29 IS 2012-34 IS 2012-35
October 2012
Desktop Computer Policy Electronic Mail Procedures Internet Resource Use
Page - 215 -
Employee Responsibility 22. I will immediately notify management of any actual or attempted security violations I may observe such as employee misuse, computer viruses, unauthorized attempts to gain access to a DMV building, a system or data, or other incidents as described in the DMV 145 booklet, Handling and Reporting Information Security Incidents. IS 2012-19 IS 2012-20 IS 2012-07 IS 2012-24 IS 2012-32 APM 7.680
Access to DMV Work Areas Desktop and Mobile Computer Security Information Security Incident Reporting and Follow Up Intranet Security Procedures Notification of Security Breach Involving Personal Information Personal Communication Devices and Voicemail
23. I will only create, read, update or delete DMV information for purposes necessary to perform my authorized job functions. IS 2012-03 IS 2012-22 Privacy Policy
Classifying and Handling Information Procedures Responsible Computing
24. I will only copy, change, or delete the files, documents, or software of another employee to perform my authorized job functions. IS 2012-03 IS 2012-35
Classifying and Handling Information Procedures Internet Resource Use
25. I will comply with Software License Agreements. I will not illegally use or copy software that is owned or licensed by DMV. 2003-01 Software Management State Administrative Manual, Section 4846
26. I will comply with all applicable patent, trademark, copyright, and other laws. IS 2012-20 IS 2012-38
Desktop and Mobile Computer Security Security of Desktop and Mobile Computers and Related Materials and Equipment U. S. Copyright Law: Title 17
27. Unless it is related to a Department investigation or similar authorized action I will not intentionally send, receive, or store information that is in violation of departmental policy. For example, information that is discriminatory, harassing, derogatory, defamatory, threatening, or obscene. IS 2012-34 APM 3.001 APM 3.040
Page - 216 -
Electronic Mail Procedures Equal Employment Opportunity Policy Sexual Harassment Prevention Policy
October 2012
28. I will not alter, disable, or otherwise intentionally bypass the virus protection software, patching processes or other security controls installed on or used by any DMV Information Asset. IS 2012-35 IS 2012-22
Internet Resource Use Responsible Computing
29. I will not intentionally destroy or dispose of any DMV information unless by authorized methods and in accordance with government statutes and DMV policy. IS 2012-03 IS 2012-15 IS 2012-34 APM 4.600
Classifying and Handling Information Procedures Confidentiality Requirements Electronic Mail Procedures Records Management and Recycling
30. I will store my current files, data, and e-mail messages only for the duration of their intended business purpose in accordance with DMV policy and procedures unless I am notified of a different retention period. IS 2012-34 Electronic Mail Procedures APM 4.600 Records Management and Recycling SAM Chapter 1600 – Records Management California Public Records Act (Government Code 6250 through 6276.48 Government Code 14740 -14770
31. I understand it is my responsibility to contact my supervisor for additional information and applicability of these provisions to my job functions. Government Code 19572
32. I understand that this statement shall not be deemed to waive the attorney-client privilege existing under applicable law. Attorney–client privilege is a legal concept that protects certain communications between a client and his or her attorney and keeps those communications confidential. The attorney–client privilege is one of the oldest recognized privileges for confidential communications. The United States Supreme Court has stated that by assuring confidentiality the privilege encourages clients to make "full and frank" disclosures to their attorneys, who are then better able to provide candid advice and effective representation.
33. I understand that failure to comply with any or all of these policies and/or provisions may result in loss or limitation of access to DMV Information Assets, disciplinary action, including dismissal, as well as civil or criminal penalties. IS 2012-33 IS 2012-35
Acceptable Use Internet Resource Use
34. I acknowledge that I have read, understand, and received a copy of this statement. IS 2012-33 IS 2012-06
October 2012
Acceptable Use Information Security Awareness and Training
Page - 217 -
Acceptable Use Statement Cross Reference Acceptable Use Statement Section Intro Access 1
2
Information Security Policy Manual
3
4
5
6
7
8
9
10
Disclosure Use 1
2
3
1
2
3
4
Employee Responsibility 1
2
3
4
5
6
7
8
9
10
11
12
13
Acceptable Use Access to DMV Work Areas Accountability: Source of Information, Updates & Changes Classifying & Handling Information/Procedures Confidential or Sensitive Information on Desktop or Mobile Computers Confidentiality Requirements Data Resource Managers Desktop & Mobile Computer Security Desktop Computer Electronic Mail /Procedures Firewall Security Information Controls Information Security Awareness & Training Information Security Incident Reporting Internet Resource Use/Procedures Intranet Security /Procedures
Information Security Policy Manual Mobile Devices
Page - 218 -
October 2012
Acceptable Use Statement Section Intro Access 1
Network Security Notification of Security Breach Physical Security of Information Assets Responsible Computing Security of Desktop & Mobile Computers Transaction Auditability
2 3
4
5
6
7
8
9
10
Disclosure Use 1
2
3
1
2
3
4
Employee Responsibility 1
2
3
4
5
6
7
8
9
10
11
12
13
Administrative Policy Manual (APM) 4.600 Records Management & Recycling 6.100 Public Information 7.680 Personal Communication Devices & Voicemail
October 2012
Page - 219 -
Acceptable Use Statement Section Intro Access 1
2
3
4
5
6
7
8
9
10
Disclosure Use 1
2
3
1
2
3
4
Employee Responsibility 1
2
3
4
5
6
7
8
9
10
11
12
13
Other Policies & Standards Desktop/Mobile Computing (DMC) Mobile Devices/Media Standards Privacy Policy Remote Access Standards Software Management UserID and Password Various State Administrative Manual (SAM) 5300.3 Agency Responsibilities Information Security Policy Manual: Network Component Standards and Remote Access Requirements SAM 5345.2 Cryptography; Driver’s Privacy Protection Act (Title 18, U.S. Code sections 2721-2725) DMV 145: Reference Guide To Handling & Reporting Information Security Incidents SAM 4846 U. S. Copyright Law: Title 17 APM 3.001 Equal Employment Opportunity Policy; APM 3.040 Sexual Harassment Prevention Policy SAM Chapter 1600 – Records Management; California Public Records Act (Government Code 6250 through 6276.48, Government Code 14740 -14770 Government Code 19572 Attorney–client privilege is a legal concept that protects certain communications between a client and his or her attorney and keeps those communications confidential. The attorney–client privilege is one of the oldest recognized privileges for confidential communications. The United States Supreme Court has stated that by assuring confidentiality the privilege encourages clients to make "full and frank" disclosures to their attorneys, who are then better able to provide candid advice and effective representation.
Page - 220 -
October 2012
E-mail Monitoring Request Form and Procedure
October 2012
Page - 221 -
Page - 222 -
October 2012
PCI-DSS Requirements & Security Assessment Procedures Matrix Version 2.0, October 2010 The following tables contain excerpts from the Payment Card Industry (PCI) Data Security Standard (DSS) requirements correlated to DMV documentation in support of those requirements. PCI-DSS Requirement
DMV Documentation
3.1.1 Implement a data retention and disposal policy that includes:
8.400:Retention of Electronic Fund Transaction Data (New. 10/09) 8.410 Retention of Credit Card Data (New. 12/11)
Limiting data storage amount and retention time to that which is required for legal, regulatory, and business requirements Processes for secure deletion of data when no longer needed Specific retention requirements for cardholder data A quarterly automatic or manual process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements 4.2 Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).
Electronic Mail Policy: 2012 revision planned to include PAN prohibition specifically.
5.2 Ensure that all anti-virus mechanisms are current, Network Components Standards actively running, and generating audit logs. 7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.
Access Control Administration
9.7 Maintain strict control over the internal or external distribution of any kind of media.
Classifying and Handling Information
9.10 Destroy media when it is no longer needed for business or legal reasons as follows:
Classifying and Handling Information
October 2012
However: 2011 ROC “there are no documented requirements to assign privileges to individuals based on job classification and function.” 4/5/2012: Grant Thorton will double check compliance.
Page - 223 -
PCI-DSS Requirement
DMV Documentation
12.1 Establish, publish, maintain, and disseminate a security policy that accomplishes the following:
Information Security Policy Manual
12.1.2 Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment.13
SAM 5305 Risk Management
12.1.3 Includes a review at least annually and updates when the environment changes.
Information Security Policy Manual
12.2 Develop daily operational security procedures that are consistent with requirements in this specification (for example, user account maintenance procedures, and log review procedures).
QSA 2011: Grant Thorton: “Through inquiry of personnel from ISD-NMPD, Server Group, and eGov it was noted that daily operational security procedures have not been developed.”
12.3 Develop usage policies for critical technologies (for example, remote-access technologies, wireless technologies, removable electronic media, laptops, tablets, personal data/digital assistants (PDAs), email usage and Internet usage) and define proper use of these technologies.
Acceptable Use Statement
12.4 Ensure that the security policy and procedures clearly define information security responsibilities for all personnel.
Information Security Policy Manual – Introduction
12.5 Assign to an individual or team the following information security management responsibilities:
Information Security Officer
12.5.1 Establish, document, and distribute security policies and procedures. 12.5.2 Monitor and analyze security alerts and information, and distribute to appropriate personnel.
Security Incident and Event Management (2012 policy under development)
12.5.3 Establish, document, and distribute security incident response and escalation procedures to ensure timely and effective handling of all situations.
Information Security Incident Reporting Team (ISIRT) Manual
12.5.4 Administer user accounts, including additions, Access Control Administration deletions, and modifications
13
Examples of risk assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30.
Page - 224 -
October 2012
PCI-DSS Requirement
DMV Documentation
12.5.5 Monitor and control all access to data.
Classifying and Handling Information
12.6 Implement a formal security awareness program Information Security Awareness and to make all personnel aware of the importance of Training cardholder data security. 12.6.1 Educate personnel upon hire and at least annually.14
Information Security Awareness and Training
12.6.2 Require personnel to acknowledge at least annually that they have read and understood the security policy and procedures.
Acceptable Use Statement
12.9 Implement an incident response plan. Be prepared to respond immediately to a system breach.
Information Security Incident Reporting Team (ISIRT) Manual
12.9.1 Create the incident response plan to be implemented in the event of system breach. Ensure the plan addresses the following, at a minimum:
Information Security Incident Reporting and Follow Up Disaster Recovery Plan Information Security Incident Response Team (ISIRT) Manual Note: Need to confirm that the following are addressed:
Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum Specific incident response procedures Business recovery and continuity procedures Data back-up processes Analysis of legal requirements for reporting compromises Coverage and responses of all critical system components
14
Note: Methods can vary depending on the role of the personnel and their level of access to the cardholder data.
October 2012
Page - 225 -
PCI-DSS Requirement
DMV Documentation
Reference or inclusion of incident response procedures from the payment brands 12.9.2 Test the plan at least annually.
Page - 226 -
Disaster Recovery plan is tested twice annually; however, the Incident Response Plan is not tested annually.
October 2012
Applicable Statutes California Penal Code Section 502 http://dmvweb/documents/Executive/ISP/Manual/cal_penal_code_Section502.pdf
Information Policies Act15 Civil Code Section 1798 Section 1798.3 Section 1798.14-1798.23 Section 1798.24-1798.24b Section 1798.25-1798.29 Section 1798.82-1798.84
Federal Federal Information Processing Standard (FIPS) Federal Information Security Management Act of 2002 (FISMA), PL 107-347, December 17, 2002 Federal Information Processing Standard (FIPS) 140-2, Security Requirements For Cryptographic Modules Federal Information Processing Standards (FIPS) Publication 196 (1997 February 18)
Government Code Section6250-6270 Section8314 Section11019.9 Section11546.1 Section14613.7a
15
Formerly Appendix B.
October 2012
Page - 227 -
Other American National Standards Institute (ANSI) California State Office of Privacy Protection Website Declaration of Rights, Article I, Section I DMV Privacy Policy Drivers Privacy Protection Act, Title 18, Part I, Section 2721 et seq Handling and Reporting Information Security Incidents (DMV 145) Information Technology-Code of Practice for Information Security Management, “Compliance, “Standard 17799.12.1.4 NIST National Institute of Standards and Technology (NIST) Special Publication (SP) 800-32 (26 February 2001) NIST SP 800-53: Recommended Security Controls for Federal Information Systems and Organizations Notification of Security Breach Involving Personal Information Policy Revision Request (PDF) The Privacy Act of 1974, 5 U.S.C., Section 552a Budget Letter 03-03, Notification of Information Technology Incidents and Computer Crimes
Page - 228 -
October 2012
Change Management Procedure Document
Version 2.0
CM1A Procedures v.2
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Change Management (Release 1A) – Process Flow................................................................ 3 Submit Remedy Change Request (CRQ) (Box #1) ................................................................... 4 Supervisor Review and Authorization (Box #2) ...................................................................... 7 Domain CAB (Box #3a, 3b, 3c) ................................................................................................ 9 Enterprise CAB (Box #4a, 4b, 4c) .......................................................................................... 12 Plan Release Readiness (Box #5)........................................................................................... 15 Design, Build, Test and Prepare for Deployment (Box #6) ................................................... 16 Deploy (Box #7) ..................................................................................................................... 18 QA Check/Approve (Box #8) ................................................................................................. 19 Confirm CRQ Complete and Close (Box #9) .......................................................................... 20 APPENDIX A – Prepare for CAB (for the DCAB Administrator role) ...................................... 21 APPENDIX B – Post and Ongoing CAB Activities (for the DCAB Administrator role)............. 22
Modification Log Date 1/5/2011
Version v2.0
Section All
4/27/2011
v 1.0
All
Modification Modified procedures to include information that was in the 1A training and revised based on Remedy 7.6 Upgrade (6/1/2011) Procedure format revised to be Process focused vs. Tool Focused
Author Tanima Pattani Tanima Pattani
Page 2 of 23
CM1A Procedures v.2
1.
Change Management (Release 1A) – Process Flow OTech Change and Release Management Process
Supervisor
Change Submitter
Submit
Change Authorize
Change Approve
Deploy
1 Submit Remedy CRQ
Classification
Emergency
Normal (Minor, Major)
2 Review & Authorize
No
Authorized
Latent
End
Yes
Domain Change Administrator
Approved Standard No (Reschd) End
Deployed
Yes
8 QA Check / Approve
Domain Change Advisory Board
No
3a Domain CAB Review & Authorize
Authorized
Yes
Classification
3b Domain CAB Assess Release Readiness
Minor
Enterprise Change Advisory Board
Authorized
No
3c Domain CAB Review Change Implementation
End
Approval Yes
Major
4a Enterprise CAB Review & Authorize
No
4b Enterprise CAB Assess Release Readiness
End
Yes
4c Enterprise CAB Review Change Implementation
No Approval
End
Change Specialist/ Assignee
Yes No 5 Plan release Readiness
6 Design, Build Test Prep for Deploy
7 Deploy
9 Confirmed Complete & Close
Yes
Successful
End
4/14/2011 Approved Standard
Minor
Major
Emergency
Latent
Multiple Classifications
Each box in this flow corresponds to a section in this document which will provide the procedural level information for each activity performed. Page 3 of 23
CM1A Procedures v.2
2.
Submit Remedy Change Request (CRQ) (Box #1)
Purpose:
To ensure that all changes are logged and tracked.
Description:
Create a Remedy record with details of the change requested. This includes: • Determine the Type of change • Create the Change Request in Remedy • Submit the Change Request
Owner:
Change Submitter
Possible Participants (Roles):
External Customer OTech Service Desk OTech staff
Possible Inputs:
• • • • •
Possible Outputs:
CRQ record in Remedy
Manual entry from a CSS request Generated from a Remedy SR Phone Call Email Walk-In
1. Determine the Type of change requested: • Standard: Scriptable, repeatable, low risk changes performed regularly without incident that impact only your Unit/Remedy Support Group. • Normal: A change that requires both Authorization and Approval to occur over 2 separate CAB meetings. It undergoes two reviews by Change Advisory Boards (CABs): Authorization to begin planning, building, and testing and Approval to release the change into the production environment o Minor: A Normal change that impacts only one domain and is more complex than a standard change. These changes are reviewed, authorized and approved at the Domain CAB (DCAB). o Major/Significant: A Normal change that is higher risk or impacts more than one domain. These changes will be reviewed, authorized and approved at both the DCAB and Enterprise CAB (ECAB). • Emergency: An urgent change not able to be Authorized and Approved at 2 separate CAB meetings thus increasing the level of risk to the production environment. • Latent: Documents a break/fix. A change request submitted after the change has been released to production in response to a critical INC. The change must be related to the INC record. These are reported at the DCAB and ECAB.
Page 4 of 23
CM1A Procedures v.2 2. Create the Change Request in Remedy using a template. Based on the type of change, populate the data fields as specified below: 2.1. STANDARD CHANGE If a new Standard CRQ is being requested, it must be entered as a NORMAL Change and in the SUMMARY, specify: “Nominee for Standard CRQ”. After 2 successive and successful implementations, the change may be approved to be a Standard by the DCAB Quorum. 2.1.1. A clear description of the change in the Summary 2.1.2. Provide details on the change in the Notes: 2.1.3. Provide the Requested Start and End Date/Time indicating when the change needs to be implemented. 2.1.4. Relate to other Remedy records if applicable 2.2. NORMAL CHANGE 2.2.1. A clear description of the change in the Summary 2.2.2. Provide details on the change in the Notes 2.2.3. Provide the Requested Start and End Date/Time indicating when the change needs to be implemented. For a Project Change*, the Requested Dates will reflect the timeframe for the Project from Planning through Implementation Completion. 2.2.4. Relate to other Remedy records if applicable *When there are a series of changes that need to occur as part of a single effort. These changes may be related to a higher level change called a “Project Change” which is identified by a Change Type of Project. This should be set in the Change Template. 2.3. EMERGENCY CHANGE 2.3.1. A clear description of the change in the Summary 2.3.2. Provide details on the change in the Notes: • Justification for the Emergency so that the Emergency CAB can make an informed decision regarding the approval for the change. • Risk of delaying the change to meet Normal Change cycle • Known details on the change 2.3.3. Provide the Requested Start and End Date/Time indicating when the change needs to be implemented. 2.3.4. Relate to other Remedy records if applicable 2.4. LATENT CHANGE 2.4.1. A clear description of the change in the Summary 2.4.2. Provide details on the change in the Notes: • Business/Technical reason for submitting as Latent • Known details on the change 2.4.3. Provide details regarding the change in the Work Info:
Page 5 of 23
CM1A Procedures v.2 • Test Plan – how and what testing was performed prior to implementation • Backout Plan – what was it and was it executed • Impact to Service and Customers 2.4.4. Provide the Actual Start and End Date/Time indicating when the change was implemented. 2.4.5. Relate the INC that justifies this CRQ to be a Latent 3. Submit the Change Request by selecting Next Stage from the Process Flow Status Bar 3.1. For a Standard CRQ or Emergency CRQ the CRQ will be Planning in Progress 3.2. For a Normal CRQ, the CRQ status will be Request for Authorization 3.3. For a Latent CRQ, Performance Rating should be set to “1” 3.3.1. Specify the Change Coordinator on the Assignment Tab 3.3.2. The CRQ will be Completed – Final Review Required NOTE: The Change Coordinator can only be specified after the initial submit (NEXT STAGE) because it is populated based on the template.
Page 6 of 23
CM1A Procedures v.2
3.
Supervisor Review and Authorization (Box #2)
Purpose:
To validate that NORMAL type CRQs are necessary, complete and that Risk and Impact are assessed prior to CAB review.
Description:
Review all NORMAL type CRQs to determine if the change should be pursued. Provide a quality check prior to CAB review to ensure that CRQs are properly documented and classified based on Risk and Impact, authorize the change, and engage impacted Support Groups.
Owner:
Supervisor of “Change Coordinator Support Group” based on the template used
Possible Participants (Roles):
Supervisor of the Change Coordinator Support Group Submitter Requestor
Possible Inputs:
NORMAL type CRQs Support Group Staffing and Workload
Possible Outputs:
Rejected or Approved CRQs Updated required data in the CRQs Notification to impacted support groups to attend DCAB meeting
Changes that meet the criteria for a Standard, Emergency, or Latent will automatically bypass this step.
1. Perform QA review and ensure the CRQs are advanced from Remedy status, Request for Authorization to ensure they will be on the CAB agenda. 1.1. Review and determine if the change should even be pursued. Considerations may include: • If there is already a change for this activity (duplicate CRQ) • Is there a standard change for this activity • Resources are not available • The CRQ does not align with standard services offered • There is no business need for this change 1.1.1. If the change is not pursued, provide an explanation in Work Info and cancel the CRQ by selecting Cancel from the Process Flow Status Bar 1.2. Review and ensure completeness of documentation in the Remedy CRQ including: • Summary (clear description of the change) • Notes (ensure Impact to Customers/Services specified if known) • Impact • Requested Start and End Dates/Times 1.1.2. Enter the Change Coordinator Name 1.1.3. If the change is not complete, work with the submitter or assignee to complete the documentation.
Page 7 of 23
CM1A Procedures v.2 1.3. Perform Risk Assessment by clicking on the Risk Wizard icon and answering the risk questions to determine the appropriate level of approval (DCAB only or DCAB and ECAB) 2. Authorize the Change by selecting Approve from the Process Flow Status Bar 3. The CRQ status will be Request for Change 4. Notify other OTech support groups that may be impacted by the change or whose participation is necessary for planning and implementation of the change to attend the DCAB review of the change Recommendation: Utilize the Remedy Email System to notify impacted support groups. This will create a Work Info entry record of the notification in the CRQ. While viewing the CRQ, select Email System from the left navigation bar, under Functions. Draft the email in the Email window that is displayed. Include your email id in the Recipient list so that a reply-all to the message will be sent to you. Click Send Email Now.
Page 8 of 23
CM1A Procedures v.2
4. Domain CAB (Box #3a, 3b, 3c) Purpose:
To provide a forum for all change decisions within a domain and ensure visibility to all exception changes.
Description:
A meeting of a group of qualified representatives responsible for the following within their domain: • To ensure NORMAL changes are authorized prior to planning. • To ensure NORMAL changes are approved prior to deploying. • To review all previous week’s Emergency and Latent changes as well as any changes that were not Successful.
Owner:
Domain CAB Administrator
Possible Participants (Roles):
Domain Chair/Manager DCAB members Impacted support group representatives Change Requestor Change Submitter Change Coordinator
Possible Inputs:
For the given domain, the DCAB Agenda and Change Management Status Report which includes: • Changes requesting DCAB authorization to plan. • Changes requesting DCAB approval to release. • Emergency Changes submitted or closed in Remedy since the last meeting. • Latent Changes submitted or closed in Remedy since the last meeting. • Any CRQs closed since the last meeting with a Closure Status reason other than Successful. ECAB minutes ECAB project list Change Management Freeze Calendar CAB Process Checklist
Possible Outputs:
Authorized and Approved changes CRQ Work Info Updates DCAB Minutes Action Items Items identified for Change Management Continual Service Improvement
The DCAB meeting is for decision making vs. technical discussions and solution definition.
Page 9 of 23
CM1A Procedures v.2 1. Prepare for the DCAB as documented in Appendix A 2. Execute DCAB 2.1. CAB Manager reviews the ECAB minutes 2.2. Review and obtain updates for Previous Action Items 2.3. Review Changes released last week (Box #3c – Review Change Implementation) 2.3.1. Review Closed Changes • CRQs with a timing of Latent or Emergency: review and discuss why the change was latent or an emergency with a goal of avoiding future occurrences.
•
CRQs with a status reason of not Successful (Unsuccessful, Successful with Issues, or Backed Out): review and discuss the change with a goal of avoiding future occurrences.
•
If a Standard change was not Successful, the CAB quorum should review the change to determine if it should be a NORMAL change until proven successful.
•
Document decisions, actions, recommendations in the Work Info of the given change (based on the agenda document) 2.4. Review Changes requesting Approval to Release on the CAB Console (Box #3b – Assess Release Readiness) 2.4.1. Review Release Readiness Checklist. 2.4.2. Ensure all Approval Criteria is discussed and understood (on the last pages of the CAB agenda)
2.4.3. Ensure Scheduled Start Date/Time and Scheduled End Date/Time are valid 2.4.4. Investigate and address any scheduling conflicts 2.4.5. Ensure the following Work Info entries are complete and accurate: • • • •
Service Impact (Services and Customers impacted) Risk Assessment (the possible risk to services and customers) Test Plan (how the change is going to be tested or why it cannot be tested) Backout Plan (how will the environment be restored to its prior state or if it is not possible) 2.4.6. Verify with the change representative that the necessary resources (within and outside of their unit/domain) are identified and committed to implement the Change 2.4.7. Facilitate change discussion
2.4.8. Request quorum vote If the change is approved, select Approve from the Process Flow Status Bar in Remedy. •
If the CRQ is a Major Change, the status remains Scheduled for Approval for ECAB review otherwise, for a Minor or Emergency, the status will progress to Scheduled If there are questions, issues or additional documentation is required, update the Work Info with the details of what is needed for approval. The change will not be approved at the CAB. The CAB may grant “Conditional Approval”, the details of which should be noted in the Work Info, which allows the Change Coordinator a specified amount of time to
Page 10 of 23
CM1A Procedures v.2 update the CRQ and notify the DCAB Admin. The DCAB Admin will verify the update. (This may involve verification with the quorum.) If the change is Cancelled or Not Approved (i.e., CRQ is a duplicate or does not align with the standard services offered), document the reason in Work Info with Work Info Type: Cancellation Information and select Cancel from the Process Flow Status Bar in Remedy. 2.5. Changes requesting Authorization to Plan (Box #3a – Review and Authorize) 2.5.1. Ensure Requested Start Date/Time and Requested End Date/Time are valid • Investigate and address any possible conflicts 2.5.2. Verify with change representative that the necessary resources (within and outside of their unit/domain) are identified and committed to plan, build, and test the Change If the change is authorized, select Approve from the Process Flow Status Bar in Remedy. • If the CRQ is a Major Change, the status remains Request for Change for ECAB review otherwise, for a Minor, the status will progress to Planning in Progress If there are questions, issues or additional documentation is required, update the Work Info with the details of what is needed for authorization and do not progress the change If the change is Cancelled or not Authorized (i.e., CRQ is a duplicate or does not align with the standard services offered), update the Work Info, Work Info Type: Cancellation Information and select CANCEL from the Process Flow Status Bar in Remedy. 2.6. Identify Change Management (CM) Process improvement opportunities
2.6.1. Review previous process improvement opportunities. CM Continual Service Improvement (CSI) representative to provide any updates. 2.6.2. Discuss and add any new process improvement opportunities that the DCAB Admin and Chair will take to the Change Management CSI meeting.
3. Perform post and ongoing CAB activities as documented in Appendix B
Page 11 of 23
CM1A Procedures v.2
5. Enterprise CAB (Box #4a, 4b, 4c) Purpose:
To provide a forum for all change decisions within a domain and ensure visibility to all exception changes.
Description:
A meeting of a group of qualified representatives responsible for all Enterprise Domains: • To ensure Major changes are authorized prior to planning. • To ensure Major changes are approved prior to deploying. • To review all previous week’s Emergency and Latent changes as well as any changes that were not Successful.
Owner:
Enterprise CAB Administrator
Possible Participants (Roles):
All Domain Chairs/Managers Change Management Process Sponsor Change Requestors Change Submitters Change Coordinators Supervisor of Change Coordinator
Possible Inputs:
The ECAB Agenda includes: • Changes requesting ECAB authorization to plan • Changes requesting ECAB approval for release • Emergency Changes submitted or closed in Remedy since the last meeting. • Latent Changes submitted or closed in Remedy since the last meeting. • Any CRQs closed since the last meeting with a Closure Status Reason other than Successful. ECAB project list Change Management Freeze Calendar CAB Process Checklist
Possible Outputs:
Authorized and Approved changes CRQ Work Info Updates ECAB Minutes Action Items Items identified for Change Management Continual Service Improvement
The ECAB meeting is for decision making vs. technical discussions and solution definition.
1. Prepare for the ECAB as documented in Appendix A 2. Execute ECAB 2.1. Review and obtain updates for Previous Action Items 2.2. Review Changes released last week (Box #4c – Review Change Implementation) 2.2.1. Review Closed Changes • CRQs with a timing of Latent or Emergency: review and discuss why the change was latent or an emergency with a goal of avoiding future occurrences.
Page 12 of 23
CM1A Procedures v.2 •
CRQs with a status reason of not Successful (Unsuccessful, Successful With Issues, or Backed Out): review and discuss the change with a goal of avoiding future occurrences.
•
Document decisions, actions, recommendations in the Work Info of the given change (based on the agenda document) 2.3. Review Changes requesting Approval to Release on the CAB Console (Box #4b – Assess Release Readiness) 2.3.1. Review Release Readiness Checklist. 2.3.2. Ensure all Approval Criteria is discussed and understood (on the last pages of the CAB Agenda) 2.3.3. Ensure Scheduled Start Date/Time and Scheduled End Date/Time are valid 2.3.4. Investigate and address any scheduling conflicts 2.3.5. Ensure Service Impacts are clear and understood 2.3.6. Verify with the change representative and CAB Chairs of other engaged domains that the necessary resources are identified and committed to implement the Change 2.3.7. Facilitate change discussion 2.3.8. Request quorum vote If the change is approved, select Approve from the Process Flow Status Bar in Remedy. • The status will progress to Scheduled If there are questions, issues or additional documentation is required, update the Work Info with the details of what is needed for approval and do not progress the change If the change is Cancelled or Not Approved (i.e., CRQ is a duplicate or does not align with the standard services offered), document the reason in Work Info with Work Info Type: Cancellation Information and select Cancel from the Process Flow Status Bar in Remedy. 2.4. Changes requesting Authorization to Plan (Box #4a – Review and Authorize)
2.4.1. Ensure Requested Start Date/Time and Requested End Date/Time are valid • Investigate and address any possible conflicts 2.4.2. Verify with the change representative and CAB Chairs of other engaged domains that the necessary resources are identified and committed to plan, build, and test the Change If the change is authorized, select Approve from the Process Flow Status Bar in Remedy. • The status will progress to Planning in Progress If there are questions, issues or additional documentation is required, update the Work Info with the details of what is needed for authorization and do not progress the change If the change is Cancelled or not Authorized (i.e., CRQ is a duplicate or does not align with the standard services offered), update the Work Info, Work Info Type: Cancellation Information and select CANCEL from the Process Flow Status Bar in Remedy. 2.5. Identify Change Management (CM) Process improvement opportunities
Page 13 of 23
CMlA Procedures v.2 2.5.1.
Review previous process improvement opportunities. CM Continual Service Improvement (CSI) representative to provide any updates.
2.5.2.
Discuss and add any new process improvement opportunities for the ECAB Admin and ECAB Chair to take to the Change Management CSI meeting.
3.
Perform post and ongoing CAB activities as documented in Appendix B
Page 14 of 23
CM1A Procedures v.2
6.
Plan Release Readiness (Box #5)
Purpose:
To conduct the proper planning required for the change prior to implementing the change.
Description:
During this step, the Change Coordinator will engage applicable support groups to create a plan on how this change will be designed, built, tested and deployed based on domain specific process (i.e. SDLC).
Owner:
Change Coordinator (in the case of OTech, this is often the Change Submitter)
Possible Participants (Roles):
Support Groups Customers
Possible Inputs:
• •
Possible Outputs:
Configuration Items identified • Impacted by Change • Installed/modified/removed by the Change Schedule for design, build, testing and deployment OTech Customers Impacted OTech Services Impacted Tasks Risk Assessment Test Plan Backout Plan Related Remedy records (CRQ, WO)
Authorized Change Request Forward Schedule of Change (CAB Console)
1. Per support group procedures, produce the outputs identified as required for the specific change 2. Populate the Remedy CRQ with Planning Information if applicable 2.1. Create related WOs 2.2. Add relationships for all related INC, WO and CRQ records 2.3. Add Tasks into the Tasks Tab For CRQs where Change Type = “Change”, the following information is also required 2.4. Review/revise Impacted Customers/Services in Notes 2.5. Update the Work Info with the following: • Service Impact: Impact to Service and Customers • Risk Assessment: Risk of implementing the change i.e., what could be impacted if there are issues with implementation.
• Test Plan: Details on how this change was tested • Backout Plan: Details on how the environment will be rolled back to its prior state if needed
2.6. Review and revise the Release Readiness checklist (Task)
Page 15 of 23
CM1A Procedures v.2
7.
Design, Build, Test and Prepare for Deployment (Box #6)
Purpose:
Create design, build and test the change. Ensure change is ready for release into Production.
Description:
The change is designed, built and tested in a controlled non-production environment.
Owner:
Change Coordinator
Possible Participants (Roles):
Other Domain team members Non-domain team members Customers
Possible Inputs:
CRQs with status Planning in Progress
Possible Outputs:
• • • • •
Release Readiness checklist Scheduled Date/Times for Implementation Test Results Related Remedy records (CRQ, WO) Communication to stakeholders and customers
1. Per support group procedures, produce the outputs identified as required for the specific change 2. Populate Remedy CRQ with Implementation information 2.1. Review/revise Impacted Customers/Services in Notes 2.2. Review/revise the NOTES for Standards and for all other Change types, update the Work Info with the following: • Service Impact: Impact to Service and Customers • Risk Assessment: Risk of implementing the change i.e., what could be impacted if there are issues with implementation. • Test Plan: Details on how this change was tested (or why the change can not be tested) • Backout Plan: Details on how the environment will be rolled back to its prior state if needed
2.3. For Emergency CRQs, provide the following additional information: 3.3.3. Specify a Change Coordinator 3.3.4. Relate to other Remedy records if applicable 3.3.5. Provide Supervisor Approval email in Work Info 2.4. Create related WOs or CRQs if necessary 2.5. Enter the Scheduled Start Date/Time and Scheduled End Date/Time for when the change implementation/release will begin and end 2.6. Add Implementation Tasks into the Task Tab 2.7. Review and revise the Release Readiness checklist (Task) 3. Progress the Change using Next Stage from the Process Flow Status Bar in Remedy as follows: 3.1. For a Standard Change, progress until the status is Scheduled
Page 16 of 23
CMlA Procedures v.2 3.2. For all other Changes, progress until the status is Scheduled for Review If the CRQ is the first sub-change related to a Project CRQ, the Project CRQ must also be progressed to Scheduled for Review.
Page 17 of 23
CM1A Procedures v.2
8.
Deploy (Box #7)
Purpose:
To release the Change into the Production environment as approved.
Description:
The change is released into production and verified as documented in the CRQ.
Owner:
Change Coordinator
Possible Participants (Roles):
Possible Inputs: Possible Outputs:
Task Assignees Other Domain team members Non-domain team members Customers CRQs that have been Scheduled and are awaiting the scheduled date/time for Release.
• • • • • •
Modified production environment Install Results Test Results Work Info updates Task updates Related Remedy records (INC or WO)
1. On the Scheduled Start Date/Time and when staff are ready to release the change, progress the Change using Next Stage from the Process Flow Status Bar in Remedy. The new status will be Implementation in Progress. For a Project Change this should occur when the first dependent change is progressed to Implementation in Progress. 2. Deploy the change as per the documentation in the CRQ. 3. Update Tasks with Actual Start/Completion Date/Times as they are executed. Once all tasks are marked complete, the CRQ will automatically progress to a Completed status. For all non-Standard CRQs the status reason is Final Review Required. For a Standard CRQ, the status reason is Final Review Completed (Box #9). 4. If there are issues with Implementation, update the Remedy CRQ Work Info, Work Info Type, Install Results with details. 5. Create related WOs, INC or CRQs if necessary 6. Verify implementation of the change as documented in the CRQ (i.e., smoke test) A Project CRQ will remain in Implementation in Progress from the time the first sub-CRQ goes to Implementation until the last sub-CRQ is progressed to a Completed status.
Page 18 of 23
CM1A Procedures v.2
9.
QA Check/Approve (Box #8)
Purpose:
To ensure all CRQ documentation is complete and accurate prior to closure.
Description:
The Domain CAB Administrator will review the CRQ to ensure all necessary Work Info entries are complete and ensure that the dates/times of the change are accurate. Minimally, this is done prior to every DCAB meeting.
Owner:
Domain CAB Administrator
Possible Participants (Roles):
Possible Inputs: Possible Outputs:
Change Coordinator Supervisor of Change Coordinator Task Assignees Other Domain team members Non-domain team members All Completed CRQs with status reason Final Review Required.
• •
Update Work Info, Install Results Relate Remedy records (e.g., INC or WO)
1. Review Completed Changes with status reason Final Review Required 2. Verify the following documentation has been entered for the CRQ and work with Change Coordinator to complete if needed: 2.1. Ensure results are accurately documented in Work Info Type, Install Results (e.g., was the CRQ implemented at the Scheduled date/time? Were there issues? Did the customer indicate that the CRQ met the requirements provided?) If there are issues, verify relationships created to INC record(s). 2.2. Ensure that all Tasks are marked Complete with Actual Start and End Dates/Times 2.3. Ensure the CRQ Actual Start and End Dates/Times and Scheduled Start and End Dates/Times are accurate based on the documentation in the Work Info 2.4. For Latent and Emergency CRQs ensure • the justification for the CRQ is clearly documented in the Notes • the INC or CRQ that prompted the CRQ is related • the Change Coordinator is specified 3. If all of the QA criteria have been met, progress the CRQ using Next Stage from the Process Flow Status Bar in Remedy. The status will be Completed – Final Review Completed. For a Project CRQ ensure that all sub-CRQs are minimally in a Completed status. (Completed Closed, Cancelled, or Pending status)
Page 19 of 23
CM1A Procedures v.2
10. Confirm CRQ Complete and Close (Box #9) Purpose:
To ensure that the Change is correctly closed with input from the Requestor.
Description:
The Install Results are reviewed to determine closure of the Change with respect to success. Success is determined by whether the change was implemented as per requirements and if there were resulting incidents.
Owner:
Change Coordinator
Possible Participants (Roles):
Possible Inputs: Possible Outputs:
Change Requestor Task Assignees Other Domain team members Non-domain team members Customers All Completed CRQs with status reason Final Review Completed.
• • • •
Closed CRQ Update Install Results Update Work Info Relate Remedy records (INC or WO)
1. Change Coordinator contacts the Requestor to determine if the CRQ met the Change requirements 1.1. Update Work Info if needed 2. Progress the Change using Next Stage from the Process Flow Status Bar in Remedy and provide the Status Reason indicating the success of the change when prompted: • Successful: The CRQ met the requirements and did not result in any incidents nor were there any issues during implementation. • Successful with issues: The CRQ was implemented, met the requirements, but there were issues during implementation or resulted in Incidents. • Unsuccessful: The CRQ was implemented, but did not meet the requirements specified by the Assignee (or customer), but the changes remain in production. • Backed Out: The CRQ was not implemented or had significant issues and was backed out. 3. If the status reason is not Successful, prepare to give an update at the next CAB meeting, for example: • Reason CRQ was not Successful • Incidents generated • Corrective Actions If the CRQ was a Standard Change, the CAB should evaluate if this change should no longer be a Standard at the DCAB.
Page 20 of 23
CM1A Procedures v.2
11. APPENDIX A – Prepare for CAB (for the DCAB Administrator role) The following documentation is an excerpt from the CAB Administrator-Manager Process Checklist. 1. Perform Quality Assurance (QA) review and ensure the CRQs are advanced from the following Remedy statuses to ensure they will be on the CAB agenda. Contact the Change Coordinator and cc: the Supervisor if the CRQ does not meet criteria specified below: a. Scheduled for Review (Approval to Release) i. Verify documentation has been entered including Summary, Risk Wizard is populated, Notes, Change Coordinator, Dates (Scheduled Start, Scheduled End), Release Readiness Checklist and Work Info entries for: Service Impact, Risk Assessment, Test Plan and Backout Plan. ii. Advance each CRQ that meets the QA criteria using NEXT STAGE to status Scheduled for Approval b. Completed (Status Reason = Final Review Required) i. Verify documentation has been entered for the CRQ. If the change has a Status Reason other than Successful, there must be a Work Info entry – Work Info Type Install Results with details and possible relationship to an INC. ii. Advance each CRQ that meets the QA criteria using NEXT STAGE to status Completed (Status Reason = Final Review Completed) iii. For Latent CRQs, verify documentation in the Classification, Work Info, Assignment, Relationship and Dates Tabs as per the Change Management Procedures 2. Create agenda for CAB meeting (using standard format) – save to SharePoint site a. Copy New Action Items from previous minutes to Previous Action Items section 3. Run Remedy CRQ report for your DCAB a. From the Remedy Report Console, select Custom Reports -> Change Management -> Domain CAB Reports -> Change Management Status Report and specify CAB Name and select options from menu b. Save to SharePoint site 4. Email DCAB Quorum with links for the following: a. DCAB agenda b. DCAB CRQ report c. ECAB Minutes d. ECAB Projects
Page 21 of 23
CM1A Procedures v.2
12. APPENDIX B – Post and Ongoing CAB Activities (for the DCAB
Administrator role) The following documentation is an excerpt from the CAB Administrator-Manager Process Checklist. A. Post-CAB Meeting (Close of Business day after the CAB meeting) 1. Finalize minutes a. Verify all CAB agenda notes for each section are complete and accurate 2. Post the minutes to SharePoint site 3. Distribute to all attendees (including guests)
B. Ongoing 1. QA reviews of CRQs – Review all statuses to ensure CRQs are progressing and email staff/supervisors to follow up: o Draft – CRQs should be in this state for more than 48 hours. If there are, send email asking Requester to either progress the CRQ to Request for Authorization or Cancel.
o Request For Auth – This CRQ requires supervisor approval to progress to the domain CAB for Authorization to Plan. o Request For Change – Ensure that the dates allow for (2) CAB reviews/approvals prior to Requested Start Date. These CRQs will need to be on the agenda under Changes requesting Authorization to Plan. o Planning In Progress – Check the dates and ensure that CRQs are progressing as needed to obtain Release Approval by the CABs in order to avoid an EMR change. o
Scheduled for Review – The DCAB Administrator must Quality Check the CRQ including the Release Readiness Checklist before approving and progressing the CRQ to Scheduled for Approval to obtain Release Approval from the CAB.
o Scheduled For Approval – Ensure that Approval to Release can be obtained prior to the Scheduled Start Date. These CRQs will need to be on the agenda under Changes Requesting Approval to Release. o Scheduled – If the Scheduled Start Date is in the past, investigate further to determine if this change was executed, backed out or postponed. This CRQ may need to be progressed to Implementation in Progress, Completed or Closed. o Implementation In Progress – These are the CRQs that are currently being released to production based on the Scheduled Start/End Date/Time.
Page 22 of 23
CM1A Procedures v.2 o Completed/Final Review Required – The DCAB Administrator must Quality Check the CRQ and approve this change for closure. This includes checking the Work Info Tab. o Completed/Final Review Completed – Ensure that the Change Coordinator progresses the CRQ to Closed status. *If there is no response from the CRQ owner, escalate to the Supervisor for resolution. 2. 3. 4. 5. 6.
Follow up on CAB action items and parking lot items to ensure resolution Provide First line support to staff as Change Management Subject Matter Expert (SME) Coach and educate staff on the Change Management process Perform QA of Templates and Create/Modify templates Suggest improvements to Change Management and Continual Service Improvement (CSI) team as needed
Page 23 of 23
Reference Number: 3119 Custodians of Information Standard Issue Date: 06/16/2009 Owner: Operations – Security Management Section
Revised Date: 04/04/2012
Distribution All employees
Ownership The Office of Technology Services/Security Management Section is responsible for ensuring this document is necessary, reflects actual practice, and supports organization policy. This document was last reviewed/updated in April, 2012.
Section 1 – Introduction This security Standard describes the standards for California Technology Agency's (Technology Agency) custodians of information. A custodian of information is an individual responsible for overseeing and/or implementing the necessary safeguards to protect information assets at the level classified by the owner of information. Technology Agency employees or contracted vendors are custodians of information. In the Office of Technology Services (OTech) managed services environment, customer information is classified as confidential. Refer to 3113 - Data Classification Standard for details. In accordance with State Administrative Manual (SAM) section 5320.3, state entities must be vigilant to protect personal, sensitive, or confidential information from inappropriate or unauthorized access, use or disclosure, regardless of media type. Whether a state department is the custodian or the owner of the information, employees must ensure the security and integrity of the information.
Section 2 – Standard Requirements The majority of state departments are still dependent upon paper and other media types, such as microfiche. In September 2006, the Department of Finance issued Protection of Information Assets, Management Memo 06-12, adding paper and other media types to the state security incident reporting criteria. Efforts to improve awareness in the office environment can help safeguard personal, sensitive, or confidential information, regardless of the media type. Part I – Responsibilities The responsibilities of a custodian of information (all media): 1. Ensure compliance with applicable laws, and state mandates and procedures affecting the information, which includes, but is not limited to, the Health Insurance Portability and Accountability Act (HIPAA), Federal Tax Information (FTI), and Payment Card Industry (PCI). 2. Comply with security policies and procedures established by the owner of the information and the Technology Agency Information Security Officer.
Page 1 of 3
Custodians of Information Standard
#3119
3. Advise OTech Security Management Section of vulnerabilities that may present a threat to the information and provide additional threat mitigation alternatives. 4. Notify OTech Security Management Section of any unusual, actual, or attempted access to information. 5. Technology Agency employees shall not access, alter, or destroy any customer information without prior written authorization from the owner. 6. Technology Agency employees shall not access information that is not specifically designated in their current job duties. 7. Technology Agency employees that have direct access to (or provide access to) personal, sensitive, or confidential information will access private information only when it is necessary in the course of their job duties. Part II – Directives Many probable threats exist in the current office environment including but not limited to the disclosure, altering, and loss of personal, sensitive, or confidential information. Thus, the following directives should be strictly adhered to by Technology Agency employees and contracted vendors. 1. Allocate time to ensure that information classified as confidential is locked in a secure location when unattended and at the end of the working day, thereby reducing the threat of a security incident. 2. Scan paper documents and file them electronically on a secured file system. 3. Use the secure recycling bins for confidential information when the document retention date has expired. Employees should familiarize themselves with the Department of General Services (DGS) Consolidated Retention Guide (DOC). 4. Employees using Technology Agency-owned portable computing devices such as laptops, personal digital assistants, external drives, and removable media should ensure the devices are secure when they are out of sight. Refer to 3106 - Portable Storage Device Security Standard and 3124 - Portable Computing Device Security Standard for details. 5. Keys to offices and file cabinets that contain confidential information must not be left unattended. 6. Custodians having access to personal, sensitive, or confidential information must maintain confidentiality.
Section 3 – Applicability and Exclusions A. This Standard applies to Technology Agency information assets and anyone accessing them. B. Direct any questions regarding the applicability of this Standard to the OTech Security Management Section for clarification. C. Exceptions to this Standard must be documented and will be considered on a case-by-case basis. Requests for an exception to this Standard must be submitted via the Security Policy/Standard Exception Request Form, TECH 358.
Section 4 – Auditing and Reporting A. Auditing may be performed on a periodic or random basis by the Security Management Section or its designees. In the event an audit determines this Standard is not being applied, notification will be sent to the appropriate person for remediation.
Page 2 of 3
Custodians of Information Standard
#3119
B. Any known violations of this Standard must be reported to the Technology Agency Chief Information Security Officer and the reporting employee’s immediate supervisor.
Section 5 – Authority/References State Administrative Manual (SAM) section 5320.3 California Office of Information Security Management Memo 06-12 DGS Consolidated Retention Guide (DOC) 3106 - Portable Storage Device Security Standard 3124 - Portable Computing Device Security Standard 3113 - Data Classification Standard Security Policy/Standard Exception Request Form, TECH 358
Page 3 of 3
Reference Number: 3113 Data Classification Standard Issue Date: 06/06/2007 Owner: Operations – Security Management Section
Revised Date: 04/04/2012
Distribution All employees
Ownership The Office of Technology Services/Security Management Section is responsible for ensuring this document is necessary, reflects actual practice, and supports organization policy. This document was last reviewed/updated in April, 2012.
Section 1 – Introduction Data classification standards and methods are adopted to protect the confidentiality, integrity, and availability of data. The California Technology Agency (Technology Agency) will adopt and abide by the following data classification standard requirements owned by the Department of General Services (DGS) as indicated in the State Administrative Manual (SAM) section 5320.5. IMPORTANT: System data in the hosted environment must be classified by the customer and disclosed to the Office of Technology Services (OTech) staff; specifically the Customer Representative and/or Account Manager. The owner of the file or database is also responsible for informing OTech staff of the classifications and sub-classifications that is contained therein. Hosted systems containing unclassified data will be classified with the most restrictive security measures by default.
Section 2 – Standard Requirements Part I - Data Classifications SAM section 5320.5 specifically states the following: “Subject to executive management review, the agency unit that is the designated owner of a record (paper or electronic, including automated files, or databases) is responsible for making the determination as to whether that record, file, or database should be classified as public, or confidential, and whether it contains personal, and/or sensitive data. The owner of the record, file, or data is responsible for defining special security precautions that must be followed to ensure the integrity, security, and appropriate level of confidentiality of the information. The state's records, automated files, and databases are essential public resources that must be given appropriate protection from unauthorized use, access, disclosure, modification, loss, or deletion. Each agency must classify each record, file, and database using the following classification structure: 1. Public Information - information maintained by state agencies that is not exempt from disclosure under the provisions of the California Public Records Act (Government Code sections 6250-6265) or other applicable state or federal laws.
Page 1 of 4
Data Classification Standard
#3113
2. Confidential Information - information maintained by state agencies that is exempt from disclosure under the provisions of the California Public Records Act (Government Code sections 6250-6265) or other applicable state or federal laws. Sensitive Information and Personal Information, as defined below, may occur in Public Information and/or Confidential Information. Records, files, and databases containing sensitive and/or personal information require special precautions to prevent inappropriate disclosure. When confidential, sensitive or personal information is contained in public records, procedures must be used to protect it from inappropriate disclosure. Such procedures include the removal, redaction or otherwise masking of the confidential, sensitive or personal portions of the information before a public record is released or disclosed. While the need for the agency to protect data from inappropriate disclosure is important, so is the need for the agency to take necessary action to preserve the integrity of the data. Agencies must develop and implement procedures for access, handling, and maintenance of personal and sensitive information. 1. Sensitive Information - information maintained by state agencies that requires special precautions to protect from unauthorized use, access, disclosure, modification, loss, or deletion. Sensitive information may be either public or confidential. It is information that requires a higher than normal assurance of accuracy and completeness. Thus the key factor for sensitive information is that of integrity. Typically, sensitive information includes records of agency financial transactions and regulatory actions. 2. Personal Information - information that identifies or describes an individual as defined in, but not limited by, the statutes listed below. This information must be protected from inappropriate access, use, or disclosure and must be made accessible to data subjects upon request. a. Notice-triggering personal information - specific items or personal information (name plus Social Security Number, driver's license/California identification card number, or financial account number) that may trigger a requirement to notify individuals if it is acquired by an unauthorized person. See Civil Code sections 1798.29 and 1798.3. b. Protected Health Information - individually identifiable information created, received, or maintained by such organizations as health care payers, health care providers, health plans, and contractors to these entities, in electronic or physical form. State laws require special precautions to protect from unauthorized use, access or disclosure. See Confidentiality of Medical Information Act, Civil Code section 56 et seq. and the Patients' Access to Health Records Act, Health and Safety Code sections 123100-123149.5. c. Electronic Health Information - individually identifiable health information transmitted by electronic media or maintained in electronic media. Federal regulations require state entities that are health plans, health care clearinghouses, or health care providers that conduct electronic transactions to ensure the privacy and security of electronic protected health information from unauthorized use, access, or disclosure. See Health Insurance Portability and Accountability Act, 45 C.F.R. parts 160 and 164. d. Personal Information for Research Purposes - personal information requested by researchers specifically for research purposes. Releases may only be made to the University of California or other non-profit educational institutions and in accordance with the provisions set forth in the law, including the prior review and approval by the Committee for the Protection of Human Subjects (CPHS) of the
Page 2 of 4
Data Classification Standard
#3113
California Health and Human Services Agency before such information is released. See Civil Code section 1798.24(t).” Part II – Information Categorization Listed below are additional categories that align with the above data classifications. Information Category
Reference Document(s)
Notice triggering Personal Identity Information (PII)
Civil Code sections 1798.29 and 1798.3
Protected Health Information (PHI)
Confidentiality of Medical Information Act, Civil Code section 56 et seq. and the Patients' Access to Health Records Act, Health and Safety Code sections 123100-123149.5
Electronic Patient Health Information (EPHI)
Health Insurance Portability and Accountability Act, 45 C.F.R. parts 160 and 164
Payment Card Information (PCI)*
Payment Card Industry (PCI) Security Standards Council in their Data Security Standard (PCIDSS)
Federal Tax Information (FTI)
Internal Revenue Service (IRS) Code, Section 6103 and is covered by the IRS Publication 1075, “Tax Information Security Guidelines for Federal, State and Local Agencies and Entities”
*Payment Card Information – financial information as defined by the Payment Card Industry (PCI) Security Standards Council in their Data Security Standard (PCIDSS). The most common example of PCI data requiring protection is the Primary Account Number (PAN), but additional items that must also be protected if stored with the PAN include Cardholder Name, Service Code, and Expiration Date. Customer (internal and external) information technology (IT) systems and environments must be technically architected in a PCI compliant manner.
Section 3 – Applicability and Exclusions A. This Standard applies to California Technology Agency IT resources and to anyone accessing these resources. Direct any questions regarding the applicability of this Standard to the OTech, Security Management Section for clarification. B. Exceptions to this Standard must be documented and will be considered on a case-by-case basis. Requests for an exception to this Standard must be submitted via the Security Policy/Standard Exception Request Form, TECH 358.
Section 4 – Auditing and Reporting A. Auditing may be performed on a periodic or random basis by the OTech, Security Management Section or its designees. In the event an audit determines this Standard is not being applied, notification will be sent to the appropriate person for remediation. B. Any known violations of this Standard must be reported to the Technology Agency Chief Information Security Officer and the reporting employee’s immediate supervisor.
Section 5 – Authority/References 3100 - Asset Protection Policy State Administrative Manual (SAM) section 5320.5
Page 3 of 4
Data Classification Standard
#3113
Government Code sections 6250-6265 Civil Code section 56 Civil Code section 1798.24(t) Civil Code sections 1798.29 and 1798.3 Health and Safety Code sections 123100-123149.5 Health Insurance Portability and Accountability Act, 45 C.F.R. parts 160 and 164 Committee for the Protection of Human Subjects (CPHS) California Health and Human Services Agency Payment Card Industry Data Security Standard (PCIDSS) United States of America Code – Title 26, Section 6103 Internal Revenue Service Publication 1075 Security Policy/Standard Exception Request Form, TECH 358
Page 4 of 4
Procedure
Data Storage Cleansing and Removal Procedure
Owner: Operations – Security Management Section
Number: 3125 Issue Date: 12/07/2007 Revised Date: 04/01/2012
Distribution All employees
Ownership The Security Management Section (SMS) is responsible for ensuring this document is necessary, reflects actual practice, and supports organization policy. This document was last reviewed/updated in April, 2012.
Section 1 – Introduction The purpose of this Procedure is to ensure that data storage components and media are properly cleansed before being replaced, reused, discarded and/or surveyed. The data storage components, devices and/or media in use at the California Technology Agency, must have data removed prior to the cleansing and removal process. The Office of Technology Services (OTech), SMS, in conjunction with the OTech Engineering Division has created this Procedure to ensure that data storage components and media are properly cleansed or removed.
Section 2 – Procedure Proper Methods of Clearing or Sanitizing Media A. Please follow the procedures below, written by the US Department of Defense, when removing or replacing data storage media: 1. Identify the data storage media to be replaced, reused, or discarded. 2. Using the Clearing and Sanitization Matrix defined in Table 1 below, select and perform the appropriate method to clear (i.e., to be reused) or sanitize (i.e., to be destroyed) the data storage media. 3. Staff performing these activities will be responsible for providing audit trail documentation should an audit occur. The Data Storage Component Clearing and Sanitization Form, TECH 366 was created to assist staff performing these activities in providing a paper trail should an audit occur. The use of this form is optional. 4. Replace, reuse, or destroy the data storage component.
Page 1 of 4
Data Storage Cleansing and Removal Procedure
#3125
Table 1 – US Department of Defense 5220.22-M Clearing and Sanitization Matrix
Media
Clear
Sanitize
Magnetic Tape Type I
a or b
a, b, or m
Type II
a or b
b or m
Type III
a or b
m
Bernoullis
a, b, or c
m
Floppies
a, b, or c
m
Non-Removable Rigid Disk
c
a or b & m
Removable Rigid Disk
a, b, or c
a or b & m
c
m
Magnetic Disk
Optical Disk Read Many, Write Many Read Only
m, n
Write Once, Read Many (Worm)
m, n
Memory Dynamic Random Access Memory (DRAM)
c or g
c, g, or m
Electronically Alterable PROM (EAPROM)
i
j or m
Electronically Erasable PROM (EEPROM)
i
h or m
Erasable Programmable (ROM (EPROM)
k
l, then c, or m
Flash EPROM (FEPROM)
i
c then i, or m
Programmable ROM (PROM)
c
m
Magnetic Bubble Memory
c
a, b, c, or m
Magnetic Core Memory
c
a, b, e, or m
Magnetic Plated Wire
c
c and f, or m
Magnetic Resistive Memory
c
m
Nonvolatile RAM (NOVRAM)
c or g
c, g, or m
Read Only Memory ROM
m
Static Random Access Memory (SRAM)
c or g
c and f, g, or m
g
q
Impact
g
p then g
Laser
g
o then g
Equipment Cahtode Ray Tube (CRT) Printers
Page 2 of 4
Data Storage Cleansing and Removal Procedure
#3125
Appropriate Removal Actions Defined The following list corresponds to Table 1 - US Department of Defense 5220.22-M Clearing and Sanitization Matrix: a. b. c. d.
e. f. g. h. i. j. k. l. m. n. o. p. q.
Degauss with a Type I degausser. Degauss with a Type II degausser. Overwrite all addressable locations with a single character. Overwrite all addressable locations with a character, its complement, then a random character and verify. THIS METHOD IS NOT APPROVED FOR SANITIZING MEDIA THAT CONTAINS TOP SECRET INFORMATION. Overwrite all addressable locations with a character, its complement, then a random character. Each overwrite must reside in memory for a period longer than the classified data resided. Remove all power to include battery power. Overwrite all locations with a random pattern, all locations with binary zeros, all locations with binary ones. Perform a full chip erase as per manufacturer's data sheets. Perform i above, then c above, a total of three times. Perform an ultraviolet erase according to manufacturer's recommendation. Perform k above, but increase time by a factor of three. Destroy - Disintegrate, incinerate, pulverize, shred, or melt. Destruction required only if classified information is contained. Run five pages of unclassified text (font test acceptable). Ribbons must be destroyed. Platens must be cleaned. Inspect and/or test screen surface for evidence of burned-in information. If present, the cathode ray tube must be destroyed.
B. Data Storage Media under Third Party Maintenance Agreement(s) Storage devices, under third party maintenance agreement(s), needing replacement or repair cannot be returned to the service provider or manufacturer. The replaced media must be destroyed by OTech staff onsite. Functioning devices requiring maintenance may not be shipped offsite for repair unless all system and user data has been overwritten with nonsensical data; otherwise, repairs must be performed onsite. Such maintenance agreements should be discussed with the service provider or manufacturer prior to contract completion. C. Third Party Contracts for Media Destruction When contracting with a private contractor to destroy data storage media containing confidential records please adhere to the State Administrative Manual, Section 1693 Destruction of Confidential Records, stated below: "1693 DESTRUCTION OF CONFIDENTIAL RECORDS (Revised 09/02) Agencies Must Send A State Employee To Witness Confidential Destruction When Using The Services Of Private Contractors. In Sacramento, State Destruction Center staff will be used to witness the destruction of confidential records. If an agency needs to destroy accountable forms, arrangements
Page 3 of 4
Data Storage Cleansing and Removal Procedure
#3125
must be made with the State Destruction Center to ensure witnessing by appropriate agency personnel."
Section 3 – Applicability and Exclusions A. This Procedure applies to all applicable California Technology Agency information technology (IT) resources and anyone accessing California Technology Agency IT systems. Direct any questions regarding the applicability of this Procedure to the OTech SMS for clarification. B. Exceptions to this Procedure must be documented and will be considered on a case-by-case basis. Requests for an exception to this Procedure must be submitted via the Security Policy/Standard Exception Request Form, TECH 358.
Section 4 – Auditing and Reporting A. Auditing may be performed on a periodic or random basis by the OTech SMS or its designees. In the event an audit determines this Procedure is not being applied, notification will be sent to the appropriate person for remediation. B. Any known violations of this Procedure must be reported to the California Technology Agency Chief Information Security Officer and the reporting employee’s immediate supervisor.
Section 5 – Authority/References State Administrative Manual, Section 1693 3400 - Acceptable Use Policy Security Policy/Standard Exception Request Form, TECH 358 Data Storage Component Clearing and Sanitization Form, TECH 366 US Department of Defense 5220.22-M Clearing and Sanitization Matrix
Page 4 of 4
Reference
Device Ports and Protocols Security Standard
Owner: Operations – Security Management Section
Number: 3130 Issue Date: 12/22/2008 Revised Date: 04/04/2012
Distribution All employees of the California Technology Agency (Technology Agency), Office of Technology Services (OTech)
Ownership The OTech/Security Management Section (SMS) is responsible for ensuring this document is necessary, reflects actual practice, and supports organization policy. This document was last reviewed/updated in April, 2012.
Section 1 – Introduction The Technology Agency, OTech, systems located in the managed services environment are maintained in a manner that follows security best practices. Access to these devices is controlled by a combination of authorization by the data owner and the OTech custodians responsible for the security and health of the device and operating system. This Standard is intended to describe: Roles and responsibilities of maintaining ports and protocols of information technology devices. Requirements regarding commonly used Transmission Control Protocol (TCP)/Internet Protocol (IP) and User Datagram Protocol (UDP) services. Port numbers given in this document refer to the default port numbers and are for reference only.
Section 2 – Standard Requirements Part I – Roles and Responsibilities and Port References A. Roles and responsibilities of system administrators, relevant to device ports and protocols include, but are not limited to: 1. Adherence to 3126 – Server Security Standard. 2. Adherence to 3302 – Security Update Management Standard. 3. Adherence to Office of Technology Services (OTech) change control processes and procedures upon requests to change port configurations. 4. Only OTech staff is permitted to implement and maintain device port and protocol configurations. 5. Device port and protocol configuration changes must be processed through the OTech SMS for approval prior to implementation. Reference Security Procedure 3121 – Firewall and Access List Request for details.
Page 1 of 4
Device Ports and Protocols Security Standard
#3130
6. Customer firewall configurations may never be replicated to a firewall in the managed services environment. Customer firewall configurations are permissible in the Tenant Managed Services (TMS) environments only. 7. Requests for device port configuration changes that may negatively impact the health or manageability of the device is not permitted. 8. Unused device ports must be disabled. B. Systems in the managed services environment must adhere to the reference table below:
DefaultPort
Service/Protocol
Conditions
21/tcp
FTP and Simple FTP
FTP is a clear-text protocol. FTP is acceptable, provided the originating source resides in the CSGNet/CGEN, and the data is neither confidential nor sensitive. VPN is required for FTP when the originating source resides in the public Internet. The underlying intent is to NOT open FTP on these web servers to the public Internet.
22/tcp
SSH, Secure FTP
Permitted. Used for secure logins, file transfers (scp, simple ftp) and port forwarding.
23/tcp
TELNET
Telnet is a clear-text protocol. Not permitted if the data is confidential or sensitive.
25/tcp
SMTP
Permitted to be open only on authorized mail servers functioning as mail gateways. Cannot be run along with other major services.
123/tcp, udp
NTP
Permitted to be open only on authorized NTP (Network Time Protocol) servers or devices.
80/tcp
HTTP
Not permitted from the public Internet to the intranet zone. Not permitted if the data is confidential or sensitive. Suggest using HTTPS instead.
443/tcp
HTTPS
Secure HTTP (SSL).
111/tcp
RPCBIND
Permitted internally.
512/tcp
REXEC
Never permitted. This is a clear-text protocol that allows authentication data to be intercepted.
3389/tcp
RDP
Allowed inbound from specific IP addresses or very small ranges (8 or fewer addresses) to specific IP addresses.
Page 2 of 4
Device Ports and Protocols Security Standard
#3130
1. The use of the protocol service known as Authentication and Key Agreement (AKA) is restricted regardless of the port number. 2. Requests for device port configurations must be submitted by the data owner with the approval of the data owner’s information security officer. Customer vendors are not permitted to request port configurations. 3. Requests for IP-to-IP protocol access are never permitted. 4. Requests for Remote Desktop Protocol (RDP) access to devices in the managed services environment are permitted from specific customer IP addresses or IP ranges less than eight 5. RDP access may not be permitted to vendor locations and to community purpose workstations. Part II – Simple Network Management Protocol Requirements and Reporting A. Simple Network Management Protocol (SNMP) Requirements Listed below are the acceptable use and configuration of SNMP: 1. SNMP must be disabled on devices, where it is not actively being used as described in 3126 – Server Security Standard. 2. Devices installed on the production network must use SNMP version 3. 3. Units/divisions supporting network devices using versions 1 or 2 must upgrade systems or obtain an approved exception from the OTech Information Security Office for those devices. Please refer to Section 3 – Applicability and Exclusions (below) for instructions on how to obtain an exception. 4. Devices and software purchased by the Technology Agency must support version 3. B. SNMP Reporting Procedure Discoveries of versions 1 or 2 found by the routine vulnerability scans will be considered high risk vulnerabilities. The SMS will submit a Help Desk ticket, which will be left open until either an exception is approved or the version is upgraded by the responsible unit/division. Part III – Network File System (NFS) Requirements A. NFS services are ONLY permitted within customer and OTech systems when the following conditions are met (any exceptions, please see section 3-C): 1. NFS v4 is used. 2. Encryption must be utilized for the purposes of mutual authentication (e.g. Kerberos authentication) on systems containing information that is classified as “notice triggering” or if the NFS server communicates with clients that are on separate Virtual Local Area Networks (VLANs). 3. Publicly accessible servers (e.g. web or web/application) may not access NFS mounts on back-end database servers.
Section 3 – Applicability and Exclusions A. This Standard does not apply to systems in the TMS environments. B. This Standard applies to applicable OTech devices and the staff supporting them. Exceptions to the upgrade requirement will only be granted if there are no alternative devices or software that supports SNMP version 3 or the purchaser agrees to disable SNMP until version 3 is available.
Page 3 of 4
Device Ports and Protocols Security Standard
#3130
C. Exceptions to this Standard must be documented and will be considered on a case-by-case basis. Requests for an exception to this Standard must be submitted via the Security Policy/Standard Exception Request Form, TECH 358. Please refer to 3502 – Information Security Exception Request for detailed information. Direct any questions regarding the applicability of this Standard to the SMS.
Section 4 – Auditing and Reporting A. Auditing may be performed on a periodic or random basis by the SMS or its designees. In the event an audit determines this Standard is not being applied, notification will be sent to the appropriate person for remediation. B. Any known violations of this Standard must be reported to the Technology Agency Chief Information Security Officer and the reporting employee’s immediate supervisor.
Section 5 – Authority/References 3100 – Asset Protection Policy 3121 – Firewall and Access List Request Procedure 3126 – Server Security Standard 3302 – Security Update Management Standard 3502 – Information Security Exception Request Procedure 3300 – Vulnerability Management Policy Introduction to Version 3 of the Internet-standard Network Management Framework Security Policy/Standard Exception Request Form, TECH 358
Page 4 of 4
FIPS PUB 199 _______________________________________________________________ FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION
Standards for Security Categorization of Federal Information and Information Systems
_______________________________________________________________
Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8900
February 2004
U.S. DEPARTMENT OF COMMERCE Donald L. Evans, Secretary TECHNOLOGY ADMINISTRATION Phillip J. Bond, Under Secretary for Technology NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY Arden L. Bement, Jr., Director
FIPS Publication 199
Standards for Security Categorization of Federal Information and Information Systems
________________________________________________________________________________________________
FOREWORD The Federal Information Processing Standards Publication Series of the National Institute of Standards and Technology (NIST) is the official series of publications relating to standards and guidelines adopted and promulgated under the provisions of Section 5131 of the Information Technology Management Reform Act of 1996 (Public Law 104-106) and the Federal Information Security Management Act of 2002 (Public Law 107-347). These mandates have given the Secretary of Commerce and NIST important responsibilities for improving the utilization and management of computer and related telecommunications systems in the federal government. The NIST, through its Information Technology Laboratory, provides leadership, technical guidance, and coordination of government efforts in the development of standards and guidelines in these areas. Comments concerning Federal Information Processing Standards Publications are welcomed and should be addressed to the Director, Information Technology Laboratory, National Institute of Standards and Technology, 100 Bureau Drive, Stop 8900, Gaithersburg, MD 20899-8900. -- SUSAN ZEVIN, ACTING DIRECTOR INFORMATION TECHNOLOGY LABORATORY
ii
FIPS Publication 199
Standards for Security Categorization of Federal Information and Information Systems
________________________________________________________________________________________________
AUTHORITY Federal Information Processing Standards Publications (FIPS PUBS) are issued by the National Institute of Standards and Technology (NIST) after approval by the Secretary of Commerce pursuant to Section 5131 of the Information Technology Management Reform Act of 1996 (Public Law 104106) and the Federal Information Security Management Act of 2002 (Public Law 107-347).
iii
FIPS Publication 199
Standards for Security Categorization of Federal Information and Information Systems
________________________________________________________________________________________________
TABLE OF CONTENTS SECTION 1
PURPOSE..................................................................................................... 1
SECTION 2
APPLICABILITY.............................................................................................. 1
SECTION 3
CATEGORIZATION OF INFORMATION AND INFORMATION SYSTEMS ................... 1
APPENDIX A
TERMS AND DEFINITIONS ............................................................................... 7
APPENDIX B
REFERENCES
............................................................................................... 9
iv
FIPS Publication 199
Standards for Security Categorization of Federal Information and Information Systems
________________________________________________________________________________________________
1
PURPOSE
The E-Government Act of 2002 (Public Law 107-347), passed by the one hundred and seventh Congress and signed into law by the President in December 2002, recognized the importance of information security to the economic and national security interests of the United States. Title III of the E-Government Act, entitled the Federal Information Security Management Act of 2002 (FISMA), tasked NIST with responsibilities for standards and guidelines, including the development of: •
Standards to be used by all federal agencies to categorize all information and information systems collected or maintained by or on behalf of each agency based on the objectives of providing appropriate levels of information security according to a range of risk levels;
•
Guidelines recommending the types of information and information systems to be included in each category; and
•
Minimum information security requirements (i.e., management, operational, and technical controls), for information and information systems in each such category.
FIPS Publication 199 addresses the first task cited—to develop standards for categorizing information and information systems. Security categorization standards for information and information systems provide a common framework and understanding for expressing security that, for the federal government, promotes: (i) effective management and oversight of information security programs, including the coordination of information security efforts throughout the civilian, national security, emergency preparedness, homeland security, and law enforcement communities; and (ii) consistent reporting to the Office of Management and Budget (OMB) and Congress on the adequacy and effectiveness of information security policies, procedures, and practices. Subsequent NIST standards and guidelines will address the second and third tasks cited.
2
APPLICABILITY
These standards shall apply to: (i) all information within the federal government other than that information that has been determined pursuant to Executive Order 12958, as amended by Executive Order 13292, or any predecessor order, or by the Atomic Energy Act of 1954, as amended, to require protection against unauthorized disclosure and is marked to indicate its classified status; and (ii) all federal information systems other than those information systems designated as national security systems as defined in 44 United States Code Section 3542(b)(2). Agency officials shall use the security categorizations described in FIPS Publication 199 whenever there is a federal requirement to provide such a categorization of information or information systems. Additional security designators may be developed and used at agency discretion. State, local, and tribal governments as well as private sector organizations comprising the critical infrastructure of the United States may consider the use of these standards as appropriate. These standards are effective upon approval by the Secretary of Commerce.
3
CATEGORIZATION OF INFORMATION AND INFORMATION SYSTEMS
This publication establishes security categories for both information 1 and information systems. The security categories are based on the potential impact on an organization should certain events occur which jeopardize the information and information systems needed by the organization to accomplish its assigned mission, protect its assets, fulfill its legal responsibilities, maintain its day-to-day functions, and protect individuals. Security categories are to be used in conjunction with vulnerability and threat information in assessing the risk to an organization. 1 Information is categorized according to its information type. An information type is a specific category of information (e.g., privacy, medical, proprietary, financial, investigative, contractor sensitive, security management) defined by an organization or, in some instances, by a specific law, Executive Order, directive, policy, or regulation.
1
FIPS Publication 199
Standards for Security Categorization of Federal Information and Information Systems
________________________________________________________________________________________________
Security Objectives The FISMA defines three security objectives for information and information systems: CONFIDENTIALITY
“Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information…” [44 U.S.C., Sec. 3542] A loss of confidentiality is the unauthorized disclosure of information. INTEGRITY
“Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity…” [44 U.S.C., Sec. 3542] A loss of integrity is the unauthorized modification or destruction of information. AVAILABILITY
“Ensuring timely and reliable access to and use of information…” [44 U.S.C., SEC. 3542] A loss of availability is the disruption of access to or use of information or an information system.
Potential Impact on Organizations and Individuals FIPS Publication 199 defines three levels of potential impact on organizations or individuals should there be a breach of security (i.e., a loss of confidentiality, integrity, or availability). The application of these definitions must take place within the context of each organization and the overall national interest. The potential impact is LOW if— − The loss of confidentiality, integrity, or availability could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. 2 AMPLIFICATION: A limited adverse effect means that, for example, the loss of confidentiality, integrity, or availability might: (i) cause a degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is noticeably reduced; (ii) result in minor damage to organizational assets; (iii) result in minor financial loss; or (iv) result in minor harm to individuals. The potential impact is MODERATE if— − The loss of confidentiality, integrity, or availability could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. AMPLIFICATION: A serious adverse effect means that, for example, the loss of confidentiality, integrity, or availability might: (i) cause a significant degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is significantly reduced; (ii) result in significant damage to organizational assets; (iii) result in significant financial loss; or (iv) result in significant harm to individuals that does not involve loss of life or serious life threatening injuries.
2
Adverse effects on individuals may include, but are not limited to, loss of the privacy to which individuals are entitled under law.
2
FIPS Publication 199
Standards for Security Categorization of Federal Information and Information Systems
________________________________________________________________________________________________
The potential impact is HIGH if— − The loss of confidentiality, integrity, or availability could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals. AMPLIFICATION: A severe or catastrophic adverse effect means that, for example, the loss of confidentiality, integrity, or availability might: (i) cause a severe degradation in or loss of mission capability to an extent and duration that the organization is not able to perform one or more of its primary functions; (ii) result in major damage to organizational assets; (iii) result in major financial loss; or (iv) result in severe or catastrophic harm to individuals involving loss of life or serious life threatening injuries.
Security Categorization Applied to Information Types The security category of an information type can be associated with both user information and system information 3 and can be applicable to information in either electronic or non-electronic form. It can also be used as input in considering the appropriate security category of an information system (see description of security categories for information systems below). Establishing an appropriate security category of an information type essentially requires determining the potential impact for each security objective associated with the particular information type. The generalized format for expressing the security category, SC, of an information type is: SC information type = {(confidentiality, impact), (integrity, impact), (availability, impact)}, where the acceptable values for potential impact are LOW, MODERATE, HIGH, or NOT APPLICABLE. 4 EXAMPLE 1:
An organization managing public information on its web server determines that there is no potential impact from a loss of confidentiality (i.e., confidentiality requirements are not applicable), a moderate potential impact from a loss of integrity, and a moderate potential impact from a loss of availability. The resulting security category, SC, of this information type is expressed as: SC public information = {(confidentiality, NA), (integrity, MODERATE), (availability, MODERATE)}. EXAMPLE 2:
A law enforcement organization managing extremely sensitive investigative information determines that the potential impact from a loss of confidentiality is high, the potential impact from a loss of integrity is moderate, and the potential impact from a loss of availability is moderate. The resulting security category, SC, of this information type is expressed as: SC investigative information = {(confidentiality, HIGH), (integrity, MODERATE), (availability, MODERATE)}.
EXAMPLE 3: A financial organization managing routine administrative information (not privacy-related information) determines that the potential impact from a loss of confidentiality is low, the potential impact from a loss of integrity is low, and the potential impact from a loss of availability is low. The resulting security category, SC, of this information type is expressed as:
SC administrative information = {(confidentiality, LOW), (integrity, LOW), (availability, LOW)}.
3
System information (e.g., network routing tables, password files, and cryptographic key management information) must be protected at a level commensurate with the most critical or sensitive user information being processed, stored, or transmitted by the information system to ensure confidentiality, integrity, and availability. 4
The potential impact value of not applicable only applies to the security objective of confidentiality.
3
FIPS Publication 199
Standards for Security Categorization of Federal Information and Information Systems
________________________________________________________________________________________________
Security Categorization Applied to Information Systems Determining the security category of an information system requires slightly more analysis and must consider the security categories of all information types resident on the information system. For an information system, the potential impact values assigned to the respective security objectives (confidentiality, integrity, availability) shall be the highest values (i.e., high water mark) from among those security categories that have been determined for each type of information resident on the information system. 5 The generalized format for expressing the security category, SC, of an information system is: SC information system = {(confidentiality, impact), (integrity, impact), (availability, impact)}, where the acceptable values for potential impact are LOW, MODERATE, or HIGH.
Note that the value of not applicable cannot be assigned to any security objective in the context of establishing a security category for an information system. This is in recognition that there is a low minimum potential impact (i.e., low water mark) on the loss of confidentiality, integrity, and availability for an information system due to the fundamental requirement to protect the system-level processing functions and information critical to the operation of the information system. EXAMPLE 4:
An information system used for large acquisitions in a contracting organization contains both sensitive, pre-solicitation phase contract information and routine administrative information. The management within the contracting organization determines that: (i) for the sensitive contract information, the potential impact from a loss of confidentiality is moderate, the potential impact from a loss of integrity is moderate, and the potential impact from a loss of availability is low; and (ii) for the routine administrative information (non-privacy-related information), the potential impact from a loss of confidentiality is low, the potential impact from a loss of integrity is low, and the potential impact from a loss of availability is low. The resulting security categories, SC, of these information types are expressed as: SC contract information = {(confidentiality, MODERATE), (integrity, MODERATE), (availability, LOW)},
and SC administrative information = {(confidentiality, LOW), (integrity, LOW), (availability, LOW)}.
The resulting security category of the information system is expressed as: SC acquisition system = {(confidentiality, MODERATE), (integrity, MODERATE), (availability, LOW)},
representing the high water mark or maximum potential impact values for each security objective from the information types resident on the acquisition system.
5
It is recognized that information systems are composed of both programs and information. Programs in execution within an information system (i.e., system processes) facilitate the processing, storage, and transmission of information and are necessary for the organization to conduct its essential mission-related functions and operations. These system processing functions also require protection and could be subject to security categorization as well. However, in the interest of simplification, it is assumed that the security categorization of all information types associated with the information system provide an appropriate worst case potential impact for the overall information system—thereby obviating the need to consider the system processes in the security categorization of the information system.
4
FIPS Publication 199
Standards for Security Categorization of Federal Information and Information Systems
________________________________________________________________________________________________ EXAMPLE 5:
A power plant contains a SCADA (supervisory control and data acquisition) system controlling the distribution of electric power for a large military installation. The SCADA system contains both real-time sensor data and routine administrative information. The management at the power plant determines that: (i) for the sensor data being acquired by the SCADA system, there is no potential impact from a loss of confidentiality, a high potential impact from a loss of integrity, and a high potential impact from a loss of availability; and (ii) for the administrative information being processed by the system, there is a low potential impact from a loss of confidentiality, a low potential impact from a loss of integrity, and a low potential impact from a loss of availability. The resulting security categories, SC, of these information types are expressed as: SC sensor data = {(confidentiality, NA), (integrity, HIGH), (availability, HIGH)},
and SC administrative information = {(confidentiality, LOW), (integrity, LOW), (availability, LOW)}.
The resulting security category of the information system is initially expressed as: SC SCADA system = {(confidentiality, LOW), (integrity, HIGH), (availability, HIGH)},
representing the high water mark or maximum potential impact values for each security objective from the information types resident on the SCADA system. The management at the power plant chooses to increase the potential impact from a loss of confidentiality from low to moderate reflecting a more realistic view of the potential impact on the information system should there be a security breach due to the unauthorized disclosure of system-level information or processing functions. The final security category of the information system is expressed as: SC SCADA system = {(confidentiality, MODERATE), (integrity, HIGH), (availability, HIGH)}.
5
FIPS Publication 199
Standards for Security Categorization of Federal Information and Information Systems
________________________________________________________________________________________________
Table 1 summarizes the potential impact definitions for each security objective—confidentiality, integrity, and availability. POTENTIAL IMPACT Security Objective
Confidentiality Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.
LOW
MODERATE
HIGH
The unauthorized disclosure of information could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals.
The unauthorized disclosure of information could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals.
The unauthorized disclosure of information could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.
The unauthorized modification or destruction of information could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals.
The unauthorized modification or destruction of information could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals.
The unauthorized modification or destruction of information could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.
The disruption of access to or use of information or an information system could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals.
The disruption of access to or use of information or an information system could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals.
The disruption of access to or use of information or an information system could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.
[44 U.S.C., SEC. 3542]
Integrity Guarding against improper information modification or destruction, and includes ensuring information nonrepudiation and authenticity. [44 U.S.C., SEC. 3542]
Availability Ensuring timely and reliable access to and use of information. [44 U.S.C., SEC. 3542]
TABLE 1: POTENTIAL IMPACT DEFINITIONS FOR SECURITY OBJECTIVES
6
FIPS Publication 199
Standards for Security Categorization of Federal Information and Information Systems
________________________________________________________________________________________________
APPENDIX A
TERMS AND DEFINITIONS
AVAILABILITY: Ensuring timely and reliable access to and use of information. [44 U.S.C., SEC. 3542] CONFIDENTIALITY: Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information. [44 U.S.C., SEC. 3542] EXECUTIVE AGENCY: An executive department specified in 5 U.S.C., SEC. 101; a military department specified in 5 U.S.C., SEC. 102; an independent establishment as defined in 5 U.S.C., SEC. 104(1); and a wholly owned Government corporation fully subject to the provisions of 31 U.S.C., CHAPTER 91. [41 U.S.C., SEC. 403] FEDERAL INFORMATION SYSTEM: An information system used or operated by an executive agency, by a contractor of an executive agency, or by another organization on behalf of an executive agency. [40 U.S.C., SEC. 11331] INFORMATION: An instance of an information type. INFORMATION RESOURCES: Information and related resources, such as personnel, equipment, funds, and information technology. [44 U.S.C., SEC. 3502] INFORMATION SECURITY: The protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide confidentiality, integrity, and availability. [44 U.S.C., SEC. 3542] INFORMATION SYSTEM: A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. [44 U.S.C., SEC. 3502] INFORMATION TECHNOLOGY: Any equipment or interconnected system or subsystem of equipment that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the executive agency. For purposes of the preceding sentence, equipment is used by an executive agency if the equipment is used by the executive agency directly or is used by a contractor under a contract with the executive agency which: (i) requires the use of such equipment; or (ii) requires the use, to a significant extent, of such equipment in the performance of a service or the furnishing of a product. The term information technology includes computers, ancillary equipment, software, firmware and similar procedures, services (including support services), and related resources. [40 U.S.C., SEC. 1401] INFORMATION TYPE: A specific category of information (e.g., privacy, medical, proprietary, financial, investigative, contractor sensitive, security management), defined by an organization, or in some instances, by a specific law, Executive Order, directive, policy, or regulation. INTEGRITY: Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity. [44 U.S.C., SEC. 3542] NATIONAL SECURITY SYSTEM: Any information system (including any telecommunications system) used or operated by an agency or by a contractor of an agency, or other organization on behalf of an agency— (i) the function, operation, or use of which involves intelligence activities; involves cryptologic activities related to national security; involves command and control of military forces; involves equipment that is an integral part of a weapon or weapons system; or is critical to the direct fulfillment of military or intelligence missions (excluding a system that is to be used for routine administrative and business applications, for example, payroll, finance, logistics, and personnel management applications); or, (ii) is protected at all times by procedures established for information that have been specifically authorized under criteria established by an Executive Order or an Act of Congress to be kept classified in the interest of national defense or foreign policy. [44 U.S.C., SEC. 3542]
7
FIPS Publication 199
Standards for Security Categorization of Federal Information and Information Systems
________________________________________________________________________________________________
SECURITY CATEGORY: The characterization of information or an information system based on an assessment of the potential impact that a loss of confidentiality, integrity, or availability of such information or information system would have on organizational operations, organizational assets, or individuals. SECURITY CONTROLS: The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information. SECURITY OBJECTIVE: Confidentiality, integrity, or availability.
8
FIPS Publication 199
Standards for Security Categorization of Federal Information and Information Systems
________________________________________________________________________________________________
APPENDIX B
REFERENCES
[1]
Privacy Act of 1974 (Public Law 93-579), September 1975.
[2]
Paperwork Reduction Act of 1995 (Public Law 104-13), May 1995.
[3]
OMB Circular A-130, Transmittal Memorandum #4, Management of Federal Information Resources, November 2000.
[4]
Information Technology Management Reform Act of 1996 (Public Law 104-106), August 1996.
[5]
Federal Information Security Management Act of 2002 (Public Law 107-347), December 2002.
9
FY 2012-2013
Department of Motor Vehicles
Strategic Plan
nd leader in p u sted b l i c tru
Cali for ni
recognize da
r se
aD
:A V M
ūū ūū ūū ūū
vic
e
Mission To serve the public by providing quality licensing and motor vehicle-related services.
contents from the director. . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
who we are
Our Mission and Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
Our Core Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
Our Core Functions . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. . 4 Our Support Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
goals , strategies, and performance measures
Service . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. . 6 Workforce . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .
7
Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
Consumer Protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . methodology . . contact us. .
10
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1
Service Strategy Leverage available resources to achieve customer success at their initial point of contact with DMV.
2
from the director I am pleased and excited to present DMV’s 2012 - 2013 Strategic Plan. Over the years, in our pursuit of service excellence, we have put into place major enhancements to the services and products we provide to customers and employees. This is due in part to our strategic planning process and the framework we use to advance our Mission, Vision, and Goals. Yet, in today’s environment, we are challenged to be even more precise in our decision making as we go forward. That is why we have developed a bold new Service Strategy Statement:
Leverage available resources to achieve customer success at their initial point of contact with DMV.
This strategy affirms our commitment to maximizing the new capabilities provided by our technology and workforce investments and applying them to how we serve customers. It also places heightened emphasis on customer success. No matter how a customer chooses to do business with us, we will strive to provide a service experience that is complete, consistent, and easy to understand. The formula for a “once-and-done” service experience involves a few elements. We must provide clear and consistent information to our customers so they understand what is required of them to be successful when doing business with the DMV. We must also enhance the usability of our service options, particularly our self-service channels, to allow customers to complete their business on their first try. I realize that for many of our employees this concept of “customer success” is not a new idea. Every day, their work is based on meeting customer needs on their first field office visit, phone call to DMV, or other contact. I applaud their efforts to provide the best quality service to the people of California. It is an exciting time at DMV and with this clarity in how we will focus our service efforts, we will be better able to deliver on the rest of our plan.
George Valverde, Director California Department of Motor Vehicles
3
who we are Our Mission To serve the public by providing quality licensing and motor vehicle-related services. Our Vision California DMV: A recognized and trusted leader in public service. Our Core Values • Honesty and integrity • Commitment to serve the public • Respect and consideration for each other, our customers, and the environment • Accuracy and quality in all our products and services
Our Service Strategy Leverage available resources to achieve customer success at their initial point of contact with DMV.
Customer Success Our approach when serving our customers is to make each interaction with DMV consistent, complete, and easy to understand. We will focus on customer success by: • Making sure our customers are prepared to do business with DMV: We educate customers on which service channels they may use and provide them with clear instructions on what is required to successfully complete their DMV business. • Providing service that is consistent and complete: We believe that the service and information provided should be consistent across our service options. We take the time to completely and accurately process each transaction.
Initial Point of Contact We offer customers several options for conducting business with DMV. Regardless of which service channel they choose, we endeavor to successfully complete our customers’ business on their first attempt. In order to achieve this outcome, we will place a priority on directing eligible customers to self-service options so that those with more complex transactions may experience customer success through our fullservice options. This Service Strategy also holds true for how we will serve our internal customers.
4
Our Core Functions
Our Support Functions
Driver License and Identification Card Program
Revenue Collection and Distribution
We test and issue licenses to qualified drivers, provide identification services to the public, and verify the identity of all licensed drivers and identification card holders.
Through traditional agency accounting activities, this function collects and tracks nearly $7 billion in revenue each year. These funds are then distributed to:
Vehicle Titling and Registration Program
• local governments and environmental agencies, • state agencies and departments including California Highway Patrol, Caltrans, and DMV,
We issue titles and register all automobiles, motorcycles, trailers, and vessels, as well as commercial vehicles used for both interstate and intrastate commerce. We also issue disabled person placards and personalized license plates.
• California’s General Fund. Human Resources This function is responsible for the administration, coordination, and implementation of activities related to the recruitment, hiring, development, and retention of employees.
Driver Safety Program We promote traffic safety by monitoring the driving performance of licensed drivers. Furthermore, we evaluate high-risk drivers for driving competency and take corrective actions against the driving privilege of drivers who demonstrate safety risks.
Enforcement Services This function conducts auditing, monitoring, inspecting, and investigative services on the internal and external entities related to our core programs.
Licensing of the Motor Vehicle Industry We provide consumer protection through the licensing and regulation of occupations and businesses related to the manufacture, transport, sale, and disposal of vehicles, including: vehicle manufacturers, dealers, registration services, salespersons, transporters, and dismantlers. In addition, we regulate all occupations and businesses related to driving and traffic schools.
Information Services This function includes all services associated with fulfilling requests for DMV information related to vehicles, persons, or business entities.
Information Technology (IT) Services The IT function provides programming, installation, and maintenance for DMV’s complex and unique IT systems. This function enables us to conduct our internal operations and deliver services.
Facilities Operation This function manages the DMV’s facilities statewide including: delegated leasing, energy conservation, seismic safety in buildings, access compliance, emergency response, and disaster recovery.
5
service
Enhance Services to our Internal and External Customers One of DMV’s Core Values is a commitment to serve the public. We also offer quality products and efficient services to meet their evolving needs. We actively seek our customers’ input and listen to their concerns and suggestions. Only by thoroughly understanding our customers, can we deliver on this pledge. This also holds true for the service we provide within our organization. Whether delivering services to internal or external customers, we continue to focus on building new tools and capabilities, making our processes easier, and directly asking our customers how we can best serve them. Our aim is to set the trend in service innovation for everyone we serve. Strategies • Research and assess the diverse needs of our customers. • Enhance and promote effective organizational communication. • Enhance and promote effective external customer communication. • Align DMV products, services, and resources with current and evolving customer needs.
Customer Service Excellent Poor
Performance Measures • Maintain the percentage of surveyed field office customers who rate their satisfaction as “satisfied” or better. • Increase the percentage of customers who use alternative service channels for vehicle registration renewal transactions. • Increase the percentage of customers who use alternative service channels for driver license renewal transactions. • Increase the percentage of customers that had an appointment at the time of their field office visit. • Increase the percentage of surveyed employees that answered “agree” or “strongly agree” to the following statements: –– “DMV provides quality service to the public.” –– “DMV employees provide quality service to each other.”
6
workforce
Strengthen and Support the Professionalism and Skill of our Workforce Strategies • Improve methods that foster collaborative and open communication among the workforce.
Understanding that “employees make the difference,” DMV is committed to further developing the professionalism and skill of our workforce. In order to sustain this goal, we pursue employee-focused initiatives that enhance both individual and organizational capabilities. We invest in our employees by providing them with the training, tools, and resources necessary to effectively serve our customers.
• Research and assess the diverse needs of our workforce. • Enhance our workforce environment. • Enhance our workforce capabilities to meet current and evolving business needs and demographics.
Additionally, we understand that empowered employees are more productive, more likely to offer innovative ideas to enhance their work, and take an active role in resolving problems. Therefore, we are fostering a culture that supports employee empowerment by giving employees flexibility and responsibility based upon their individual skills and capabilities.
• Create an infrastructure to support an effective workforce. • Modernize our recruitment and selection processes to maximize the effectiveness of our workforce. Performance Measures • Increase the percentage of surveyed employees that answered “agree” or “strongly agree” to the following statements: –– “Considering everything, I am satisfied working at DMV.” –– “I understand how my work contributes to the overall success of DMV.” –– “The training I have received for my current position has adequately prepared me for the work I do.” –– “I have the tools and equipment necessary to do my job.” –– “I am informed about current events, major projects, and critical issues facing DMV.” • Increase the percentage of DMV employees receiving their annual Individual Development Plan (IDP).
7
safety
Enhance Traffic Safety Through Internal Programs and Partnerships At DMV, we rely on partnerships with other safetyrelated government agencies to make our roadways safer. Nowhere is this more apparent than through our active participation in California’s Strategic Highway Safety Plan where DMV takes the lead on implementing 34 specific safety plans in various traffic safety challenge areas. These areas include reducing impaired driving, ensuring driver competency, and targeting crashes involving younger and older drivers. Strategies • Expand traffic safety related projects and programs. • Ensure drivers are qualified and competent to use the roadways. • Educate the public to promote traffic safety through proven methods and innovative approaches. • Evaluate and provide evidence-based information on the effectiveness of traffic safety related actions to stakeholders. • Improve the quality, completeness, timeliness, and uniformity of safety data and the sharing among federal, state, and local agencies and stakeholders. • Plan for and assess the safety implications of innovative modes of transportation.
8
Performance Measures • Reduce the number of fatalities per 100 million vehicle miles traveled. • Increase the percentage of eligible DUI convicted offenders within the four pilot counties (Los Angeles, Sacramento, Alameda, and Tulare) who install an Ignition Interlock Device (IID) on all vehicles they own or operate.
security
Strengthen Validity, Security, and Protection of Personal Information Performance Measures • Reduce the number of impacted individuals from Personal Identifiable Information incidents.
Every day, thousands of customers provide us with detailed information about themselves in order to register a vehicle, receive a driver license, or complete other DMV transactions. We earn the public’s trust through diligent safeguarding of the personal information we hold and employing proven fraud prevention methods.
• Increase the percentage of notices of a privacy incident sent within 15 calendar days.
We also understand that a California driver license or identification card is considered the de facto form of identification (ID) with banks, law enforcement, and businesses that require ID of their customers. It is because of this that we continue to strive for one license–one record–one identity. Strategies • Promote information security and privacy awareness. • Ensure accurate submission and timely processing of departmental actions. • Ensure consistent enforcement of DMV information security policies. • Identify and integrate best practices to mitigate fraud and protect personal information under DMV authority. • Establish accurate and secure identity management to facilitate authentication and authorization. • Strengthen and enhance the processes used to release or exchange DMV information.
9
protection
Enhance Consumer Protection We want consumers to feel confident when patronizing vehicle-related businesses. As a regulator and licensor of these businesses, DMV protects the public when they purchase a vehicle from a dealership, send a child to driving school, or attend a traffic violator school. We investigate consumer complaints and, if necessary, take action against these types of businesses. We also protect against identity theft, financial fraud, and document counterfeiting. Strategies • Enhance inspection, investigation, and review processes. • Develop new and improved trend analysis and enforcement tactics. • Enhance case management and resolution processes. • Identify and integrate best practices that impact consumer protection as they relate to licensing, motor vehicle-related services, and enforcement practices. • Promote public awareness of rights, responsibilities, and consumer protection services. • Improve visibility and strengthen communication and partnerships with licensees and other stakeholders.
10
Performance Measures • Increase the percentage of post-licensing dealer inspections that had no violation. • Increase the percentage of actions taken as a result of investigations of unlicensed activities.
methodology Strategic planning, performance measurement, and the ongoing monitoring and tracking of data are integrated systems and processes that make up the framework for Performance Management here at DMV. The key elements function as follows:
Assessment of Progress Each quarter, data and trends are reviewed by the Executive Team. Each review provides the opportunity to consider changes, adjustments, or corrections to any element of our strategic direction.
Environmental Assessment
Reporting Every quarter, organizational performance measures and accomplishments resulting from major projects and activities, are shared department-wide.
The Performance Management process is initiated annually through an assessment of our environment. We use the results to identify our strategic issues and opportunities.
Performance Management Model
Strategic Planning The Executive Team validates or revises the Mission, Vision, Core Values, Goals, Strategies, and Performance Measures. Collectively, these elements represent our strategic direction. Once adopted, these major elements will guide what we will focus on for the next 12 to 18 months.
Environmental Assessment
Analyze and Adjust
Organizational Performance Measures We track performance measures tied directly to the department’s Goals and Strategies. They are used to gauge progress toward Goal achievement and intended results. At the program level, performance measures are also established and maintained. Measures at this level are used to determine how well the division is fulfilling its core functions. Additionally, program level measure results are used to explain changes in our organizational measure data.
Results
Strategic Planning
Performance Measures
11
contact us California Department of Motor Vehicles Office of Strategic Planning and Organizational Development 2415 First Avenue, MS F500 Sacramento, CA 95818
Stephanie Dougherty Chief of Strategic Planning and Organizational Development
[email protected]
This plan is available to employees on the DMV intranet and to the public on the internet at: www.dmv.ca.gov
12
Vision Califonia DMV: A recognized and trusted leader in public service.
Edmund G. Brown Jr., Governor
State of California Brian P. Kelly, Acting Secretary
Business,Transportation and Housing Agency George Valverde, Director
California Department of Motor Vehicles
Message from the Director ...................................................................................................... 2 DMV IT — Who We Are Our Mission ........................................................................................................................ 3 Our Vision ........................................................................................................................... 3 Our Core Values ................................................................................................................ 3 Our Strategic Imperative ..................................................................................................... 3 The DMV IT Workforce Core IT Functions ............................................................................................................... 4 Other Divisions ................................................................................................................... 4 Strategic Alignments The DMV Strategic Business Plan………………………………………………………………...5 The California IT Strategic Plan……………………………………………………………………6 The Future DMV — Strategic Goals and Strategies Innovation Bound by Efficiency ........................................................................................... 7 Attract and Retain a Skilled IT Workforce ............................................................................ 8 Analytics Drive Decision Making ......................................................................................... 9 Protect Data and Information Assets ..................................................................................10 Maturity through Standards ................................................................................................11 Improve Collaboration and Communication........................................................................12 The Methodology IT Strategic Planning ..........................................................................................................13 The Strategic Framework Governance .......................................................................................................................14 Enterprise Architecture ......................................................................................................14 Enterprise IT Standards .....................................................................................................14 Project Management ..........................................................................................................14 Success Over Time Implications to Address ......................................................................................................15 Conclusion .........................................................................................................................15 Contact Us .........................................................................................................................16
O
ver the past decade, the Department of Motor Vehicles (DMV) transformed the delivery of services to California’s citizens through diligent strategic planning, governance practices, and through the use of Information Technology (IT) tools, applications, and processes. We have come a long way, and we are committed to sustaining the excellence set in motion. It is with great pleasure that I present the DMV’s Information Technology Strategic Plan (ITSP) for 2012 – 2016. This five-year plan is the product of collaboration with IT and the Office of Strategic Planning and Organizational Development (OSPOD) executive team members. Working together, this team of dedicated leaders created an overarching IT strategic framework which supports the DMV’s new Service Strategy statement : “Leverage available resources to achieve customer success at their initial point of contact with DMV.”
This plan provides an enterprise approach to address current and future challenges. Through implementation of the plan, we will ensure sustained network and organizational readiness. We have tied our IT investments to business needs, providing additional efficient and secure services to our customers. DMV has leveraged technology in a manner that enables our customers to achieve success at their initial point of contact with the DMV. We have faced a number of challenges over the past several years and we will continue to face hurdles in the foreseeable future. However, if past performance is any indicator of success, I am confident that through the forward-thinking efforts of our dedicated, hardworking, and resourceful “DMV Team,” we will continue to sustain our vision of the California Department of Motor Vehicles as a recognized and trusted leader in public service. I would like to take this opportunity to thank our IT and Business Team for their hard work, commitment, and leadership, and all of the dedicated DMV employees who work hard to make our mission, vision, and goals a reality. I look forward to our future transformation and the progress we can attain together.
Sincerely,
George Valverde Director California Department of Motor Vehicles
Our Mission
Our Core Values
To maximize the value of information technology to our customers through innovation and empowerment.
Honesty and integrity Commitment to serve the public Respect and consideration for each other, our customers, and the environment
Our Vision To be recognized as the preeminent government information technology solutions provider.
Accuracy and quality in all our products and services
Strategic Imperative Using industry best practices, DMV IT provides innovative enterprise IT products and services, empowering customers and employees to gain efficiencies.
“In everything the ends well defined are the secret of durable success.” - Victor Cousin
CORE IT FUNCTIONS Approximately 600 [1] employees work in IT areas throughout the DMV. Business programs throughout the organization utilize these personnel for day-to-day IT maintenance and support as well as on a variety of IT projects. Under the guidance and leadership of the DMV Chief Information Officer and executive team members, the DMV IT workforce is responsible for implementing the electronic and information technology strategies outlined in the Department’s IT Strategic Plan. The DMV IT workforce provides quality service enabling the DMV to conduct day-to-day operations and execute service delivery to customers utilizing innovative and efficient information technologies. These technologies provide the flexibility to efficiently adapt to changing governmental mandates and business requirements and meet the evolving demands of California’s citizens. Information Technology staff work in the following areas.
Information Systems Division (ISD) staff provides department-wide support by: Designing, programming, implementing, and evaluating new systems or modifying existing systems. Providing mainframe, server, and database administration services for DMV programs, business partners, and customers. Coordinating operational and planning issues with the California Technology Agency (Technology Agency). Establishing enterprise IT policies and architecture for the Department’s IT program and enforcing IT standards. Providing web development services for internal program partners. Receiving, verifying, and configuring hardware and software for the Department. Providing customer Help Desk support for all data network and IT infrastructure problems/issues. Acting as principal advisor to the Directorate, the Business, Transportation and Housing Agency, California Technology Agency, and the Governor’s Office on matters related to the DMV’s IT programs.
OTHER DIVISIONS Other divisions within DMV utilize numerous IT personnel within their program areas. Many of these personnel have IT and non-IT related responsibilities. These include: Providing first-level Help Desk support, troubleshooting hardware and software problems/issues. Maintaining program and workgroup applications (web pages, data repository, reporting applications, etc.) Developing ISD Service Requests and related business rule development for program-specific applications. Sponsoring, managing, and developing IT-related programs and initiatives.
[1]
The DMV Budget Office, Fiscal Year 2011-12
THE DMV BUSINESS STRATEGIC PLAN The DMV has developed five organizational business goals and a new Service Strategy for 2012 to advance the Department’s mission and vision. The 2012 - 2016 IT Strategic Plan introduces six strategic IT goals that align with and support the business goals and service strategy, move the Department forward in achieving our mission and vision, and facilitate a “once and done” service environment. Many of the IT goals directly align with the business goals. The Department’s “DMV Now” mobile application exemplifies how the IT goal “Innovation Bound by Efficiency” directly supports the business goal of “Enhanced Services to our Internal and External Customers.” Other IT goals have an indirect alignment to the business goals. The IT goal “Attract and Retain a Skilled IT Workforce” while not directly correlated, may influence the business goal of “Enhanced Services to Our Internal and External Customers.” A skilled IT workforce may lead to more efficient and effective workflows or automated processes, which would result in improved DMV services.
DMV IT STRATEGIC GOALS DMV STRATEGIC BUSINESS GOALS
THE CALIFORNIA IT STRATEGIC PLAN The Department of Motor Vehicles is a recognized leader in leveraging IT for transformative change. We have changed the way we conduct business and are providing greater efficiencies to our workforce and the citizens of California. The DMV IT goals identified below support and align with those of the State. Many have a direct alignment to State IT goals. For example, both DMV and State IT goals focus on creating a skilled and capable IT workforce. In comparison, the DMV IT goal “Protecting Data and Information Assets” has an indirect relationship to the State IT goal to provide an “Accessible and Mobile Government.” Efforts to increase citizen access to government services would include efforts to ensure information is protected and secure, but there is not a direct relationship between the two goals. We will routinely evaluate our progress to assure continuing alignment with State IT goals and sustain the standard of excellence that we have established thus far.
DMV IT STRATEGIC GOALS CA IT STRATEGIC BUSINESS GOALS
1. INNOVATION BOUND BY EFFICIENCY In the last decade, DMV has made efforts to improve its efficiency and provide better service in field offices and elsewhere, in order to potentially reduce the number of customers that visit field offices.” [3] DMV IT is committed to serving our internal and external customers. We are proactive in identifying and implementing IT solutions that enable DMV to enhance business processes and provide greater customer service efficiencies. Mindful of the economic climate, DMV IT will expand and make the most efficient use of our resources. Remaining focused, we continue modernization of our existing IT infrastructure to ensure continued network readiness. Our strategies leverage innovative, effective, and sustainable IT providing the greatest return on our technology investments. We will utilize the power of technology to engage and empower our workforce and customers, gain efficiencies through mobility, and provide increased online services.
STRATEGIES Simplify access to DMV information Increase mobile applications Establish Services Catalog
[3]
Legislative Analyst Office (LAO) Improving Customer Service Efficiency at the DMV, Mac Taylor , February 24, 2012
2. ATTRACT AND RETAIN A SKILLED IT WORKFORCE Technology facilitates our ability to make transformative changes in the way we do business. However, it is DMV IT’s dedicated employees who are the catalyst in identifying and delivering innovative and efficient technology-based solutions. A valued and empowered IT workforce is key to achieving our business and IT mission, vision, and goals. DMV IT understands the importance of workforce and succession planning. The objectives outlined in this plan are dynamic and reflect the Department’s commitment to a skilled and empowered workforce. They provide opportunities for professional growth and development and include mentoring, mobility, transfer of knowledge, improved communication, collaboration, and training. Investing in our IT workforce will ensure DMV has the leadership, knowledge-base, and skill-set necessary to maintain and evolve the existing DMV IT infrastructure and support emerging technologies.
STRATEGIES Revitalize Workforce Succession Plan Advance technical training efforts Establish outreach and marketing programs Establish a mentor and apprenticeship program
3. ANALYTICS DRIVE DECISION MAKING DMV collects and stores 100s of terabytes of data, much of it related to vehicle registration, driver licensing, occupational licensing, and payments via credit and debit cards. This data provides DMV with the information necessary to better understand the needs of our internal and external customers and business partners. As custodians of the DMV IT infrastructure, we are accountable for the reliability of the data we collect. The ability to rapidly identify, extract, analyze, and accurately interpret this data is essential to making effective business decisions. IT provides the agility to quickly and accurately gather, compile, and share critical data with other government agencies to rapidly respond to local and/or statewide emergencies and natural disasters, ensuring the public trust. This data also enables DMV to develop overarching efficient and effective disaster recovery guidelines, ensuring business continuity. Included in this plan are strategies that enable DMV to remain forward thinking and agile. They facilitate our ability to make real-time, data driven decisions through the identification of reliable information, statistics and trends, and respond timely to data requests.
STRATEGIES Establish DMV Dashboard Implement data tracking and management Utilize data for better analytics and decision making Ensure financial accountability
4. PROTECT DATA AND INFORMATION ASSETS Security threats are changing as rapidly as technology. DMV remains ever-vigilant against internal and external security breaches and attacks on our IT infrastructure and data assets. We continue to evolve the strategic framework to enable management of the DMV IT infrastructure from one central point. This includes refining our information privacy and security programs through implementation of department-wide, consistently applied policies, standards and procedures. This plan identifies strategies that enhance information security and privacy through employee education and awareness programs. They also include continued modernization of our IT infrastructure to provide a more robust, reliable network with increased interoperability security. These objectives facilitate our ability to increase transparency in a manner that ensures the public’s trust.
STRATEGIES Centralize IT security policy Ensure consistent enforcement of DMV information security and privacy policies Ensure the privacy and security of DMV data through education and awareness Increase interoperability security
5. MATURITY THROUGH STANDARDS The DMV has achieved greater efficiency and transparency through implementation of additional online services, mobile applications, and utilization of social media. Implementing innovative technologies is a dynamic ongoing process. Our strategic framework ensures successful execution of the process through standardized governance, policy, planning, and management. DMV will continue strengthening the strategic framework to mitigate risk and meet future technology challenges. We have identified opportunities to refine our enterprise architecture and advance the management, tracking, and accessibility of our data assets. Activities include maturing our IT, information security, and information privacy guidelines, standards, policies and procedures to further ensure our organizational and network readiness.
STRATEGIES Develop and implement DMV communication and technology standards Update and implement standard IT practices to improve operational efficiency Enhance business enablement and implement self help technology Implement tools reduction strategy to reduce and consolidate supported technologies Improve organizational maturity
6. IMPROVE COLLABORATION AND COMMUNICATION DMV has historically nurtured a business culture wherein opportunities for collaboration with our business partners and other government agencies are actively pursued to provide more efficient services to the citizens of California. These collaborative efforts provide mutual efficiencies and facilitate timely issuance of complete and accurate vehicle registration and driver licensing products and information. Sharing information and data with other government and business entities facilitates our customers’ ability to achieve success on their initial point of contact with the DMV. The IT and Business team have identified strategies for improved communication and collaboration across the organization, with other state agencies as well as the business and education communities. The DMV will advance existing partnerships and cultivate new alliances to employ joint-strategies.
STRATEGIES Develop expertise and knowledge sharing opportunities to increase awareness Create and leverage higher education partnerships Develop and implement an online collaboration strategy Implement IT standards
IT STRATEGIC PLANNING For the Department of Motor Vehicles, strategic planning is an ongoing process. It is part of the governance process and a critical component of our strategic framework. Strategic planning is the method through which we achieve continuous transformation and excellence in our business processes and services. Over time, as we have matured our framework, the process of strategic planning has assimilated into our organizational culture. This process is part of the daily dialogue that occurs from the top down, bottom up, across divisions and programs, and from the front line to the back end. Key components include:
DMV IT framework ensures that goals are met, risks are mitigated, and maximum value is delivered to sustain and grow our organizational effectiveness and readiness. Key components of our strategic framework include Governance, Enterprise Architecture, Enterprise IT Standards, and Project Management.
GOVERNANCE Governance is the foundation of DMV’s IT Strategic Plan. For DMV purposes, governance is the: Framework that defines roles and responsibilities for decision making. Management of the governance process in decision making. Means to ensure an organizational, enterprise-wide decision-making perspective. Process by which strategic goals are aligned, resources are valued, and sound management is achieved. Effective governance allows DMV to capture applicable data through established processes, leveraging the information to gain maximum business value.
ENTERPRISE ARCHITECTURE DMV’s three-tier Enterprise Architecture (EA), guided by the use of enterprise principles and standards, establishes uniform criteria to provide an enterprise approach to technology and business planning. This approach maximizes the value of IT to the business, advances target architectures, and promotes enterprise thinking.
ENTERPRISE IT STANDARDS Enterprise IT Standards covers the broad spectrum of technology environments to include software, hardware, networks, applications, data, security, access, communications, project management, and other relevant architecture disciplines. Standards can be in the form of a Policy, Procedure or Guideline. A standard is developed to define the preferred method of operations which guides the organization and supports the reduction of costs, redundancy, and risks while increasing the productivity and knowledge of the IT workforce. The DMV approach to IT Standards is focused on balancing the need for a set of standards with the need for a diversity of solutions to meet strategic objectives and increase innovation, business growth and competitive advantage.
PROJECT MANAGEMENT DMV uses an Enterprise Project Management approach to fulfill its strategic needs. The DMV IT Project Management methodology aligns with the California Technology Agency policies and guidelines, Project Management Institute standards, and industry best practices to provide a common and consistent method of managing projects within the Department. The Project Life Cycle includes a defined System Development Life Cycle that provides the necessary framework to ensure successful implementation of IT Projects.
IMPLICATIONS TO ADDRESS The rapid advancement of IT and the ups and downs of our current economy are generating changes to societal norms, evolving the needs of our customers, business partners, and workforce. Diligent execution and oversight of the plan will enhance our ability to rapidly identify and address new opportunities as well as associated risks and threats as we progress.
CONCLUSION This plan addresses the challenges we face as an organization and presents strategies to ensure DMV is prepared to meet the current and future business needs of our workforce and customers in a rapidly changing, hyper-connected world. Ultimately, our success will be determined by our ability to empower our business program partners, the workforce, and our customers to gain efficiencies through the use of innovative and sustainable information and communication technologies. We must sustain excellence in our business and extend that excellence to the citizens of California in a secure and transparent manner that ensures the public’s trust. We are committed to maintaining open lines of communication with the Executive Business Teams to monitor and ensure continued relevancy and alignment with DMV business goals and strategies and to respond to changes in our legislative, regulatory, economic, and operational environment. Recognizing the potential opportunities new technologies present, we remain prepared to reap the potential benefits they offer and mitigate associated risks. Effective implementation of this plan is dependent upon the continued support of Executive Management. Together we will leverage the power of innovative and efficient IT to sustain excellence and achieve future transformation.
CA Department of Motor Vehicles Office of Strategic Planning and Organizational Development 2415 First Avenue, MS F500 Sacramento, CA 95818
Office of Strategic Planning and Organizational Development
[email protected]
This plan is available to employees on the DMV Intranet.
..
PERFORMANCE BOLQ TO ACCOMPANY CONTRACT [NOW ALL MEN
BOND NO:
TO THESE PRESENTS,
THAT WHEREAS, The S t a t e of California, acting b y and r h r o u g h , t h e D e p s r t n e n t of Transpor?zaEion, has awarded to
rs principal, hereinaf-tler . d e s i g n a t e d as rEle "Contractor"; ?or t h e w o r k described as f o l l o w s :
a contract
AND WHEREAS, The Contractor i s r e q u i r e d t o furnish a >and in connection w i t h s a i d contract: guaranteeing rhe farithful
>erformance'~hereof:
.
NOW THEREFORE, W e the u n d e r s i g n e d ' Contractor a n d , s u r e t y i r e h e l d and firmly bound u n t o t h e S t a r e o f 'California, i n tlie sub of '
. .
.
.
dollars $ ), to be p a i d to t h e sa'id S t a t e o r its c'ertain . t t t o r n e y , i t s s u c c e s s o r s a n d a s s i g n s ; f o r w h i c h payment, we31 an6 ~ r u l yto be made, w e b i n d o u r s e l v e s , o u r heirs, executors a n d ~ d m i n i s t r a r o r, s successors o r a s s i g n s , jo i n t l y and s e v e r a l l y , !irmly b y .these p r e s e n t s .
:
,
,
W E C O N D I T I O N OF THIS O E Z I G A T I O N IS SUCH T h a t i f the above b o u n d e n C o n t r a c t o r , . h i s o r i t s h e i r s , . ? x e c u t o r s , a d m i n i s tracers, successors or a s s i g n s , , s h a l l Ln a l l ~ h i n g ss t a n d t o a n d . a b i d e by, and well and truly keep and. perform :he covenants, conditions and agreements in the foregoing contract rnd z n y a l r e r a t i o n rhereof made a s c h e r e i n p r o v i d e d , on his or :heir part to be kept and performed at the time and i n t h e manner i h e r e i n s p e c i f i e d , and in all respeccs a c c o r d i n g to their t r u e l n t e n t and meaning, and s h a l l i n d e m n i f y and save,harmless t h e ;tate of C a l i f o r n i a , its o f f i c e r s and agents, as t h e r e i n s t i p u l a t e d , :hen this o b l i g a t i o n s h a l l become and be nu1.l and v o i d ; otherwtse t s h a l l be and remain i n f u l l f o r c e a n d v i r r u e . '
,
.
FOR FILING,ADAIINSTRATIVE REGULAPtfPNS i WETM THE SECRETARY OF STATE (Pvrioonf ... .. '
i~ Govornrnont Cod;!
Saclion 11380.1) ,/ .-
.-
- ._ '-.
,
_
,,
,,
,. ., .,.... . .. . . ...... . .
.-
i' I
IN WITNESS WHEREOF, We have hereunto e a l s on t h i s
.
'
s e t our hands a n d
,
,A.D.,
day o f
9
;orrespondenc.e or claims r e l a r i n g : o thCs bond should b e sent to the u r e t y at t h e f o l l o w i n g address.: .- .. -.
Contractor
.
(Seal) N a m e of Surery BY
IOTE:
Attorney- i n - t a c ~ . '
Signatures of t h o s e executing for the s u r e t y m u s t be p r o p e r l y acknowledged.
CERTIFICATE'OF ACKNOWLEDGMENT TATE O F CALIFORNIA !OUNTY O F
-
ON THIS . DAY OF BEFORE ME, A NOTARY PUBLIC I N AND FOR . F ~ I D PERSONALLY , APPEARED .9
THE
IN THE YEAR COUNTY AND STATE
LNOWN T O ' M E TO BE THE . P E R S O N ~ ~ O S E M A MIS E SUBSCRTBED TO THE WITHIN :MSTRUMENT AND KNOWN TO ME TO BE THE ATTORNEY-IN-??ACT OF AND ACKNOkXEDGED TO ME THAT HZ ;UBSCRIBED THE KAME OF TEE S A I D COMPANY T'IIERE TO AS SURETY, AND I I S OWN NAME AS ATTORNEY-IN-FACT, ,
Notary Public
