U.S. Department of Justice
Office of Community Oriented Policing Services 
Image of Department of Justice Seal
Law Enforcement Tech Guide for
Information 
Technology Security 
How to Assess Risk and Establish Effective Policies 
A Guide for Executives, Managers, and Technologists
Image of cover art:  globe superimposed on microchip

Copyright  2006 SEARCH Group, Incorporated. The U.S. Department of Justice reserves 
a royalty-free, nonexclusive, and irrevocable license to reproduce, publish, or otherwise 
use, and to authorize others to use, this book for Federal Government purposes. This 
document may be freely distributed and used for noncommercial and educational 
purposes. No part of this book may be reproduced in any form, by any means (including 
electronic, photocopying, recording, or otherwise) for commercial purposes without the 
prior permission of the U.S. Department of Justice or the authors. 

U.S. Department of Justice
Office of Community Oriented Policing Services 
Law Enforcement Tech Guide for
Information 
Technology Security 
How to Assess Risk and Establish Effective Policies 
A Guide for Executives, Managers, and Technologists 
By Kelly J. Harris and Todd G. Shipley, CFE, CFCE 
This publication was supported by cooperative agreement #2003CKWXK054 awarded 
by the U.S. Department of Justice Office of Community Oriented Policing Services to 
SEARCH Group, Incorporated, 7311 Greenhaven Drive, Suite 145, Sacramento, CA 95831. 
The opinions or recommendations contained herein are those of the author(s) and do not 
necessarily represent the official position or policies of the U.S. Department of Justice. 
References to specific organizations, products, or services should not be considered an 
endorsement of the product by the author(s) or the U.S. Department of Justice. Rather, 
the references are illustrations to supplement discussion of the issues. 

Image of Department of Justice Seal
U.S. Department of Justice
Office of Community Oriented Policing Services 
Office of The Director 
1100 Vermont Avenue, NW 
Washington, D.C. 20005 
Dear Colleague, 
Technology systems have contributed significantly to the operational effectiveness and 
efficiency of law enforcement agencies of all types. As the ability to collect, share, and 
use information continues to gain momentum in modern policing, technology tools that 
offer agencies the chance to develop this ability are ever more omnipresent. Yet, as much 
as we rely on technology for some of our most sensitive and necessary activities, securing 
that technology is often an afterthought to system deployment rather than being an 
integrated part of the strategic implementation process. 
The Law Enforcement Tech Guide for Information Technology Security: How to Assess 
Risk and Establish Effective Policies is intended to provide the law enforcement 
community with strategies, best practices, recommendations, and ideas for developing 
and implementing information technology security policies. It will help you identify 
and assess information technology security risks within your agency and provide ideas 
for mitigating them. Moreover, it will encourage readers to view security policies and 
practices as an ongoing process of assessment, modification, and measurement. 
This guide is one of the many resources that the Office of Community Oriented Policing 
Services (COPS) offers to law enforcement. It can be used as a stand-alone resource 
or used in conjunction with the original Law Enforcement Tech Guide (how to plan, 
purchase and manage technology (successfully!) published by the COPS Office in 2002. 
That guide and many of our other knowledge-based resources can be downloaded from 
www.cops.usdoj.gov, or they can be ordered free of charge by calling the COPS Office 
Response Center at 800.421.6770 or via e-mail at askCOPSRC@usdoj.gov. 
I hope that you find this guide to be both informative and helpful. 
Carl R. Peed 
Director 

Page vii

Contents
Acknowledgments .................................................................... x
About the Authors................................................................... xi
About the Guide 
About the Guide ....................................................................... 3
Assumptions About You........................................................... 5
How this Guide Is Organized.................................................... 6
NISTA Logical Framework for IT Security Policy 
Development.......................................................................... 7
Definitions of Icons .................................................................. 8
A Roadmap to the Guide ........................................................ 10
IT Security Policy DevelopmentA Cyclical Process ............. 12
Chapter 1
Information Systems Security: Understanding Your 
Responsibility, Security Policies, and Risk .................... 17
A Responsibility to Secure Your Systems ................................ 18
What Is a Security Policy?....................................................... 20
What Are the Risk Factors to an IT System? ........................... 22
Evaluating Risk Is Key to Developing Security Policies ........... 25
How Security Policies Control Risk......................................... 25
Chapter 2
Organize and Charge the Security Policy Development 
Team ............................................................................... 29
Step 1: Get Senior Leadership to the Table ............................. 30
Step 2: Identify Stakeholders .................................................. 31
Step 3: Assign a Project Manager ........................................... 32
Step 4: Create a Governance Structure with Roles and 
Responsibilities .................................................................... 33
Step 5: Review Your Agency Mission and Objectives.............. 35
Step 6: Allocate Resources ...................................................... 36
Step 7: Adopt a Methodology and Plan of Action .................. 36
Sample Security Policy Development and 
Implementation Scenario .................................................... 38

Page viii

Chapter 3
Phase IConduct a Security Self-Assessment ................. 45
The Self-Assessment Process .................................................. 46
Step 1: Identify the Systems, Single System, or System Part 
for Which You Will Develop Security Policies...................... 47
Step 2: Assemble the Appropriate Participants for the 
Process and Hold a Kickoff Meeting .................................... 47
Step 3: Gather Organizational Data ....................................... 48
Step 4: Conduct the Self-Assessment ...................................... 57
The SEARCH IT Security Self- and Risk-Assessment Tool: 
Easy to Use, Visible Results .................................................. 61
Chapter 4
Phase IIAssess Security Risks....................................... 71
Why Is the Risk-Assessment Process Important? ................... 72
Conduct a Risk Assessment .................................................... 73
Step 1: Identify the Risk and Write a Description of It........... 73
Step 2: Categorize and Quantify the Identified Risks.............. 74
Step 3: Determine Your Tolerance for Levels of Risk.............. 76
Make Your Risk Assessment Easier by Using the 
SEARCH Assessment Tool.................................................... 78
Whats Next? .......................................................................... 80
Chapter 5
Phase IIIDevelop a Risk-Mitigation Strategy ............... 83
Prioritize Your Agencys Risks ................................................ 84
What Are Security Controls? .................................................. 84
Build Your Agencys Controls in Six Steps .............................. 89
Document the Controls .......................................................... 94
Select Which Controls to Implement and Assign 
Responsibility ...................................................................... 94
Develop an Implementation Plan ........................................... 95
Chapter 6
Phase IVMeasure Your Security Controls .................... 99
What Are Security Measures? .............................................. 100
Develop and Select Measurement Methods ......................... 100
Build Your Agencys Measures in Seven Steps ...................... 103

Page ix

Chapter 7
Formalize Your IT Security Policies ..............................111
Write an Information Security Policy in Six Steps .................113
Conclusion ................................................................... 118
Appendixes 
A. Assessment Worksheets and Questions from the
SEARCH IT Security Self- and Risk-Assessment Tool ..... 121
B. SEARCH IT Security Worksheets: Control Development,
Measurement Development, Policy Development ......... 181
C. Glossary of Security Terms ............................................ 189
D. Security Resources.......................................................... 195

Page x

Acknowledgments
This publication was prepared by SEARCH, The National Consortium for Justice 
Information and Statistics, Mr. Francis X. Aumand III, chair, and Ronald P. Hawley, 
executive director. The project director was Kelly J. Harris, deputy executive director. 
Ms. Harris and Todd G. Shipley, CFE, CFCE, director of training services, wrote this 
publication. James E. Jolley, CISSP, computer training specialist, was a contributor. Twyla 
R. Putt, corporate communications manager, edited this publication. Jane L. Bassett, 
publishing specialist, provided layout and design. Chris Roebuck, webmaster, provided 
web site coordination. The federal project manager was Debra Cohen, Ph.D., of the U.S. 
Department of Justice Office of Community Oriented Policing Services (COPS). The 
authors would like to thank the Hawaii Attorney Generals Office IT Group for its advice 
in the development of the early drafts of the self- and risk-assessment tool. 
Suggested Citation 
Harris, Kelly J. and Todd G. Shipley, Law Enforcement Tech Guide for Information 
Technology Security: How to Assess Risk and Establish Effective Policies, Washington, D.C.: 
U.S. Department of Justice Office of Community Oriented Policing Services, 2006. 
About Us 
SEARCH, The National Consortium for Justice Information and Statistics, is dedicated 
to improving the quality of justice and public safety through the use, management, and 
exchange of information; application of new technologies; and responsible law and 
policy, while safeguarding security and privacy. 
We assist local, tribal, county, regional, and state agencies and organizationsincluding 
law enforcement and public safety; first responders; prosecution; defense; adjudication; 
detention; corrections and probation; and other disciplines, such as transportation, 
drivers licensing, vehicle registration, public health, and social servicesthrough a 
broad array of activities, resources, and products. Our focus is on criminal history 
systems, integrated justice information systems, information technology (planning, 
purchasing, managing), communications interoperability, and cybercrime investigation. 
Our services include in-house and on-site technical assistance and training, resource 
development (web sites, publications, white papers, conferences, workshops), public 
policy assistance, and model development (model legislation, standards and procedures, 
best practices) in these focus areas. SEARCH online resources provide information on law 
enforcement information technology (IT), integrated justice, justice software solutions, 
and IT acquisition at www.search.org. 

Page xi

About the Authors
Author Kelly J. Harris is deputy executive director for SEARCH, where she oversees 
the development, implementation, and management of all SEARCH programs and 
related projects. SEARCH programs focus on IT and its successful application to justice 
and public safety decision-making. In each program, Ms. Harris directs a broad array 
of activities, resources, and products provided to local, regional, tribal, and state justice 
and public safety agencies nationwide. These include technical assistance, training, 
resource development (publications, web sites, model development), national-scope 
policy research, and national workshops, symposia, and conferences. Ms. Harris oversees 
programs funded by grants, cooperative agreements, and contracts from the U.S. 
Departments of Justice (DOJ) and Homeland Security (DHS), and from state and 
local agencies. 
The key focus areas of SEARCH programs overseen by Ms. Harris are: 
 Law and policy issues associated with information and identification technologies 
 Planning for and implementing information-sharing technology 
 Interoperable communications technologies 
 High-technology crime investigation. 
Program activities and resources address such issues as justice information-sharing 
system integration; how to plan for, develop, improve, acquire, and manage automated 
systems; homeland security; and combating cybercrime. Specific projects involve 
Internet crimes against children, national criminal history repository improvements, 
justice information exchange modeling, and community oriented policing services. 
Ms. Harris has developed, organized, and presented at numerous national symposia 
on justice information sharing and technology, and technical assistance workshops and 
conferences on justice and public safety IT planning and implementation issues. These 
programs have trained thousands of practitioners and state and local policymakers. 
She has written numerous articles, technical bulletins, and reports on justice system 
automation and integration for SEARCH and for publication by the U.S. DOJ. She 
has also provided technical assistance on issues relating to justice and public safety 
information sharing, interoperability, and integration. 
Ms. Harris is a member of various advisory committees, including the Law Enforcement 
Information Technology Standards Council and the Global Justice Information Sharing 
Initiatives Intelligence Working Group. Ms. Harris joined SEARCH in 1991. She received 
a bachelors degree in political science and communications from the University of 
California, Davis. 

Page xii

Author Todd G. Shipley is director of training services for SEARCH, where he oversees 
a national program that provides expert technical assistance and training to local, state, 
and federal justice agencies on successfully conducting high-technology computer 
crimes investigations. 
Mr. Shipley instructs and oversees a variety of SEARCH technology crimes courses 
offered at its National Criminal Justice Computer Laboratory and Training Center in 
Sacramento, California, and at other sites nationwide. SEARCH assistance and training 
servicesprovided by an experienced team of certified computer crimes investigators 
and information systems security professionalsfocus on systems security, computer 
forensics, and investigations involving the Internet, local area networks, and online 
child exploitation. 
Mr. Shipley has 25 years of experience in law enforcement, all with the Reno (Nevada) 
Police Department, where he developed subject-matter expertise in computer forensics, 
online investigations, and information technology security. Prior to joining SEARCH 
in 2004, he was a senior detective sergeant managing the departments Financial and 
Computer Crimes Unit, where he investigated serious fraud- and financial-related 
offenses using basic investigative, technical, and covert surveillance techniques. He was 
responsible for developing cybercrime and technology crime investigative policy; serving 
as a liaison to other law enforcement, intelligence, and government agencies and industry 
bodies; providing department/regional training; and serving as an expert witness. 
His previous positions with the Department included 4 years as a detective and detective 
sergeant assigned to the U.S. Attorneys Office Organized Crime Drug Enforcement Task 
Force, 5 years as a detective investigating major property and person crimes, and 8 years 
as a patrol officer. Mr. Shipley formed Nevadas First Computer Crime Investigations 
Unit. He is a Certified Fraud Examiner (CFE) through the Association of Certified 
Fraud Examiners and a Certified Forensics Computer Examiner (CFCE) through the 
International Association of Computer Investigative Specialists. He is a member of the 
High Technology Crime Investigation Association (HTCIA), and has written and spoken 
extensively on computer forensics and technology crime topics. 
Contributor James E. Jolley is a computer training specialist for SEARCH, where he 
performs a variety of tasks related to the provision of training to local, state, and federal 
agencies on computer technology issues with criminal justice applications. He also 
researches techniques for online investigations, assists in preparing material for the 
computer training courses, assists with computer forensic examinations, and maintains 
the computer network and equipment of SEARCHs National Criminal Justice Computer 
Laboratory and Training Center in Sacramento, California. 

Page xiii

Before joining SEARCH in 2002, Mr. Jolley worked primarily in the computer security 
industry. He has served as a network security analyst for SBC, a senior security analyst 
for Chevron/Texaco, and a security consultant for CHG, LLC. In these capacities, he has 
configured and managed firewalls, installed and monitored intrusion detection systems, 
performed network scans for customer sites, provided on-site technical assistance for users, 
and worked in security policy development. 
Mr. Jolley holds a bachelors degree in computer science from the University of San 
Francisco, and has completed graduate course work in quantitative business methods at 
California State University, Hayward. He is a member of both the Information System 
Security Association and the HTCIA. He has several certifications, credentials, and licenses, 
including Certified Information Systems Security Professional (CISSP), Certified Wireless 
Network Administrator (CWNA), Microsoft Certified Professional (MCP), Cisco Certified 
Network Associate (CCNA), Cisco Certified Design Associate (CCDA), and CheckPoint 
Certified System Engineer (CCSE). He has also received extensive training on computer 
crime investigation, forensic computer science, Microsoft, Cisco, and CheckPoint. 
IT Security Tech Guide Review 
Committee 
SEARCH extends its deepest thanks and appreciation to the members of the IT Security 
Tech Guide Review Committee, who participated in an advisory capacity during the 
preparation of this Guide. These individuals have direct experience in law enforcement IT 
planning, procurement, implementation, and management and generously contributed 
their time and expertise over a period of many months, providing critical review and 
comments on early drafts of the Guide. Their contributions to the successful completion of 
this Guide cannot be overstated. 
William Spernow 
Security Mentors, LLC 
Security Consultant 
Liane M. Moriyama 
Hawaii Criminal Justice Data Center 
Susan Ballou 
Office of Law Enforcement Standards 
Steering Committee Representative for 
State/Local Law Enforcement 
National Institute of Standards and 
Technology 
Dr. Ron Glensor 
Reno (Nevada) Police Department 
Computer Security Division 
Steve Correll 
NletsThe International Justice & Public National Institute of Standards and 
Technology 
Mark Wilson, CISSP 
IT Specialist (Information Security) 
Information Technology Laboratory 
Safety Information Sharing Network 

Page xiv

Special Thanks 
In addition to the peer reviewers mentioned above, SEARCH extends special 
thanks to the following organizations that provided additional critical review of 
this document: 
 U.S. Department of Justice Office of Community Oriented Policing 
Services 
 The Bureau of Justice Assistance and U.S. Department of Justices Global 
Justice Information Sharing Initiative 
 Security Committee, Integrated Justice Information Systems Institute 
 Security and Access Ad Hoc Subcommittee, FBI Criminal Justice 
Information Services Advisory Policy Board
 Microsoft Corporation. 

About the Guide

A Library of Tech Guide Resources
This Tech Guide on information technology security is intended to serve 
Law Enforcement Tech Guide: How to plan, purchase 
and manage technology (successfully!). The original Tech Guide was published 
in 2002 by the U.S. Department of Justice Office of Community Oriented 
Policing Services (COPS) and was developed as a step-by-step guide to help law 
enforcement agencies as they implement new technologies. 
This Information Technology Security Tech Guide is intended to complement 
and be used along with the original Tech Guide. As such, this Guide makes 
frequent references to content in the original Tech Guide. It may help to keep the 
original Tech Guide close at hand so you can refer to particular pages and sections 
This Tech Guide is one of a series of four topic-specific Tech Guides funded 
by the COPS Office. The four companion Tech Guides that will form a 
comprehensive library of technology resources, along with the original Tech 
Guide, are: 
Law Enforcement Tech Guide for Small and Rural Police Agencies: A Guide for 
Executives, Managers, and Technologists 
Law Enforcement Tech Guide for Creating Performance Measures that Work: A 
Guide for Executives and Managers 
Law Enforcement Tech Guide for Communications Interoperability: A Guide for 
Interagency Communications Projects 
Law Enforcement Tech Guide for Information Technology Security: How to Assess 
Risk and Establish Effective Policies 
See page 5 for details on how to download or order your copy of the original 
Enforcement Tech Guide

About the Guide

Technology continues to proliferate throughout law enforcement. Indeed, information 
systems are indispensable tools for effective, expedient, and well-informed policing. 
Technology also poses an enormous security risk. Law enforcement agencies that 
operate mission-critical information technology (IT) systems without adequate 
security controls in place put the public, themselves, and our government at extreme 
risk. Data contained within these systems are extraordinarily sensitive and mission-
critical. Sensitive case reports, confidential investigative data, agency intelligence, 
suspect and personal data, and personnel information are just a few examples of data 
that may be subject to compromise via a malicious hack, an untrustworthy insider, an 
accidental misuse of the system, and/or a natural disaster. 
Creating security policies and instituting a security process has traditionally beenat 
bestan afterthought in many IT implementations. Too often, only marginal 
consideration is given to the security of a system (such as requiring passwords) 
when it is being developed or implemented. What is missing is the adoption of an IT 
security policy development process, a conscious decision by senior management to 
establish a formal procedure to investigate and analyze the very real security risks to 
the agencys IT systems, and to develop mechanisms and policies designed to mitigate 
those risks. Securing an information system is much more involved than merely 
requiring a password, applying a digital signature, or using encryption. It is an 
organizational strategy that must be driven by the highest levels of 
the organization. 
Controlling risk 
is key to having a 
secure information 
system. 
Therefore, 
identifying what 
those risks are is 
an important first 
step to developing 
effective IT security 
policies. 
Having effective information technology security policies is essential to protecting 
the information assets of an agency from accidental or malicious compromise. This 
Guide offers an approach to help law enforcement agencies through the often 
complex process of developing and implementing effective information 
security policies. It also provides a framework to establish an ongoing process to 
gauge the performance and effectiveness of these policies. 
Understanding your security risks is central to building an effective IT security 
program. Unless you can figure out what your agencys exposures are, you will 
probably not be successful in reducing your overall risk. Controlling risk is key to 
having a secure information system. Controlling risk allows you to avoid exposures 
that, if unidentified, could be exploited and result in damage to your system, your 
data, and your agencys reputation. 

About the Guide 4

HOW TO USE THIS GUIDE 
This Law Enforcement Tech Guide for Information Technology Security: How 
to Assess Risk and Establish Effective Policies is intended to provide strategies, 
best practices, recommendations, and ideas for developing and implementing IT 
security policies. This Guide should not be construed as specific legal advice for any 
generally encountered in law enforcement IT security policy environments. It does not 
replace or supersede any policies, procedures, rules, and ordinances applicable to your 
specific factual situation. This publication is meant to serve as a guideline for situations 
jurisdictions IT security situation. This Guide is not legal counsel and should not be 
interpreted as a legal service. 

This Guide walks you through the essential components of risk management, which 
include undertaking a detailed self-assessment of your IT system, which will ultimately 
enable your agency to identify its security risks, and then to mitigate these risks through 
the development of effective security policies. 
How can you get 
your own copy of 
the original Law 
Enforcement Tech 
Guide? See page 5. 
This document can be used independently or along with Law Enforcement Tech Guide: 
How to plan, purchase and manage technology (successfully!), which SEARCH created 
in 2002 under a cooperative agreement with the U.S. Department of Justice Office 
of Community Oriented Policing Services (COPS).1 That publication provided law 
enforcement technology practitioners with a useful, hands-on guide for implementing 
various types of technology. Although this IT Security Tech Guide is a great resource on 
its own, we suggest keeping the original Law Enforcement Tech Guide close at hand. The 
two guides are complementary and, used together, make a comprehensive toolset. 
If you dont have a copy of the original Law Enforcement Tech Guide, download or order 
one. Since this Guide on IT security policies is intended the complement the original, at 
times we will refer to it rather than repeat advice. 

1 Harris, Kelly J. and William H. Romesburg, Law Enforcement Tech Guide: How to plan, purchase and 
manage technology (successfully!), A Guide for Executives, Managers and Technologists, Washington, D.C.: 
U.S. Department of Justice Office of Community Oriented Policing Services, 2002. 

About the Guide  5

SourceS of the Original
Law Enforcement Tech Guide 
The COPS Office published the Law Enforcement Tech Guide in 2002. It is available 
electronically from the COPS Office web site at www.cops.usdoj.gov/default. 
asp?Item=512. There it is broken down into its separate parts as Portable Document 
Format (PDF) files so you can download or read one at a time. 
If youre anxious to download the entire document at onceall 14 megabytesthe 
complete version can be found on SEARCHs web site: www.search.org/files/pdf/ 
techGuIde.pdf. 
Hard copy versions are distributed by the COPS Office. To request one, contact the 
COPS Office Response Center at 800.421.6770 or via e-mail at 
askcoPSrc@usdoj.gov. 

Assumptions About You
To prepare this Guide, we had to make some assumptions about you, the reader. 
You may be the first person in your agency to get this Guide and read it; or, you may 
be part of a security team that has been formed to develop and implement security 
policies. Perhaps you are the chief or sheriff who will lead this effort. Regardless of 
your position in the agency, your personal knowledge of the agencys operations 
is integral to this projects success. Understanding the movement of and need for 
information within your agency to accomplish its daily business needs is valuable. You 
may be the person in your agency responsible for technical support (and that does 
not exclude you from also being one of the other types of readers as well!). If so, you 
may be called upon to research the technical aspects of this project as they affect and 
change the operations of your agencys systems. 
Finally, you might be a project manager who possesses useful project management 
skills, yet who has little experience with law enforcement. Or, you may not have 
any project management skills, but you have been assigned to manage this task 
nonetheless. Either way, your role of project manager is pivotal to this effort. You are 
the go-to person for project information and coordination. In most law enforcement 
agencies, both sworn and civilian personnel must wear many different hats; very 
few agencies have the resources to fully staff an IT support department or to hire a 
dedicated project manager. We assume many of our readers will fall into one or more 
of the categories above. If so, this IT Security Guide is designed to help each of you. 

About the Guide 6
How this Guide Is Organized 
The purpose of this how-to Guide is to provide you with a series of general steps 
through which you can: 1) understand and identify your security exposures, 2) 
develop and implement controls to mitigate these identified security risks, 3) create 
and implement a program to measure the effectiveness of these controls, and 4) using 
the work done in the previous steps, develop and implement security policies for your 
agency. The processes will involve many different persons and skill sets. Only when 
you have a set of security policies and their associated security controls (procedures) 
in place, and you have implemented a process to monitor their effectiveness, can you 
effectively maintain the security and integrity of your IT systems. 
What will you learn from this Guide? 
 An overview of security risk management; the importance of implementing 
an information security policy; and the critical leadership role of managers in 
policy initiatives. 
 Who to involve in your project and how to develop your Security Policy 
Development Team. 
 The four key phases of the IT security development and implementation 
process. 
 Learn how to conduct a self-assessment, which provides a status report of 
your current system (see Phase I). 
 Through a risk assessment, determine what security exposures exist in 
your IT systems, using findings from the self-assessment (see Phase II). 
 Learn how to properly develop and implement security controls to 
mitigate the identified risks (see Phase III). 
 Learn how to develop and implement an ongoing measurement process 
to ensure that the controls are effectively mitigating the risks (see Phase 
IV). 
 The hands-on process of how to write information security policies. 

About the Guide 7
The NIST Security 
Manuals are: 
Not copyrighted. 
Developed by 
a recognized 
and competent 
organization. 
Focused on 
government 
information 
security operations, 
not corporate 
operations. 
They are available 
online at http:// 
www.nist.gov 
and through the 
Computer Security 
Resource Center 
at http://csrc.nist. 
gov/. 
See Appendix 
D for a list and 
description of 
key NIST security 
documents. 
NISTA Logical Framework for IT Security 
Policy Development 
The National Institute of Standards and Technology (NIST) was tasked, after the 
E-Government Act (Public Law 107-347) was signed into law by the President in 
December 2002, to formulate and publish standards for all federal agencies to follow 
when developing information security policy and procedures. As such, NIST has 
produced and maintained numerous security manuals that create a standardized 
process for IT security policy development, particularly focused on government 
operations. We believe the NIST framework provides the most robust, consistent, 
and widely used methodology for government agencies on which to base their 
security policies. 
The NIST manuals are complex and voluminous, comprising more than 7,000 
pages of free reference works. This Guide borrows some of the key NIST principles 
to develop a framework for state and local law enforcement security policy 
development, and tailors their application to the unique issues and challenges that 
law enforcement agencies face when developing security policies and procedures. 
We will reference NIST documents throughout this Guide where appropriate for 
additional reading and research. 
The key for an agency wishing to follow a national and standardized methodology, 
such as the NIST guidelines, is to develop security policies consistent with the federal 
agencies with which your state and your agency may share data (for example, the 
FBIs Criminal Justice Information Services program). 
Global Document a Key Companion to Security Policy 
Development Efforts 
Another must-have document is Applying Security 
Practices to Information Sharing Systems. This excellent 
resource document, developed by the Global Justice 
Information Sharing Initiative Security Working 
Group, is designed to educate justice executives and 
managers in basic, foundational security practices 
that they can deploy within their enterprise and 
between multiple enterprises. This document and 
its companion CD contain background information, 
overviews of best practices, and guidelines for secure 
information sharing. The document (in PDF) and CD 
(a browser-style, graphical overview of the document) 
are available at http://it.ojp.gov/global. 
Image of front cover of Applying Security 
Practices to Information Sharing Systems

About the Guide 8

The Global Justice Information Sharing Initiative (Global) serves as a Federal 
Advisory Committee, advising the U.S. Attorney General on justice information 
sharing and integration initiatives. Global was created to support the broad-scale 
exchange of pertinent justice and public safety information. It promotes standards-
based electronic information exchange to provide the justice community with timely, 
accurate, complete, and accessible information in a secure and trusted environment. 
We believe that using this Guide, along with the NIST and Global documents, 
provides a comprehensive resource for your agencys security policy 
development initiative. 
Definition of Icons
Throughout this Guide, icons are used to draw your attention to important concepts, 
ideas, reference material, and, in some cases, warnings. Below are the icons and what 
they represent: 
Original Tech Guide Logo
Original Tech Guide Reference 
The parent Tech Guide contains useful tools, charts, and instructions for conducting 
various tasks. When you see this icon, you will be directed to a specific page, or range 
of pages, in the original Law Enforcement Tech Guide. 
Executive Sponsor Icon
Chief/Sheriff/Executive 
This icon alerts chiefs/sheriffs and executive managers to the activities, issues, and 
concepts they need to be aware of. 
Project Manager Icon
Project Manager 
This icon alerts project managers to activities, issues, and concepts they must be 
aware of. 
Stop Sign Icon
Stop Sign 
When you see a stop sign icon, pay particular attention, as it indicates where others 
have encountered trouble in their projects. This icon indicates pitfalls to avoid. 
Tips Icon
Tips 
If we have heard or know of shortcuts or have useful ideas on how to tackle a 
particular task, we will use this icon to let you know. 

About the Guide 9
NIST Icon
NIST 
We will use this icon when we refer to content that originated in a NIST 
publication. 
SEARCH IT Security Icon
The IT Security Self- and Risk-Assessment Tool 
We will use this icon when we refer to the SEARCH IT Security Self- and 
Risk-Assessment Tool, a Microsoft Excel spreadsheet that guides you through a 
detailed assessment of your agencys IT system in three categories: Management, 
Organizational, and Technical. (For a description of this Assessment Tool, see 
page 61.) 

About the Guide 10

A roadmap to the Guide 
Organize and charge the Security Policy development team 
a. Obtain leadership and involvement of senior management. 
b. Identify and recruit internal and external stakeholders and obtain their input and support. 
c. Assign a project manager to guide and oversee the initiative. 
d. Create a governance structure with defined roles and responsibilities. 
e. Review your business mission and IT strategic plan as guidance to your security initiative. 
f. Allocate time and human/financial resources.  
g. Adopt a methodology and action plan 
to developing/implementing your security policies. 
Phase Iconduct a Security
Self-Assessment 
a. Determine which system(s) or system 
part you want to develop security 
policies for. 
b. Assemble appropriate stakeholders 
and hold a kickoff meeting to discuss 
process. 
c. Gather relevant organizational data 
about the system(s) to be assessed.
d. Use the SEARCH IT Security Self- and 
Risk-Assessment Tool to conduct the 
self-assessment. 
e. Compile the results. 

About the Guide 11

Phase IIAssess Security risks 
a. For each assessment question your team answered during the self-assessment, 
identify the risk and write a description of it (use the Assessment Tool for this and 
the remaining risk-assessment tasks). 
b. Categorize and quantify each identified risk (likelihood: remote, possible, or likely; 
severity: high, medium, or low; and area of impact: human, financial, liability, etc.). 
c. Determine your tolerance level for each identified risk (avoid, assume, mitigate, or 
transfer). 
d. Determine a numeric priority for action for each identified risk (1 being highest 
priority, 3 being lowest). 
Phase IIIdevelop a risk-mitigation Strategy 
a. Prioritize risks, using the results of the risk assessment. 
b. Build security controls to mitigate risks (a six-step process). 
c. Document the controls. 
d. Select which controls to implement and manage, and assign responsibility for these. 
e. Develop an implementation plan that articulates how each control is implemented. 
Phase IVmeasure Your Security controls 
a. Develop and select measurement methods for the controls you will implement. 
b. Identify existing measures. 
c. Identify all other possible measures. 
d. Identify implications of measures. 
e. Recommend measures for adoption by management. 
Formalize and write your Security Policy 
a. Identify existing policy that addresses the identified risks. 
b. Write proposed security policy that addresses these risks. 
c. Recommend security policy for adoption by management. 

About the Guide 12

IT Security Policy Development  A Cyclical 
Process 
Developing policies to manage your IT systems must be a first priority for executives 
and managers. Policies lead to procedures for implementing security, the controls that 
prevent security breaches, and solid metrics to measure your effectiveness. In short, 
it is a cyclical process that never endsnot a project that contains defined 
beginning and end points (Figure 1). 
Image of Lock and circular flow chart
Figure 1: Normal It Security System development Lifecycle 

About the Guide 13 
 
Normally, policy drives procedures and measures of effectiveness. However, what 
should you do when policy does not exist? In producing a Tech Guide to help you 
build effective IT security policies, we obviously had to take a linear, step-by-step 
approach and one that assumed that the reader probably did not have comprehensive 
security policies in place. We realize you will probably not be starting from scratch; 
indeed, you may already have several security policies in place that you must adhere 
to. Some policies are known but not well documented, others came from legislative 
and organizational mandates, others may have been developed in response to a 
specific concern, while still others have yet to be developed. 
SDLC is a cyclical 
process regarding 
IT and, in particular, 
policy development. 
It means you 
are never really 
finished with 
an effort, but 
instead, it involves 
continuous 
review, revision, 
enhancement, and 
implementation of 
new and existing 
policies and 
procedures.
In a perfect world, we would have followed a proper System Development Lifecycle 
(SDLC). We would have developed our policy first on how our systems should run and 
interact. Lets fast-forward to the real world. Many state and local law enforcement 
agencies rarely have the good fortune or time and money to develop and complete 
an SDLC for their existing networked systems. Most agencies have already developed 
systems that have grown over time. Some security policy may already exist, as well 
as procedures, controls, and measurements. In most agencies, however, thoroughly 
documented security policies are lacking. 
Our goal is to help you take the policies that already exist (whether or not they are 
written down), build upon them and create a single, comprehensive, documented, 
security policy for your IT assets. To properly develop security policy using the 
model described in this Tech Guide requires a complete understanding of your existing 
system. To achieve this understanding, we recommend that your security policy 
team complete a self-assessment and risk assessment first. These exercises, which will 
provide you with a complete identification of your agencys assets and the potential 
risks to them, are instrumental in helping you determine what controls you need to 
mitigate those risksand the methods you need in place to measure the effectiveness 
of those controls. 
Once completed, these tasksself-assessment, risk identification, risk 
mitigation through controls, and control measurementall inform what your 
policy should be. As we walk you through the policy development process, you will 
see how this all comes together. So, although it is at the end of this Guide that you will 
craft your formal policy statement (which may seem contrary to standard convention 
at first blush), stay with us and follow the creation of policy from beginning to end. 

Stop Sign Icon
Have you read the 
IT Security Policy Development  
A Cyclical Process section yet? 
(Its on pages 12 and 13.) 
If not, it is important that you read it 
before you continue any further. 

Like any risk management process, information 
security must be fully integrated into all relevant 
organizational policies, which can occur only when 
security consciousness exists at all levels. 
From Information Security Governance, 
in ITAUDIT, vol. 4, February 15, 2001, 
The Institute of Internal Auditors 

Chapter 1:
Information Systems Security:
Understanding Your Responsibility,
Security Policies, and Risk

What 
You must clearly understand your responsibility for securing information technology 
(IT), the security risks inherent in IT systems, and how security policies help you 
mitigate them. 
Why
Security policy development is complex and is an activity that has most often been an 
afterthought to information system implementation. Developing IT security policies 
should become integral to effective IT systems planning, procurement, 
and implementation. 
Who 
Everyone in the organization must understand the IT system vulnerabilities and how 
they can occur. Management is responsible for initiating and maintaining effective 
security policies, but ultimately many individuals at varying levels in the organization 
will be involved, including system and information owners, legal counsel, IT support 
staff, and users. 
When 
Ideally, from the beginning of a technology project, but policies can (and should!) be 
developed for IT systems at any time. 

Our increasing dependence on computers and computer networks 
exposes us to the risks of cyber attacks, viruses and hacking that have the 
potential to rob us of our personal identity, disrupt our economy, and 
undermine our national security. 
Rep. Lamar Smith (R-Texas) 
Floor statement 
U.S. House of Representatives 
October 17, 2005 

Chapter 1 - 18

A Responsibility to Secure Your Systems 
What do you 
accomplish with a 
security policy? 
 Confidentiality
 Integrity
 Availability 
Effective law enforcement in the world we live in today is nearly impossible without 
the use of computer systems and computer networks. With the advent of mobile 
computing, officers can conduct business from the patrol car, accessing information 
from computer-aided dispatch systems; querying numerous state, local, and federal 
databases (i.e., regional law enforcement information systems, the National Crime 
Information Center [NCIC], National Law Enforcement Telecommunications System 
[Nlets], and terrorism watch lists); filing incident and other reports directly from 
the field; and communicating directly in real time with supervisors, peers, and other 
first responders. Moreover, agency internal IT systems such as records management 
systems (RMS) capture, maintain, and analyze all police agency and incident-
related event information, which allows the tracking and managing of criminal and 
noncriminal events, investigations, and personnel information. 
Original Tech Guide Icon, Page 252
As the original Law Enforcement Tech Guide noted, Indeed, records management 
systems of the 21st century have become a key asset to effective policing, offering 
robust analytical tools, the ability to seamlessly share information, develop complex 
linkages between myriad data and information and assist in effective management 
strategies. The police RMS is a key component to informed and intelligent decision-
making and the basis for sound integrated justice information systems. 
Jacqueline Wagner, 
chair, Institute of 
Internal Auditors 
International, 
and General 
Motors general 
auditor: Effective 
information security 
must be pervasive. 
A security or 
controls group no 
longer owns the 
task. Security is 
everyones jobit 
must be broad and 
touch every cubicle 
and office. 
Clearly, to be so robust, police systems contain sensitive records, documents, data, 
information, and files related to persons (victims, witnesses, suspects), vehicles, 
incidents, arrests, warrants, accidents, citations, field interviews, civil process paper 
service, gun registration investigations, property, and evidence, to name a few. This 
information can be captured and stored in a variety of forms, including data, voice, 
and images. Information stored in law enforcement information systems is, obviously, 
sensitive and often confidential and may be subject to many laws, policies, and 
regulations regarding its collection, use, storage, disposal, and sharing. 
Law enforcement systems, like many other organizational IT systems, are among 
the most valuable assets of any agency. At the federal level, the U.S. Office of 
Management and Budget (OMB) has promulgated a policy that requires each federal 
agency to implement and maintain a program to adequately secure its information 
assets.2 In addition, each agency must have programs that: 
 Assure that systems and applications operate effectively and provide 
appropriate confidentiality, integrity, and availability. 
2 Federal Information Technology Security Assessment Framework, November 2000, included as part 
of NIST Special Publication 800-26, Security Self-Assessment Guide for Information Technology Systems, 
November 2001. 

Information Systems Security 19

According to 
Report to the 
President, Cyber 
Security: A Crisis 
of Prioritization, 
Presidents 
Information 
technology 
Advisory 
committee, 
executive office 
of the President 
of the united 
States (pp. 10-11, 
February 2005): 
The Computer 
Emergency 
Response Team 
Coordination 
Center (CERT/ 
CC) at Carnegie 
Mellon University 
reports that 3,780 
new electronic 
vulnerabilities were 
published in 2004, 
more than a 20-fold 
increase from 
1995. 
 Protect system data commensurate with the level of risk and magnitude of 
harm resulting from loss, misuse, unauthorized access, or modification of 
those data. 
These security goals are valid not only for agencies within the Federal Government, 
but any state or local government entity. Law enforcement executives have a fiduciary 
responsibility to ensure that their automated information systems and networks are 
protected. They must also ensure that appropriate persons are assigned responsibility 
for securing those systems and that they exercise due care in the performance of 
their duties. Thus, a commitment to staff training on security issues and your 
organizations security policies is key. Training will give staff the background they 
need to make informed decisions about system security to successfully avoid risks 
and/or mitigate those risks to acceptable levels. Ultimately, senior management, 
as the owners of the system, bear the responsibility for all the risks inherent in the 
operation of your agencys IT systems. 
What can happen when reasonable and effective security practices are not mandated 
by senior management and followed through by an agency? Lets look at a couple of 
examples of what can happen. 
Example 1: Audit identifies major security vulnerability for a state agency web site; site 
closed for business. In one state, the Department of Motor Vehicles developed and 
implemented a web-based vehicle registration renewal system in 2000. The system 
gave citizens the ability to renew their motor vehicle license tabs and plates over 
the Internet. According to the report, citizens could pay their registration renewal 
taxes from their home. The state web site was a great success: Revenue related to the 
registration renewals and use of the web-based system increased from $6.6 million 
in FY2001 to $30.5 million in FY2004. However, an audit conducted in 2005 found 
major security vulnerabilities and ultimately concluded that failure by the agency to 
carefully plan for and prevent tampering with the data offered by the web site meant 
that it would have to be shut down. Indeed, the audit report contents read: 
Key Conclusion 
Serious security weaknesses have exposed the web-based Vehicle Registration Renewal 
System and citizens private data to an unacceptable risk of tampering, disruption, 
and misuse. Until significant security enhancements are made, the system should not 
be used to conduct business. 
Findings 
 The department did not implement an effective security program. 
 Computer programs developed by the Driver and Vehicle Services Division 
contained security flaws. 

Chapter 1 - 20

 Poorly configured wireless access devices provided a way to bypass the 
departments firewall.
 Sensitive customer data and critical system components were not
properly protected.
 The department did not promptly perform important system
maintenance procedures.
 The department did not adequately monitor its systems. 
Why arent there 
more published 
horror stories 
on security? The 
answer is simple. 
Most organizations 
or agencies do 
not want their 
name up in lights 
when they have 
failed to protect 
systems or data, for 
obvious reasons. 
The organizations 
usually want to 
clean up the mess 
quickly, get the 
problem fixed, 
and move on. The 
sooner the problem 
gets off the radar 
screen, the better 
everyone feels. 
Example 2: Employee error causes a security failure at a large state university. The 
incident involved open Internet access to about 20 documents that contained student 
names and social security numbers. When the university finally looked into the 
matter, they determined that a university staff member had backed up these files 
on the university web server. While the staff member had legitimate access to these 
documents, they were unknowingly saved to the web server. Because the university 
did not enforce a periodic review of its IT systems, this problem went undetected for 
about 2 years. 
What Is a Security Policy? 
A security policy is a documentor an electronic filethat spells out specific rules 
and adds structure to the organizations procedures. It gives your agency staff 
guidance regarding how they should act and respond to given events or situations. 
Some general facts about information security policy development you should 
know before you start: Policies ultimately must be: 
Security Policy: A 
written statement 
that directs the 
behavior of one or 
more individuals 
and is designed to 
reduce or eliminate 
a specific risk, 
or set of risks, 
incurred by the 
operation of an IT 
system. 
1. Implementable by your agency. Writing a thorough and concise policy that no 
one can hope to put into practice is of no use to you or your agency. Analyzing 
the chosen controls, as well as their implementation and management, should 
clearly indicate whether the resulting policy will be reasonable. 
2. Enforceable. Any written policy must have mechanisms that will control its 
enforcement, whether that is a management mechanism such as review and 
oversight or an automated function of a particular system. 
3. Responsible. The policy must clearly define who is responsible for the 
implementation of the policy and must consistently ensure that the 
responsibility is aptly handled.
4. Documented. The policy must be formally documented, distributed, and 
understood by all affected personnel within the agency. 
Security policies and their development make for interesting discussion, but unless 
you have gone through the process, few know what actually goes into creating a 
policy and, more important, why they are useful. Many believe that if they could just 

Information Systems Security 21
 
adopt an existing policy, they could solve their security needs. The problem with this 
approach is that security is actually a process, and security policies are specific to an 
organization, derived from many factors, and used for many different reasons. 
Effective IT
security: the 
state where 
recognized IT 
security risks have 
been reduced, by 
means of security 
procedures, to 
a level that is 
acceptable to 
management and 
monitored on an 
ongoing basis. 
Developing effective information security policies for a law enforcement agency is the 
product of a comprehensive risk-management effort, which includes assessing the 
risk to the organization with respect to its technology implementation, developing 
ways to mitigate that risk, and evaluating whether policies and procedures put in 
place to reduce the risk are effective. 
A security policy represents the distillation of many activities, including: 
 A detailed understanding of the current IT environment and any existing 
security policies and procedures 
 An assessment of risk and system vulnerabilities associated with that 
environment
 Priorities based on identified risks 
 Mitigation strategies adopted by management 
 Implementation of the mitigation strategies 
 Ongoing evaluation of the effectiveness of the strategies 
 Creating the written security policy 
 Revising the strategies and rewriting the policies when needed. 
Stop Sign Icon
Just because a 
security policy 
looks simple does 
not mean that 
time or effort to 
develop the policy 
was either easy 
or quick. The real 
issue is if the policy 
accomplishes 
managements goal 
of reducing risk to 
an acceptable level. 
Simply put, security policies are developed as a part of a comprehensive risk 
management process. If you do not have policies in place, you need to start with both 
a self-assessment and a risk assessment. After fully understanding your system and its 
risks, you can then successfully craft policies to manage those risks. Once the policies 
are in place, they become the basis for the actual control mechanisms that will reduce 
or mitigate your IT system risk. 
Now, there are some exceptions to the notion that you must know the risk before you 
can develop a policy. You will be required to adhere to some federal, state, and local 
laws, rules, and ordinances regardless of your assessment of risk. For example: 
States accessing NCIC must adhere to the CJIS Security Policy issued by the FBIs 
Criminal Justice Information Services (CJIS) Division. (In addition, agencies 
accessing any criminal justice information system governed by the CJIS Security 
Policy must be in compliance with Federal Information Processing Standards 
[FIPS] for all procurements after September 30, 2005.) 

Chapter 1 22
Stop Sign Icon
This Tech 
Guide does not 
specifically deal 
with state or local 
compliance issues 
that may affect 
your agency. you 
will need to know 
your responsibility 
in complying with 
any or all the laws 
or regulations 
that govern your 
agency. 
Federal regulations governing the Health Insurance Portability and 
Accountability Act (HIPAA)3 may apply to certain records maintained by state 
and local government agencies. 
Federal regulations regarding Child Protective Services may apply to state and 
local agencies. 
Ultimately, your security policies will allow your agency to: 
 Control and reduce its exposure to risks, vulnerabilities, and compromise 
of your IT systems and their data to levels you deem acceptable, or that are 
mandated by some overarching law or policy. 
 Define what outcomes need to be measured so that you can continuously assess 
the effectiveness and appropriateness of your security policies. 
Lets take a quick look at the common risk factors in a law enforcement IT system and 
how security policies mitigate these risks. 
What Are the Risk Factors to an IT System? 
Risk may come from a variety of sources both internal and external. Generally threats 
to systems and data security come from these sources: 
 The system itself 
Computer systems, because of their design, may have a variety of inherent 
vulnerabilities. For example, a system may use an unencrypted database 
and have a default password length that is inappropriate (i.e., too short or 
uncomplicated and therefore easier for a hacker or some other malicious 
attacker to crack) for the kind of data being protected. We have all experienced 
security breaches inherent in mainstream products and operating systems that 
require us to regularly download system fixes or patches from the Internet 
when a vulnerability is exposed (think of the viruses that are rapidly spread 
over the Internet via e-mail). 
 How the system is used 
Until you investigate how a system is used, you will not know what additional 
exposures may be present. Often, the system itself may be secure, but methods 
of using the system create vulnerabilities. For example, if an IT department 
backs up an RMS before it is encrypted, then anyone who can access the backup 
tape could access any data on the tape. This exposure would be completely 
outside of the normal operation of the system. 
A security policy 
is essentially a 
distillation of any 
number of risk 
factors and the 
strategy for their 
resolution. 
3 Public Law 104-191. 

Information Systems Security 23 

Some information security experts believe as much as 80% of security problems 
stem from lack of understanding or carelessness, not direct attack. Examples like the 
I Love You virus (which infected only those who opened both an unexpected message 
and its attachment), sloppy administration and useeven sharingof passwords, 
and leaving computers logged on and unattended are dangerous, yet common 
examples of the need for greater security awareness. 
 Charles Le Grand, Information Security Governance, 
in ITAUDIT (vol. 4, Feb. 15, 2001)4 
 Peopleintentionally and unintentionally 
Effectively 
mitigating the 
insider threat 
requires policies, 
practices, and 
continued training. 
The National 
Strategy to Secure 
Cyberspace, p. 40, 
february 2003, 
Presidents critical 
Infrastructure 
Protection Board 
People are often the weakest link in the security chain, whether they mean to 
be or not. Clearly you must assess your vulnerability to attack by malicious 
hackers, criminals, and/or disgruntled individuals or employees. That scenario 
certainly presents specific types of risks. 
People also pose a great risk when they inadvertently misuse a system or they 
are not educated on proper system usage. People often compromise security 
simply because of human nature. If you have adopted a password policy that 
requires long and complicated passwords, for example, do not be surprised if 
users write them on a sticky note and put it under their keyboard. If you require 
burdensome paperwork to move backup tapes around, people may simply stop 
using the system because they just want to get their job done and move on to 
what they consider to be more important tasks. Or, as in the earlier example at 
the university, the staff member inadvertently backed up sensitive data onto 
a web server that allowed public access to the documents via the World Wide 
Web. It is not that there is malicious intent, necessarily, in these scenarios, but 
rather the failure of individuals to understand that their actions and/or use of 
the system could compromise the system and/or its confidential data. 
 Natural disasters 
Certainly your systemlike any other agency assetscould be damaged, 
entirely lost, or compromised during a flood, fire, earthquake, or other
natural disaster.
4 Available at http://www.theiia.org/itaudit/index.cfm?act=ITAudit.archive&fid=132. 

Chapter 1 24
 
 Not knowing and/or not meeting your mandated responsibilities 
You could jeopardize your system and expose your agency to liability if you are 
not aware of or have not complied with existing legislation, laws, policies, and 
other regulations relating to the secure operation of your system and/or those 
that interact with it. 
Any number of laws, such as the Computer Security Act of 1987 (Public 
Law 100-235) or the Federal Information Security Management Act of 2002 
(FISMA), may affect how you protect your data because these laws create 
minimum acceptable security practices. The Computer Security Act of 1987 
provided for the establishment of standards for improving security and privacy 
of information on federal systems. It also assigned to NIST (then the National 
Bureau of Standards) the responsibility to establish standards and guidelines 
for federal computer systems. FISMA updates much of the 1987 act and in part 
states:  provide effective governmentwide management and oversight of 
the related information security risks, including coordination of information 
security efforts throughout the civilian, national security, and law 
enforcement communities . 5 
Your state, county, or city may have additional legislation and/or policies that 
may affect you. In addition, users of the FBIs CJIS will need to adhere to the 
latest CJIS security policy. Failure to adhere to these existing laws, regulations, 
and policies could leave your systems at significant risk and you and your 
agency in a position of liability. 
 Limited capacity to address IT security risks 
Lets face it, many organizations are limited in their ability to adequately 
address security risks that may face them. In addition, sometimes managers 
must decide that they can only mitigate a risk to a certain extent, which may 
stop short of the highest possible levels of security. Perhaps implementing 
higher security levels are just too costly or the agency lacks the expertise to 
properly implement and manage the activities to secure a system at that level. 
That means that the agency assumes a level of risk, simply by knowing that the 
likelihood exists that something could occur based on that decision. 
5 44 USC 3541. 

Information Systems Security 25
 
Evaluating Risk Is Key to Developing Security 
Policies 
Assessing risk under these broad categories will provide management the information 
it needs to determine the extent of potential threats to and risks associated with a 
specific IT system. Understanding, analyzing, assessing, prioritizing, and mitigating 
risk becomes the foundation for developing an agencys security policies. The rest 
of this guide, you will find, focuses heavily on activities surrounding this analysis of 
risk. Once an agency evaluates the information developed during the risk-assessment 
process and prioritizes the identified risks in order of their importance, it can then 
develop specific procedures to address the risk. At the end of this process, the agency 
will balance the most appropriate procedures for implementation that will reduce (or 
mitigate) risks to an acceptable level for the agency. 
A key component of a robust security program is implementing a continuous process 
to evaluate the effectiveness of the security policy. For IT systems, the only constant 
in the system is that it will change. Consequently, as changes are made to the system, 
new risks will be discovered and old risks may go away. The agency must continually 
evaluate and assess the effectiveness of the security procedures to ensure the level of 
risk is still within the acceptable range by management. 
How Security Policies Control Risk 
It is impossible or impractical to completely eliminate all risk; therefore, developing 
risk mitigation strategies, and the resulting policy, seeks to find the security 
procedures that do the following: 
 Minimize the total costs for the agency 
 Are the most appropriate to reduce agency risks to an acceptable level 
 Create the least adverse impact on the agency. 
If security policies are well-thought-out, implemented properly, and monitored for 
effectiveness, then management will have successfully contemplated: 
 The goals of the organization, how technology supports them, and how security 
ensures their safety 
 The security exposures to the agency and how established procedures reduce 
risk levels 
 Requirements of existing legislation, agreements, or other policies that dictate 
the level of security required for the system 
 That deviations from the expected risk levels will be detected 
 That the cost of the security is within bounds established by management. 

Chapter 1 26
 
Given what is involved in assessing risk, making decisions about acceptable levels 
of risk, and instituting organizational policies to address the risk, it should be clear 
that law enforcement managers play a key role in developing, implementing, and 
maintaining IT security policies. So lets get started! 
The question is no longer can we afford security, but can we afford to do business 
without it? 
University of Georgia, 
Office of the Chief Information Security Officer6 
6 Source: www.infosec.uga.edu/ciso/quotes.php. 

A successful security program starts with the senior 
management of the institution empowering a 
Security Officer and flows down through the security 
team members . 
University of Georgia, 
Office of the Chief Information Security Officer 

Chapter 2: 
Organize and Charge the 
Security Policy Development 
Team 

What 
An inclusive and representative team that will be responsible for all aspects of security 
policy development, implementation, and evaluation. 
Why
To ensure that the right people are involved to perform systems analysis, identify risk, 
and make security decisions. 
Who 
The policy development team consists of a variety of stakeholders within the 
organization from the chief/sheriff to managers, to users and line staff. 
When 
Now! Establishing the security policy development team must be the initial task taken 
on by executive managers involved in the project. 

Original Tech Guide Icon, Page 23
Projects, like police organizations, require structure and disciplined rules if they 
are to be successful. The decision-making structure (in this case, the Security Policy 
Development Team) defines the chain of command, documenting the roles and 
responsibilities of the various people responsible for project actions. 
It is important to include representatives of the various stakeholder groups within the 
agency not only for buy-in to the initiative, but also because each representative will 
bring his or her knowledge and expertise of some specific aspect of the information 
technology (IT) systems that will be critical in developing the security policies. 
A security policy development initiative begins like all other IT efforts. It requires a 
sound decision-making structure, an effective leader, and the development of a 
solid plan. 

Chapter 2 30 
Standards of Due Care 
Senior management, under the standard of due care and ultimate responsibility 
for mission accomplishment, must ensure that the necessary resources are effectively 
applied to develop the capabilities needed to accomplish the mission. Management 
must also assess and incorporate the results of the risk-assessment activity into their 
decision making process. An effective risk management program that assesses and 
mitigates IT-related mission risks requires the support and involvement of senior 
management. 
 NIST Special Publication 800-30, 
Risk Management Guide for Information Technology Systems 

Step 1
Executive Sponsor Icon
Get Senior Leadership to the Table 
Creating effective information security policies requires the leadership and 
involvement of the agencys senior management. Managers are responsible for 
the following: 
 Providing the leadership and accountability for your agencys security 
policy development 
 Understanding the information security process and how it relates to 
your agency 
 Allocating resources to security policy development (human and financial) 
 Establishing acceptable risk levels for your organization based on 
analysis conducted 
 Creating the security policies 
 Reviewing, approving, and instituting a program to ensure that the security 
policies remain effective. 
Management support in the security process is critical to its success for the reasons 
noted above because most IT systems cross organizational boundaries. It is only with 
managements overarching support that rational security policies can be adopted and 
implemented for the entire organization. Management involvement will also help 
resolve any intra- and/or interagency issues that may develop. 

Organize and Charge the Security Policy Development Team 31
 
Step 2 
Identify Stakeholders 
Access to the 
National Crime 
Information Center 
(NCIC) and criminal 
justice information 
systems are 
examples of 
intangible assets for 
a law enforcement 
organization. 
Maintenance 
of these rights 
necessitates 
conformance to 
a certain set of 
policies set by the 
FBI. Failure to meet 
and maintain these 
standards may 
result in revoking 
access rights to 
NCIC and CJIS. 
Identifying stakeholders and obtaining their input and support during your agencys 
efforts to develop and implement effective IT security policies is also critical 
to the success of your initiative. Stakeholders are individuals who use, access, 
manage, and/or are responsible in some way for the security of your networks and 
information systems. Remember that some stakeholders can be external to 
your organization. Each stakeholder will have different needs and points of view 
depending on the security interests of his or her role and position within the agency. 
When you begin this effort, a list of obvious stakeholders will come to mind. This 
initial group usually consists of people from your own agency who will be affected 
by the undertaking: senior management, system owners, administrators, and user 
groups. There can also be other persons or groups who should be involved because 
they process or access data from the IT systems. These stakeholders could be other 
agencies, persons, or positions that are in some way linked to the system or its data by 
virtue of its operation, legislation, regulations, and/or policies. Your project manager 
needs to identify and help create this stakeholder team. The success of the security 
initiative can often rest on having the right people selected for this team! 
A good way to identify some less-than-obvious stakeholders is to start by asking a 
series of abstract questions. Some of the questions you may want to ask are: 
 Who are the unrepresented constituencies? 
 Who are the representatives of those likely to be affected by any
changes implemented?
 Who can make the effort more effective through his or her participation? 
 Who can make it less effective by his or her nonparticipation? 
 Who might outright oppose the project? (This could include individuals within 
or outside the organization who may mobilize against the project.) 
 Who can contribute financial and technical resources? 
 Whose behavior has to change for the effort to succeed? 
Note 
Remember, governance and decision-making structures can change as you dive 
deeper into your project. Along the way, you will likely discover other parties who have 
access to your systems and/or data or are in some way affected by these systems. As 
you identify these parties during the process, you need to analyze whether they may 
need to become part of your Security Policy Development Team. 

Chapter 2 32

Anyone within your agency is potentially an information system security stakeholder. 
Some positions, however, have a greater stake in IT security than others, such as: 
1. Agency executive. 
2. Head of major agency divisions, such as Investigations, Field Services, Records, 
and Dispatch. 
3. Internal IT staff. 
4. External IT staff. 
5. City/county/state IT manager. 
6. External user group. 
7. Information-sharing partners, such as the courts, prosecutor, and probation. 
Because of the potential effect the stakeholders have on the initiative, it is essential 
to establish a representative stakeholder team. It is only when you achieve stakeholder 
buy-in that your project can create effective security controls and have a reasonable 
expectation that they will be completely implemented. 
Determining an appropriate group to serve in this capacity is also a balance. You need 
enough participants to achieve solid and comprehensive representation, but not so 
many that the group becomes unwieldy. We often suggest that working groups consist 
of eight or fewer individuals. Otherwise, scheduling meetings, having successful 
working sessions, and other project activities become just too difficult to orchestrate. 
Keep in mind that you can always solicit broader input from more individuals through 
a variety of methods, such as surveys, forming ad hoc groups to focus on an issue, or 
holding informal meetings. 
Step 3 
Original Tech Guide Icon, page 43
Assign a Project Manager 
Not sure of the qualifications of a good project manager? See Chapter 2 of the 
original Law Enforcement Tech Guide for guidance on this important task. 
Depending on the size, scope, and scale of your security policy initiative (are you 
developing policies for the entire agencys IT resources, or are you focusing on a 
specific, smaller system?) you may need to assign a full-time project manager. For 
the smaller undertaking, you most likely will be able to assign someone within 
the organization to take the lead and to be responsible for all aspects of project 
management: meeting deadlines, communicating with all affected groups, project 
documentation, Steering Committee liaison, etc. (chief or sheriff: make sure you give 
them the time they need to do this!) 

Organize and Charge the Security Policy Development Team 33 
Original Tech Guide Icon, page 37
For a more 
comprehensive 
discussion of 
outsourcing project 
staff support and 
how to determine 
if its right for you, 
consult the original 
Law Enforcement 
Tech Guide. 
In the case of a more expansive initiative, a single individual ought to be dedicated 
full-time until the security policies and evaluation measures are developed and 
finalized. A project manager can come from within the organization, or you may want 
to outsource the responsibility for leading the security policy development effort. 
A project manager for a security initiative should have a solid combination of security 
and technical skills and project management experience. This is necessary because of 
the wide range of issues that arise in an effort of this type. The project manager also 
needs to have access to the Steering Committee and chief/sheriff on a regular basis to 
keep them informed about progress, status, challenges, and obstacles. 
Step 
Create a Governance Structure with Roles and Responsibilities 
The stakeholders that you have identified have differing roles and responsibilities. 
There are many ways to configure a governance structure, but here is a model we 
recommend that seems to work for most agencies, regardless of their size (Figure 2): 
Too much 
governance? 
you may be looking 
at this governance 
structure and 
thinking, Wow, 
this looks just like 
the structure we 
already have in 
place for broad 
IT planning and 
implementation. 
If so, then good 
for you, and we 
suggest that you 
incorporate this 
structure within 
that governing 
body. Indeed, it 
would be best if the 
IT Security Policy 
Development Team 
was always a core 
part of overall IT 
governance within 
a jurisdiction or 
organization. 

Steering Committee
Chief/Sheriff 
Senior management 
 Ultimate decision-making authority 
 Provides leadership/accountability 
 Determines risk tolerance 
 Adopts security policies 
 Adopts charter 
Security Working Group
System owners, users, IT staff, and other 
stakeholders 
 Analyzes current environment 
 Identifies security risks 
Project Manager
Individual responsible for all project-
related tasks and deliverables 
 Directs Security Working Group 
 Informs Steering Committee 

Figure 2: Security Policy development team 

Chapter 2 34 
Stop Sign Icon
Your initial attack 
on this effort will be 
very active with the 
Steering Committee 
and the Security 
Working Group. 
Be aware that the 
Steering Committee 
should never 
cease to exist. Its 
continued presence 
helps to ensure 
that you maintain 
the security 
development 
process. Having 
strong security 
policies is a 
long-term project. 
Once you move 
from the active 
state of assessing 
and improving 
your security, you 
enter a long-term 
maintenance mode. 
Steering Committee 
The Steering Committee needs to include the chief or sheriff, and any other members 
of senior management within the organization. These folks will assign and commit 
staff within the department to participate in this initiative. Their most important 
role will be to constantly and consistently provide guidance and oversight to the 
effort. Ultimately, they will have the critical task of reviewing the Security Working 
Groups project deliverables, making determinations about how the organization will 
deal with risks and vulnerabilities to its IT assets, and settling on the policies to help 
protect them. When they make these decisions, they will be making them in a fashion 
that supports the organizations business mission and objectives, and that considers 
the agencys budget and resources. 
Project Manager 
This is the individual who serves as the ringleader for the entire security effort and 
is the go-to individual for all related information. At the direction of the Steering 
Committee and working in conjunction with the Security Working Group, the project 
manager makes sure that project management best practices are followed for security 
policy development. This individual will make sure that the effort is properly scoped; 
deadlines and milestones plotted and met; deliverables remain on schedule; all 
activities are documented, organized, and archived; and constantly communicates 
with all members of the team and other interested parties concerning the status of 
the security effort. 
The Steering Committee must empower the project manager and any other staff who 
are engaged in this effort with the resources, training, and guidance they need for 
its success. 
Security Working Group 
The Security Working Group is where all of the real action takes place. This group 
assists in all of the assessment and analysis activities regarding existing IT systems 
and their current security policies. The group identifies risks and vulnerabilities 
and potential procedures to control them that are then presented to the Steering 
Committee for resolution. This group will understand all aspects of the current IT 
security environment and make recommendations for how it can be improved. Its 
work directly influences the decisions made by the Steering Committee. 
The Security Working Group consists of those who know the day-to-day operations 
of technology, who use it consistently, who are managing the agencys IT systems, or 
who otherwise are affected by the agencys IT. 

Organize and Charge the Security Policy Development Team 35 
Step 5
Original Tech Guide Icon, Page 15
Review Your Agency Mission and Objectives 
As asserted in the original Law Enforcement Tech Guide: IT must support the strategic 
business mission, goals, and objectives of the law enforcement agency. Information 
technology can be an effective tool for any business to meet its overall strategic 
objectives. But first, those business objectives must be outlined in a strategic plan. 
Then, information systems can be designed to meet those business objectives. 
As you begin your security policy development initiative, go back and read your 
organizations business mission. Then review the IT strategic plan. Those documents 
will be critical to guiding your approach to systems security. 
Properly designed computer security enhances the ability of an organization to meet 
its objectives. In addition, it provides a basis to protect the valuable resources used by 
the organization. 
The following is an example of how important IT security is in meeting an 
organizations mission: 
In 1999, the Metropolitan Police Department in Washington, D.C., wrote that 
information technologymakes it easier for the MPDC to share information 
with the community quickly and effectively. As such, new information 
technology is a critical part of the MPDCs evolving strategy of community 
policing and crime prevention. 
From Information Technology and the MPDC: Moving Into the Next Century (p. 1) 
The departments focus on sharing information with the public means that MPDC 
plans to interact with and provide important information to the community so that 
it can be involved and make informed decisions. This statement clearly highlights 
the implications for securing confidential data (need to know, who is able to see what 
types of information), making sure the data are accurate (integrity), that the data are 
not compromised (secured), and that they are available to share. These considerations 
will drive many of the security policies adopted in such an organization. 
Sharing information in an agency gets more complicated when you begin to delve 
deeper into numerous agency objectives that deal with the complex aspects of 
policing, intelligence information systems, and first response. 

Chapter 2 36 
Step 6
Allocate Resources 
You will need to allocate time and resources (both human and financial) to develop 
and implement a security policy process. The first step is to make sure your staff has 
the time it needs to participate in this effort. Most individuals participating on the 
working group, in particular, are also responsible for their full-time duties; therefore, 
you must carve out time for them to work on the security initiative. 
Once new security policies are in place, implementing them may cost money, as will 
continually evaluating the effectiveness of those policies and developing new policies 
as they are needed. 
Step 7
Adopt a Methodology and Plan of Action 
You need to plot a course for how you will develop and implement your security 
policies. While there are many different methodologies to choose from, we suggest the 
following steps in IT security policy development that will form the basis for the rest 
of this guide. 
Phase I: Conduct a Self-Assessment. The activity your Security Policy Development 
Team will undertake is a thorough self-assessment of your existing IT system(s). The 
purpose of this assessment is to identify and catalog all the information you have 
regarding the IT system and its operation. When the assessment is complete, you will 
know what you are doing today to secure the system and your legal and contractual 
obligations for secure system operations. 
Phase II: Assess Security Risks. Next, you will examine the assessment information 
collected during Phase I, identify the security risks to the system and, together with 
management input, determine the agencys tolerance for each risk. 
Phase III: Develop a Mitigation Strategy through Security Controls and 
Procedures. In this phase, the team develops the security controls and/or procedures 
necessary to mitigate the risks identified in Phase II. The controls require technical 
skills of staff who are familiar with the IT system, and managers and supervisors who 
are familiar with the system workflow. Once the security controls are developed, they 
are implemented. 
Phase IV: Develop and Implement Measurements to Monitor the Effectiveness 
of the Security Controls. In this phase, the team develops and implements 
procedures to monitor the security controls to ensure they are effectively reducing IT 
security risks to the levels specified by management. This phase is your insurance 

Organize and Charge the Security Policy Development Team 37
 
policy that risk levels are maintained at the appropriate values. 
Once the work in Phases I through IV is complete, the Security Policy Development 
Team can now create the agencys IT security policies. Policies should be formulated 
based on an identified risk and the controls developed to mitigate that risk. When 
implemented, they can be assured of their success and properly measured. The 
developed policies following this formula will meet the risk levels that are acceptable 
to the agencys management. 
Original Tech Guide Icon
All of these phases need to be accomplished in a logical manner, and using 
project management best practices. See Chapters 9 through 11 of the original Law 
Enforcement Tech Guide for details on how to create a project timeline, scope, budget, 
and general processes to be followed. 
So, have we piqued your curiosity? Or have we scared you off? We hope the former! 
Let us give you a sneak preview of the entire security policy development process as 
applied to a probable scenario in a law enforcement agency. We will walk you through 
all the phases of security policy development here. Each phase is the basis for the rest 
of the detail in this Guide. Enjoy! 

Chapter 2 38 

Sample Security Policy Development and 
Implementation Scenario
Lets take a look at a sample law enforcement IT system scenario to help us 
understand what security policies are, how they are developed, and how they 
are used. The following scenario, as illustrated in Figure 3, is very simplified, 
but it will help to explain the basic security concepts.
The Security Project 
Image of Police Badge
A police department in a medium-sized city 
decides to purchase a records management system 
(RMS) to automate and standardize record-keeping 
activities for criminal investigations. Additionally, 
the mayor and city council have mandated that all 
city departments must use the citys IT department 
for all server-based applications. Accordingly, the 
RMS was purchased and installed on a city server 
for the exclusive use of the police department. (For this scenario, we are 
calling it the Anytown Police Department.) 
Phase I 
Conduct a Self-Assessment 
Phase I in the security policy development process is to conduct a self-assessment of the 
existing system to gather and identify detailed information about the agencys current 
system security environment. 
The Anytown Police Departments security policy team does this, and the information 
collected is used to inform Phase II of the process. 

Figure 3: Sample Security Policy development/Implementation Scenario 

Organize and Charge the Security Policy Development Team 39

Phase II 
Identify and Assess Risks 
Phase II involves using the data gathered in the self-assessment phase to identify security 
risks in the system, and then categorizing and quantifying these identified risks to 
determine the likelihood of the risk occurring, the severity of the risk, and the agencys 
tolerance for each risk (either to avoid the risk, assume it, mitigate it, or transfer it). During 
the risk assessment, the Anytown Police Departments security policy team identifies the 
following security issues: 
A. The database is not encrypted. 
B. The RMS is connected to the city network and there are no firewalls or other 
routing controls to limit connections to the case management server. 
C. The RMS requires passwords for access, but they can be any length of four 
characters or more. 
D. City employees are used as IT system support personnel. However, as a cost-
cutting option, the city also has contracted with a temp agency for part-time 
support personnel. 
For any risks that your agency determines must be mitigated, the security policy team then 
designs a risk mitigation strategy through the use of controls and procedures (Phase III). 
Phase III 
Develop Security Controls to Mitigate the Identified Risks 
Phase III involves developing security controls necessary to mitigate the risks identified in 
Phase II. The following controls were crafted by the Security Policy Development Team in 
response to the risks they identified: 
A. The department technical liaison officer should investigate the possibility of 
acquiring a software upgrade for the RMS that would encrypt the database. 
B. Limit access to the RMS server to department management and investigators. 
C. A password of at least eight characters in length will be required for access to the 
RMS. 
D. Because nondepartment personnel have potential access to criminal investigation 
data, all persons who have potential access must undergo an annual criminal 
background check. 
Most people would stop the security policy process at this point and declare the battle won. 
However, the only constant with IT systems is change. Thus, measurements must be put in 
place to ensure the controls are, and remain, effective (Phase IV). 

Figure 3, continued 

Chapter 2 40 

Phase IV 
Develop and Implement Security Measurements 
Phase IV involves developing and implementing measures to monitor the effectiveness of 
the security controls. The Anytown Police Departments policy team creates the following 
ongoing methods for measuring security policy effectiveness: 
A. The departments technical liaison officer verifies annually that the RMS software 
database is encrypted. The officer may require assistance from the IT system staff 
for this activity. The first check is done 1 week after the software upgrade is installed 
and is done independently of the software installation. A report is submitted to the 
chief annually. 
B. The technical liaison officer reviews the network connections to the RMS annually. 
With the assistance of the IT systems staff, router and firewall configurations are 
reviewed to verify that only department users can access the case management 
server over the city network. 
C. The technical liaison officer is directed to request a file of the encrypted RMS 
passwords annually. A dictionary-cracking program is run against the passwords 
to determine if any can be cracked. The first test of the password file is to occur 1 
month after the software has been modified to support the new password policy. A 
report of the number of cracked passwords is submitted to the chief. 
D. The departments personnel officer audits the IT system staff records annually 
to verify that all IT system personnel, both city employees and contractors, have 
undergone a criminal background check. The first audit is conducted 3 months after 
the city personnel policy is revised. A report of the results of this check is prepared 
and submitted to the chief. 
Write the Policies 
At this point, the agency leadership and Security Policy Development Team are ready to 
write the IT security policies, building on the work that has been accomplished in Phases 
I through IV. Anytown Police Department thus creates the following policies for each 
identified risk: 
A. All data related to criminal activity or investigations within the department must 
be encrypted. If encryption is not cost effective, the data must be under the direct 
control at all times of a sworn officer of the department. 
B. All network access to department servers containing confidential and/or criminal 
data shall be limited to authorized users. 
C. Access control to any department system containing classified and/or criminal data 
shall require a password of at least eight characters and shall contain at least one 
nonalphanumeric character. 
D. All nonsworn personnel having potential access to confidential or criminal data 
must undergo an annual criminal background check. 

Figure 3, continued 

Organize and Charge the Security Policy Development Team 41

Figure 4 illustrates the relationship among the identified risks, controls, measures, and 
policies in four scenarios. 

Risk:  The database is not encrypted. 
Control:  The department technical liaison officer should investigate the possibility of 
acquiring a software upgrade for the RMS that would encrypt the database. 
Measure:  The departments technical liaison officer verifies annually that the RMS 
software database is encrypted. The officer may require assistance from 
the IT system staff for this activity. The first check is done 1 week after 
the software upgrade is installed and is done independently of the software 
installation. A report is submitted to the chief annually. 
Policy:  All data related to criminal activity or investigations 
within the department must be encrypted. If encryption is not cost effective, the 
data must be under the direct control at all times of a sworn officer of the department. 

Risk: The RMS is connected to the city network and there are no firewalls or other routing
controls to limit connections to the case management server.
Control: Limit access to the RMS server to department management and investigators.
Measure: The technical liaison officer reviews the network connections to the RMS
annually. With the assistance of the IT systems staff, router and firewall 
configurations are reviewed to verify  that only department users can access 
the case management server over the city network.
Policy: All network access to department servers containing confidential 
and/or criminal data shall be limited to authorized users. 

Risk: The RMS requires passwords for access, but they can be any length of four 
characters or more.
Control: A password of at least eight characters in length will be required for 
access to the RMS. 
Monitor: The technical liaison officer is directed to request a file of the encrypted RMS 
passwords annually. A dictionary-cracking program is run against the passwords to determine if any can be 
cracked. The first test of the password file is to occur 1 month after the software has been modified to support 
the new password policy. A report of the number of cracked passwords is submitted to the chief. 
Policy: Access control to any department system containing classified and/or criminal data shall 
require a password of at least eight characters and shall contain at least one nonalphanumeric character. 

Risk: City employees are used as IT system support personnel. However, as a cost-cutting option, the
city also has contracted with a temp agency for part-time support personnel.
Control:  Because non-department personnel have potential access to criminal investigation data, all persons
who have potential access must undergo an annual criminal  background check. 
Measure: The departments personnel officer audits the IT system staff records annually to verify that all IT system
personnel, both city employees and contractors, have undergone a criminal  background check. The first audit is 
conducted 3 months after the revised city personnel policy is changed. A report of the results of this check is 
prepared and submitted to the chief. 
Policy: All nonsworn personnel having potential access to confidential or criminal data must undergo an annual 
criminal background check. 

Figure 4: relationship Among risks, controls, measures, and Policies 

Security needs to be built in from the startnot 
slapped on after the fact. 
Gene Spafford, Professor of Computer Sciences, 
Purdue University 

Chapter 3:
Phase IConduct a Security
Self-Assessment

What
Gather and identify detailed information about your agencys current (as-is) system(s)  
security environment in three categories: Management, Operational, and Technical. 
Why
Understanding the environment in which your system is currently operating, and the 
rules (or lack thereof ) governing its operation, maintenance, access, and security, will 
help you identify where the system may be subject to vulnerabilities. 
Who
Senior management, project managers, administrators, and users may be called upon  
by the Security Policy Development Team to contribute to gathering and organizing 
the self-assessment inventory for your agency. 
When 
The self-assessment inventory should be the first activity your security policy team 
undertakes and completes. Since this inventory process will take some time to 
accomplish properly, it is best if this phase of the security policy initiative is started 
promptly at the projects inception. (You need to hit the ground running.) 

Security self-assessment is a method by which your agency can understand where it is 
today in terms of providing security for information technology (IT) systems. Think 
of the assessment as an as-is of thestate of your organizations IT security. It is an 
exercise that will help you bring together any guidelines, rules, procedures, controls, 
and informal activities currently in place that impacts a specific IT systems security. 
In most state and local law enforcement agencies, there are many policies, procedures, 
and methods in place to secure IT, but generally they are not located in a single place, 
nor have they been rationally organized into a single document. Sometimes they are 
just things people in the organization know but that have never been written down. 
Conducting a self-assessment will help you bring together all those critical guidelines 
and methodologies to allow you to successfully explore your environment. 
The completed self-assessment informs all future phases of the security policy 
development process, and, in particular, forms the basis for successful risk assessment 
and security policy development. You can conduct a self-assessment of one system, 
many systems, or part of a system, depending on the scope of your project. 

Chapter 3 46

NIST Icon
Creating a comprehensive inventory of information about the management, 
operational, and technical environment of the system or systems is the crux of a self-
NIST assessment.7 As you will see, it involves collecting detailed data and information about 
each of these areas, which individualsboth inside and outside your organization 
are responsible for them, and any existing formal or informal rules, policies, and 
procedures governing each. 
It is best if your agency accomplishes this inventory itself because your staff: 
 Understand how your systems work 
 Are the most aware of the intricacies of the system 
 Are the most familiar with how the system is actually used 
 Will learn even more by handling the self-assessment internally. 
While there are 
a number of 
self-assessment 
guides or audit 
checklists available 
for a fee or free 
on the Internet, 
remember, these 
are just guides 
and no publication 
can provide your 
agency with an 
all-inclusive list of 
the security issues 
that you need to 
be aware of. It is 
managements 
responsibility to 
understand the 
current status of 
their IT systems 
and controls so 
they can make 
informed decisions 
to appropriately 
mitigate risks to an 
acceptable level. 
The Self-Assessment Process 
This process is really quite straightforwardit just requires time, research, legwork, 
and organization! Here are the steps we suggest you follow to complete this process: 
1. Identify which systems, single system, or part of a system for which you will be 
developing security policies. 
2. Assemble the appropriate participants for the process and hold a kickoff
meeting.
3. Gather relevant organizational data regarding the IT systems to be assessed that 
addresses management, operational, and technical system issues. 
4. Conduct the self-assessment by ranking the level to which the agency has 
developed, implemented, and evaluated policies, procedures, and controls 
regarding the management, operational, and technical components of the 
subject systems (and yes, we have a questionnaire you can use to guide you 
through this).8 
5. Compile the results of your self-assessment, which will become the basis for 
your agencys IT security risk assessment (detailed in Chapter 4). 
7 The key areas of the self-assessmentManagement, Operational, and Technicalare taken from 
the NIST Special Publication 800-26, Security Self-Assessment Guide for Information Technology Systems 
and Revision 1 of NIST SP 800-26, Guide for Information Security Program Assessments and System 
Reporting Form and NIST SP 800-53, Recommended Security Controls for Federal Information Systems. 
8 Refer to Appendix A for a description of this self-assessment questionnaire. Specific questions are 
listed beginning on page 126. 

Phase IConduct a Security Self-Assessment 47

Step 1 
Identify the Systems, Single System, or System Part 
for Which You Will Develop Security Policies 
Many law enforcement agencies do not have formal and clearly articulated security 
policies for their IT systems. If your agency falls into this category, we recommend you 
take an enterprise look at your IT holdings and develop policies governing all of them. 
Of course, this means much more work than, say, just looking at one system, but there 
is a danger that any policies or procedures (including those surrounding IT security) 
are only as good as the weakest link in the system. Thus, if you have comprehensive 
policies and procedures for one system, but not another, are you merely defeating 
your security goals in the long run? This becomes even more problematic if the 
systems are integrated. 
List the systems and/or locations that you initially want to include for your security 
self-assessment activities. As the self-assessment project progresses, you may discover 
that you need to add more systems/locations to your list as you discover how your 
system is used or how it is interconnected to other systems. (Note, if you add 
additional systems, it may also affect who will be part of the self-assessment team 
described in Step 2.) 
 For each location in your list, create a list of the IT systems that you want to 
assess. 
 For each system, create a list of people who understand the system, both 
technically and functionally.
Step 2 
Assemble the Appropriate Participants for the 
Process and Hold a Kickoff Meeting 
As discussed in Chapter 2 regarding assembling the Security Policy Development 
Team, it is important that key individuals not only participate in the self-assessment 
process, but also that they understand why conducting the self-assessment activity 
and doing it completely and accurately is so important. Take the time herenow 
that you have determined the scope of your projectto make sure you have the right 
people involved. 
We know that the executive sponsor of the agency must be involved, as well as top 
management whose divisions or units are affected by the system and policies you 
are developing. The project manager, as you already know, is also key to successful 
completion of your policies. At this time it is important that you make sure you 
also reassess the involvement of the following individuals or teams in your policy 
development team: 

Chapter 3 48
 Administrators: These are the actual administrators of the various parts 
of your system that will be assessed. This may be a single individual or 
several administrators of multiple systems. Each plays an integral role in the 
development, implementation, and maintenance of the system and, thus, an 
important part of the assessment process. 
 Data owners: Individuals who are responsible for the proper maintenance and 
care of the data that resides in a particular system are integral to this effort. 
They will understand the rules, policies, and regulations regarding capturing, 
maintaining, and disseminating the data stored in the IT systems. Because they 
are ultimately responsible for the data, they will be key to developing the right 
security policies. 
 System owners and users: System owners could include persons outside of 
the agency who actually own the hardware that contains your data. They may 
be part of the larger community government or an agency that by agreement 
stores your data. Including them in the process will be important to obtaining 
correct information during the assessment process. Users may be obvious 
their inclusion is always important for gaining acceptance. 
 Legal assistance/research: Your security policy team may need help in 
locating and assessing legislation, agreements, and/or agency policies that may 
affect the operation of the IT systems under review. If not legal counsel, your 
agency needs to assign someone the task of researching these 
important documents. 
 External system users/contributors and/or beneficiaries: Your staff 
may also need input from and access to external resources. Part of the self-
assessment process is to understand what data or operational links exist 
between the system being assessed and any other system, be it internal or 
external to your agency. 
Once you determine the individuals who will participate in the self-assessment, you 
should hold an initial meeting to discuss the process of self-assessment, including the 
following steps. 
Step 3 
Gather Organizational Data 
You must now gather a variety of relevant organizational data regarding the IT 
systems that will be assessed. In November 2001, the National Institute of Standards 
and Technology (NIST) laid out a methodology to facilitate the self-assessment 
process by organizing it into the three broad categories: Management, Operational, 
and Technical.9 We believe this remains one of the most appropriate, streamlined, 

9 This methodology appeared in NIST Special Publication 800-26, Security Self-Assessment Guide for 
Information Technology Systems. 

Phase IConduct a Security Self-Assessment 49

and straightforward approaches for state and local law enforcement agencies to 
organize information pertaining to their IT systems. The information gathered in 
these three categories will form the basis for the self-assessment process. 
Project Manager Icon
The project 
manager should be 
the point person 
and repository 
for all information 
collected during 
Step 3.
The best place to begin your data collection is by talking with the owners of the 
IT systems under review. These are the people who, among other things, may be 
responsible for funding the system, or responsible for the data in the system, or for 
the access to and use of the system. In addition, the actual users of the system can 
provide good information about the system as it relates to security. Throughout this 
process, you are trying to determine: 
1. How and where your IT systems are accessed. 
2. What are managements expectations of how the system is used? 
3. What are the legal or policy requirements that pertain to the system? 
4. How many people actually use or maintain the system? 
5. Where the system documentation is located, and how accurate is it? 
The self-
assessment 
process itself is 
not a 5-minute 
exercise! It will 
take some time 
to complete and 
it will require you 
to do quite a bit 
of research. your 
goal is to try to 
really understand 
your IT system so 
that ultimately all 
potential risks are 
discovered.
For your benefit, we have created a list of possible information sources that you 
should research and collect. As preparation for the self-assessment, you should gather 
and organize as much of the following information as possible. Obviously, each 
agency is different, so your agency may or may not have some of the sources listed 
below. If this is the case, you should try to locate other similar sources of information 
unique to your environment that will be helpful to your security activities. 
Here are your categories of information collection and why they are important: 
Management Information 
The Management category addresses how IT systems are managed, including 
identifying risks to the system. It includes questions about such issues as: 
 Risk Management: Whether the organization has a risk-management process 
in place and whether it takes steps to reduce and maintain the risks at an 
acceptable level. 
 Security Reviews: Whether the organization has implemented routine 
evaluations of and responses to identified system vulnerabilities.
 Lifecycle: Whether security policies and procedures development and 
maintenance is part of the technology lifecycle development process within the 
agency. (Meaning it is dynamic, not static.) 
 Certification and Accreditation: Normally reserved for federal agencies 
compliance for certifying their IT systems in accordance with NIST guidelines. 

Chapter 3 50

Stop Sign Icon
As we begin describing the information to collect, you will note it is voluminous. 
. It is in Microsoft Excel spreadsheet format and is described in 
more detail starting on page 61. 
We have created a tool to help facilitate the assessment process, downloadable at 
www.search.orgYou may also use Appendix A: Assessment worksheets and Questions 
from the SeArch Information Security Self- and risk-Assessment tool 
to help you through this chapter. 
However, many state and local agencies fall under these rules based on the data 
that they maintain according to federal programs (such as compliance with 
Health Insurance Portability and Accountability Act [HIPAA] regulations or 
Child Protective Services regulations). 
 System Security Plan: Does the agency maintain a formal security plan that 
includes the security requirements of the system(s), as well as procedures to 
fulfill those requirements? The plan should delineate individual responsibilities 
and expected behavior of all individuals who access, maintain, and otherwise 
interact with the system. 
Here are the types of organizational information you should collect to inform the 
management self-assessment. 
1. Controlling organizations. Identify and list all the controlling organizations 
of your agency, up to and including the federal level, if applicable. 
a. If you are a local police department, the first level outside your agency will 
probably be your city or county government. 
b. If you are working at the state level, you may not have a controlling 
organization if the head of your agency already reports to the governor or 
a state legislative committee; nevertheless, your agency will be responsible 
to these entities in a similar mannerwith often more pressure due to the 
political sensitivity. 
c. The federal level becomes important if your agency either uses services from 
or receives funding from a federal agency. 
The list you develop should contain the following information at the minimum: 
 Agency name. 
 Relationship to your organization. 
 The areas of control related to your organization. What oversight does this 
agency exercise with respect to your organization? 

Phase IConduct a Security Self-Assessment 51

Original Tech Guide Icon, Page 52
 The first-level contacts within those agencies that your people would 
normally contact. These are the go-to people in the other agency.
2. Business/mission statement(s) for your agency. These should be easily 
located in your agencys strategic plan. 
3. Audit reports. These documents will potentially provide you with a lot of good 
information related to your organization and IT systems. Specifically, you need 
to identify and collect any audit reports created that relate to: 
a. Your agencythe audit reports may have been created for any purpose 
(financial, security, or otherwise). 
b. The IT infrastructurethe audit reports may have been created for the data 
network, physical security, emergency preparedness, and so forth. 
4. Policies/procedures. Collect existing policies, procedures, memoranda, and 
so forth, related to IT systems control and/or IT security in particular and or 
any other compliance requirements based on law or agreement (for example, 
the FBI Criminal Justice Information Services [CJIS] Divisions CJIS Security 
Policy, HIPAA, Sarbanes-Oxley Act,10 and so forth). 
5. Building design and construction details. Collect these for any 
location housing IT systems or users of IT systems that are part of this self-
assessment activity. 
6. Project-related documents. Obtain, if they exist, the project plans, project 
specifications, proposals, requests for proposals (RFPs), and other documents 
for all IT systems that are part of this self-assessment. 
7. Existing agreements. Do any agreements made between your department and 
any other entities relate to the IT systems that are part of this self-assessment? 
Some examples of such agreements may be the following: 
a. Service-level agreementsthese agreements typically are between the 
service provider (usually an IT department, which may be part of another 
agency) and your organization. 
b. Availability agreementsthese typically would be made with your end 
users to guarantee system availability. In addition, they may also cover their 
responsibilities to maintain security, confidentiality, and controlled access to 
the system. 
8. Position description and related correspondence. Identify the most senior 
person in your organization responsible for each IT system under review. 
a. Obtain a copy of his or her job description. 
b. Obtain any memos or letters of understanding addressed to this person that 
are related to the IT system under review. 
10 Public Law 107-204. 

Chapter 3 52

9. Responsible party information. Identify the organization that is responsible 
for maintaining the IT system. Gather the following information: 
a. If the IT system is a commercial product 
i. License agreement. 
ii. Support agreement. 
iii. Policies and procedures related to maintenance and support of the IT 
system. 
iv. Documentation of how the organization maintains system records 
regarding changes, modifications, and/or upgrades. 
b. If the system was developed in house (this may be the city or county IT 
department) 
i. System design documentation. 
ii. Copies of structured walk-throughs or other development documentation 
that was created when the system was built. 
iii. Maintenance logs. 
iv. Requests for system changes/modifications. 
10. Budget information. Obtain the initial and subsequent budget proposals and 
justifications for the IT system. Determine the financial justifications for the IT 
system. 
11. External information-sharing system information. Identify any other IT 
systems that either supply information to, or receive information from, the IT 
system under review. Obtain the same information for those systems as you are 
doing for this system. 
12. Business continuity plans. Does your agency have any business continuity 
plans? If so, obtain copies of these plans.
Operational Information 
The Operational category addresses security methods implemented and executed by 
people (as opposed to systems). Since people are usually the weakest link in the chain 
of security, this area is important to understand. Your employees and users of the IT 
systems must understand their jobs and how they both affect, and are responsible for, 
security. It is designed to answer questions about issues such as: 
 Personnel Security: How personnel interacts with the organizations 
computerized systems and the access and authorities they need (and use) to do 
their jobs. 
 Physical Security: How physical and environmental security measures have been 
taken to protect systems, buildings, and related supporting infrastructures 
against threats associated with their physical environment. 

Phase IConduct a Security Self-Assessment 53 

 Production, Input/Output Controls: There are many aspects to supporting general 
IT operations. This topic area discusses items such as whether or not you have 
a functioning user help desk, or your internal procedures for media handling, 
including their storage and destruction. 
 Contingency Planning: Whether the agency has contingency plans for disasters 
and other disruptions. It involves more than planning for a move off site after 
a disaster destroys a facility, but also how to keep an organizations critical 
functions operating in the event of any disruptions, large or small. 
 Hardware and Systems Software Maintenance: Whether and how the organization 
monitors the installation of, and updates to, hardware and software to ensure 
that the system functions as expected and that a historical record is maintained. 
 Data Integrity: How data are protected from accidental or malicious alteration 
or destruction and how the user is assured that the information meets 
expectations about its quality and integrity. 
 Documentation: Whether documentation of the hardware, software, policies, 
standards, procedures, and approvals related to the system are maintained and 
account for the systems security controls. Agencies should also make sure there 
are procedures for ensuring that the documentation is obtained 
and maintained. 
 Security Awareness, Training, and Education: People are a crucial factor in 
ensuring the security of computer systems and their valuable information 
resources. Security awareness, training, and education enhance security by 
improving awareness of the need to protect system resources. Additionally, 
training develops skills and knowledge so computer users can perform their 
jobs more securely. 
 Incident Response Capabilities: Whether an agency has plans for responding to 
computer security incidents. Such incidents are becoming more common and 
their impact far-reaching. 
Here are the types of organizational information you should collect to inform the 
operational self-assessment: 
1. Users. Compile a list of authorized persons who use, maintain, or otherwise 
interact with the IT system under review. 
a. Obtain a copy of the personnel policies related to the job performance of 
these individuals. 
b. Obtain job descriptions for these individuals. 
2. Personnel policies. Obtain a copy of the personnel policy for your 
organization and any other organization that provides support for the IT 
system under review.

Chapter 3 54

3. Administrator information. Identify the people who are responsible for 
controlling and/or administering the IT system under review. 
a. Request, if they exist, memos, procedures, or guides that are used in the 
administration of the IT system. 
b. If these individuals reside in other agencies, you need to obtain copies of 
their job descriptions and a copy of that agencys personnel policies. 
4. Maintenance and support documents. Identify the personnel (such as the 
system administrator or a specific subordinate of the system administrator) 
responsible for the maintenance/support of the IT system under review. 
a. Request, if they exist, any memos, procedures, or guides that are used in the 
maintenance/support of the IT system under review. 
b. If these persons reside in other agencies, then you need to obtain copies of 
their job descriptions and a copy of that agencys personnel policies. 
5. Physical security. Identify the agency and/or people responsible for the 
physical security of any location where the IT system is either used or resides. 
a. Obtain copies of any policies, memos, procedures, or guidelines that 
determine how physical security is established and maintained.
b. If the responsible agency is outside of your organization, then you need to 
obtain copies of its job descriptions for persons responsible for security and 
a copy of that agencys personnel policies. 
6. Building maintenance. Identify the agency and/or people responsible for the 
building maintenance and support at any location where the IT system under 
review is either used or resides. 
a. Obtain copies of any policies, memos, procedures, or guidelines that 
determine how this support is established and maintained.
b. If the responsible agency is outside of your organization, you need to obtain 
copies of the job descriptions of persons involved in supporting the physical 
plant and a copy of that agencys personnel policies. 
7. Disaster recovery plans. Determine if any external agencies maintain disaster 
recovery plans relating to the physical plant where your users and/or 
IT system reside. 
a. If they exist, obtain copies of these plans. 
b. Do these plans provide for backup power, utilities, air conditioning,
and so on?
8. Data security. Gather controls, policies, or procedures that have been 
developed that address data security. 
9. Contingency plans. If available, collect contingency plans that have been 
developed, such as your response plan to a natural disaster or other incident. 

Phase IConduct a Security Self-Assessment 55

10. Data quality/integrity documents. Determine if there are controls and/or 
audits that relate to data integrity. 
11. Training materials. If your organization has a training section, it should 
be tasked with security awareness training. Collect the training charter and 
training material related to security.
12. Incident response plans. If your organization has an incident response team, 
it may have plans for a response to an IT security breach. Obtain a copy of the 
charter and procedures. 
Technical Information 
The Technical category examines security controls that the computer system 
executes. Systems themselves can provide automated protection for unauthorized 
access or misuse, facilitate detection of security violations, and support security 
requirements for applications and data. Issues you will examine here include those 
pertaining to the following: 
 Identification and Authentication: A measure that prevents unauthorized people 
(or unauthorized processes) from entering an IT system. It requires that the 
system be able to identify and differentiate among users. 
 Logical Access Controls: The system-based mechanisms used to designate who or 
what is to have access to a specific system resource and the type of transactions 
and functions that are permitted. 
 Audit Trails: This activity maintains a record of system activity by system or 
application processes, as well as user activity. In conjunction with appropriate 
tools and procedures, audit trails can provide individual accountability, a 
means to reconstruct events, detect intrusions, and identify problems. 
Here are the types of organizational information you should collect to inform the 
technical portion of the self-assessment: 
1. Identify the system 
a. System name. 
b. Describe what the system is used for (give detail, at least one-half to one full 
page). 
c. Date first installed. 
d. Current release or version number. 
e. Major system components (create a written technical overview of the 
system). 
f. Person or persons responsible for maintaining the system. 
i. This group should maintain a list of system changes, updates, 
modifications, and maintenance. Collect copies of this information. 

Chapter 3 56

g. Location of the installed system. 
h. Record all system configuration parameters made during and subsequent 
to the systems installation. Identify, if possible, any justifications made 
for the selection of system configuration parameters. When computer 
systems are installed, certain configurations of the software are made at 
that time to enable the specific use of the system by the installing agency. 
System configurations could include who can access the system, what levels 
of security are required, and other system behavior. These parameters are 
configured to the individual agency workflow. 
2. Create a data flow diagram 
a. Identify input data, and its source and form. Input data are any data a user 
or another computer system provides as input to your system. 
b. Identify output data, where used, and in what form. Output data are 
information that is created by your system. 
c. Identify stored data within the system. Stored data are any data that your 
system stores for any length of time, i.e., historical data or databases. It is 
the long-term storage of input data. 
i. Where are the data stored? 
ii. Are the data backed up and, if so, where are the backups stored? 
3. Create a workflow diagram 
a. Identify all locations from which the system is accessed. 
b. Identify all individuals who access the system and how they relate to the data 
flow of the system. 
4. Authentication information. If the system requires authorization for use, 
identify the people responsible for administration. 
a. Obtain, if they exist, copies of policies or procedures this group uses to 
administer access to the system. 
b. Does this group have review policies relating to the administration activities? 
If so, obtain copies of the policies. 
5. System owners. Is any person or group considered to be the owner(s) of the 
system? If so, obtain a list of their expectations related to the operation of the 
system. 
At this point, you will have collected a large amount of information relating to the IT 
systems you are preparing to examine. Coalesce and organize this information so you 
can locate the various pieces easily. All the work you have done will be of great benefit 
as you begin the self-assessment process. 

Phase IConduct a Security Self-Assessment 57

Step 4
Conduct the Self-Assessment 
Now that you have gathered all of your management, organizational, and technical 
information, you are ready to answer a series of questions designed to help you assess 
the current state of your IT security. This process mainly consists of ranking the level 
to which the agency has developed, implemented, and evaluated policies, procedures, 
and controls regarding the security of the subject systems. 
Stop Sign Icon
A description 
and tour of the 
Assessment Tool 
begins on page 61. 
Specific questions that focus on management, operational, and technical issues 
related to the systems under review are designed to illustrate how your agency is 
currently dealing with the issue. You will find a comprehensive list of the key 
questions you will need to consider in Appendix A: Assessment Worksheets and 
Questions from the SEARCH IT Security Self- and Risk-Assessment Tool, which 
follows the NIST framework for this process. These questions are provided in 
four main categoriesManagement, Operational, Technical, and State and Local Law 
Enforcement-Specific IT Securitythat are further divided into the 18 subcategories 
listed on page 63. 
A Look at How You Will Answer the Key Assessment 
Questions Using Levels 
Before we begin, let us explain how the questions are posed in the Assessment Tool, 
and how your team will need to consider and answer those questions. We will use the 
first question in the Management category as our example (Figure 5). 
Management 
1. Risk Management 
1.1 Is risk periodically assessed? 
 Is the current system configuration documented, including links to other systems? 

Figure 5: First Question in management category in the Assessment tool 

Chapter 3 58

The Management category includes 61 questions that relate to the management 
of your systems (you should also feel free to add your own questions to the 
suggested list). These questions are divided into five distinct subcategories: 
1. Risk Management. 
2. Review of Security Controls. 
3. Lifecycle. 
4. Authorize Processing (Authentication and Certification). 
5. System Security Plan. 
Each subcategory contains the specific questions that your agency must answer to 
explore in detail how it is addressing the particular issue. 
The policy development team reviews the questions, consults the management-related 
data gathered as described earlier in this chapter, conducts additional research, if 
necessary, and then answers the questions using the SEARCH IT Security Self- and 
Risk-Assessment Tool. Each question must be answered by addressing five specific 
levels with a simple yes, no, partial, or not applicable (n/a) answer. Each of 
the five levels measures how mature the agency is in addressing a particular security 
issuesuch as the existence of a documented policy. See Figure 6 for a detailed 
description of the five levels. 

Phase IConduct a Security Self-Assessment 59

LEvEL 1: Documented Policy 
Does your agency have a formally documented and disseminated policy on that security control? 
Does the policy define 1) purpose and scope of the policy, 2) responsibilities required for its 
execution, and 3) compliance requirements and penalty specification? 

LEvEL 2: Documented Procedures 
Does your agency have formal, complete, and well-documented procedures for the policies 
defined at level 1? 
Do the procedures: 
 List the control areas and clearly state the agencys position? 
 Document their applicabilityclearly list when, where, how, to whom, and about what the 
procedure applies? 
 List the assignment of IT responsibilities and define explicit behavior? 
 Identify points of contact and where supplementary information can be found? (not applicable)

LEvEL 3: Implemented Procedures and Controls 
Have the procedures and controls been implemented? 
Are the following statements true? 
 Are the owners and users aware of the security policies and procedures? 
 Have the policies and procedures been formally adopted and the technical controls installed? 
 Is a security metrics program in place? (ongoing security compliance measurement) 
 Has management formally authorized the use of the system? 
 Have employee job descriptions been updated to include security responsibilities that the 
implemented controls require? 
 Have employees been trained on security procedures? 

LEvEL 4: Tested and Evaluated Procedures and Controls
Is a metrics program in place that routinely evaluates the adequacy and effectiveness of security 
policies, procedures, and controls? 
Are the following elements in place? 
 An effective program for evaluating the adequacy and effectiveness of security policies, 
procedures, and controls. 
 A mechanism for identifying vulnerabilities revealed by security incidents or security alerts. 
 A process for reporting significant security weaknesses and ensuring rapid and effective 
remedial action. 

LEvEL 5: Fully Integrated Procedures and Controls 
Does your agency have a fully operational, comprehensive security program that is an integral 
part of your agencys culture? 
Are the following statements true? 
 There is an active agencywide security program that achieves cost-effective security. 
 IT security is an integrated practice within the asset (IT system). 
 Security vulnerabilities are understood and managed. 
 Threats are continually reevaluated, and controls are adapted to a changing security 
environment. 
 Additional and/or more cost-effective security alternatives are identified as the need arises. 
 Costs and benefits of security are measured as precisely as practicable. 
 Status metrics for the security program are established and met.

Each Level must be answered with a Yes, No, Partial, or N/A (Not Applicable)
 
figure 6: Levels in SEARCH It Security Self- and risk-Assessment tool 

Chapter 3 60

So, using the example question shown in Figure 5, and addressing the five levels 
shown in Figure 6, our answers could look as follows (Figure 7): 
Management 
1. Risk Management 
1.1 Is risk periodically assessed?
  Is the current system configuration documented, including links to other systems? 
 Level 1Documented Policy: Yes 
(meaning there is a formal policy in place regarding keeping 
documentation of system configuration) 
 Level 2Documented Procedures: Yes 
(meaning there are procedures in place about how to enact 
the policy described in level 1).
 Level 3Implemented Procedures and Controls: Yes 
(meaning that owners and other users are aware of 
management-adopted policies and procedures, and are 
trained on their implementation) 
 Level 4Tested and Evaluated Procedures and Controls: No 
(the agency has not implemented a means for testing or 
evaluating the policies, procedures, and implementation 
strategies) 
 Level 5Fully Integrated Procedures and Controls: No 
(the agency has not reached a level of a full, comprehensive 
security program related to this particular issue) 

figure 7: Answers to first Question in management category 

Phase IConduct a Security Self-Assessment 61

The SEARCH IT Security Self- and Risk-
Assessment Tool: Easy to Use, Visible Results 
SEARCH Icon
Download this 
Assessment Tool 
spreadsheet at 
www.search.org or 
see Appendix A for 
a hard copy version 
of the assessment 
questions and 
worksheets to 
record your 
responses. 
The Assessment 
Tool was developed 
using Microsoft 
Excel. If you do 
not have this 
application, you 
can download a 
free Excel reader 
at www.microsoft. 
com/downloads. 
To complete your self-assessment, you can use the questions we have adopted and 
revised from the NIST guidance under SP 800-26.11 To make the process a little easier, 
SEARCH has built an IT Security Self- and Risk-Assessment Tool, based on the 
information described in this chapter, to aid you in this process. 
The Assessment Tool is a Microsoft Excel spreadsheet containing worksheets 
that cover the three information categories and subcategories described in Step 
3Management, Operational, and Technicaland a fourth category, developed 
and added by SEARCH, State and Local Law Enforcement-Specific IT Security 
Controls, which assists with recording information on additional state and local 
government issues. 
The Assessment Tool allows your policy development team to walk through the 
process and record their answers in one location. The Assessment Tool provides your 
team with a simple and concise methodology by which to assess your systems and 
their potential risk. It gives a graphical view of the systems assessed and their current 
status, based on the teams input. Because of the graphical nature of the Assessment 
Tool, it is immediately obvious where important issues need to be addressed. The 
answers can give managers a roadmap to their response to the risk and offer guidance 
on funding requirements for their systems. 
11 Security Self-Assessment Guide for Information Technology Systems, November 2001. 

Chapter 3 62 

A Tour of the Assessment Tool 
The first page of the Assessment Tool is the Table of Contents (Figure 8), an indexed 
listing of the spreadsheet contents. Each topical area is hyperlinked to the worksheet 
containing the questions to be completed. When you highlight the section and left 
click on it with your mouse, you will be taken immediately to that worksheet.

Image of Screenshot of Risk Assessment Tool 
figure 8: table of contents, SeArch It Security Self- and risk-Assessment tool 

 Introduction 
The introduction page provides an overview of the Assessment Tool and its use. It also 
references the NIST documents that were used to build the Assessment Tool. 
 Gathering Preliminary Information 
This section is a resource page containing much of the information already discussed 
in this chapter, describing the kinds of information that the team must have available 
before it starts this project. 
 System Questionnaire 
This system questionnaire cover sheet is used to document or describe the system or 
systems that are the focus of the assessment, who is involved with the assessment, and 
the purpose of the assessment. 
Categories 
The Assessment Tool is broken down into four main categoriesthree of these are 
used as described by NIST, and we have added a fourth category for questions specific 
to state and local law enforcement. 

Phase IConduct a Security Self-Assessment 63 

As discussed on page 57, the four categories contain 18 subcategories of questions 
your policy development team should answer during the assessment. The four 
categories and their subcategories are listed in Figure 9. 

Management 
1. Risk Management 
2. Review of Security Controls
3. Lifecycle 
4. Authorize Processing (Certification and Accreditation) 
5. System Security Plan 
Operational 
6. Personnel Security 
7. Physical and Environment Protection 
8. Production, Input/Output Controls 
9. Contingency Planning 
10. Hardware and System Software Maintenance 
11. Data Integrity 
12. Documentation 
13. Security Awareness, Training, and Education 
14. Incident Response Capability 
Technical 
15. Identification and Authentication 
16. Logical Access Controls 
17. Audit Trails 
State and Local Law enforcement-Specific It Security 
18. FBI CJIS Compliance 

Figure 9: Assessment tool categories/Subcategories 

When you click on the hyperlink to one of the subcategories, you are immediately 
taken to the worksheet containing the particular set of questions for that subcategory. 
The questions are listed down the left side of the worksheet. A group of Effectiveness 
Ranking fields runs across the top. SEARCH has tried to make answering these 
questions as simple as possible for policy development teams that are using the self- 
and risk-assessment processes laid out in this Tech Guide. 

Chapter 3 64

Figure 10 shows the worksheet for the 1. Risk Management subcategory within the 
Management category. 

Image of Risk Management worksheet

Figure 10: worksheet for risk management Subcategory 

As shown in this worksheet, the five effectiveness ranking levels are listed across 
the top of the Assessment Tool. (See Figure 6 on page 59 for a detailed description 
of these levels.) In its documentation of this process, NIST asserts that the process 
should be followed from left to right: build your policy first, then your procedures, 
implement both, build your measurements, and then create a feedback loop.12 
This linear process is ideal, but probably not realistic for most agencies. 
Many agencies have existing systems in which policies and procedures have been 
developed in some areas, and a certain amount of measures have been put in place to 
evaluate these. But few agencies have successfullyor adequatelycovered all 
levels, and this is where the Assessment Tool will really benefit your security 
planning. Answering the questions in the Assessment Tool will immediately 
12 Note: The SEARCH IT Security Self- and Risk-Assessment Tool diverges from the NIST 
methodology by assuming few organizations have completed a full and detailed self-assessment and 
risk assessment of their IT systemsan exercise central to understanding what vulnerabilities exist 
and, therefore, what policies are needed. By beginning with a detailed analysis of an organizations 
IT environment, this Assessment Tool will then identify risks, gaps, and policy needs. 

Phase IConduct a Security Self-Assessment 65

highlight those areas you have not yet addressed and give you a methodology with 
which to adequately address all of your security issues. 
Going back to our original example question from the Risk Management subcategory, 
heres how the self-assessment immediately indicates those areas you need to address 
in your policy development and implementation. Lets say your answers to the 
question: Is risk periodically assessed? for each level are: 
Level 1: Yes, a policy exists. 
Level 2: Partially, we have some procedures in place for periodic risk assessment. 
Level 3: No, we have not implemented the policies and procedures. 
Level 4: No, we have not developed any process for measuring the 
implementation of our policies and procedures.
Level 5: No, we have not built any feedback mechanisms into the process.
So how does the Assessment Tool make this easier for your team to answer the 
questions? As the team reviews the questions, they can use the <arrow> keys to 
highlight the specific field under the Effectiveness Ranking section and record an 
answer for that particular question and level. Highlighting the field displays a down 
arrow in that field, as shown in Figure 11. Clicking on the arrow displays a drop-down 
menu from which you can select an answer of NO, YES, PARTIAL, or N/A. 
Image of Effectiveness Ranking with Drop Down Menus
figure 11: using drop-down menus to Answer Questions in worksheet 

Chapter 3 66

Selecting an answer for that field provides the team with a visual representation 
of the answer. Red for NO, green for YES, yellow for PARTIAL, and no color 
for N/A, as illustrated in Figure 12. This gives the team and any managers using 
the Assessment Tool an immediate understanding of the status of that question in 
relation to the system. It also can give a manager an overall sense of the system by 
visually depicting the green YES answers versus the red NO and yellow PARTIAL 
answers. (In Figure 12, the green is represented by light gray, the red by light purple, 
and the yellow by dark gray.) 

Image of Partially-filled in Effectiveness Ranking

figure 12: worksheet After effectiveness ranking Questions are Answered 
The Assessment Tools ease of use and its ability to aid the team by quickly 
documenting answers to the assessment questions makes using it a much easier 
process by which the team can complete the self- and risk-assessment processes. 

Phase IConduct a Security Self-Assessment 67

Use the Assessment Tool! 
Now its time to complete all the questions in your self-assessment in the four 
categories of Management, Operational, Technical, and State and Local Law 
Enforcement-Specific IT Security Controls. Please use the assessment questions 
and response worksheets included in the Assessment Tool, located in Appendix A. 
Or, download the Microsoft Excel spreadsheet Assessment Tool from our web site at 
www.search.org. 
Once you have completed the questions in the Assessment Tool, the next phase of 
the IT security policy development process requires you to identify and assess all 
the security risks you will uncover from this self-assessment process. Once you have 
identified these risks (see Chapter 4), developed controls to mitigate these risks 
(see Chapter 5), and developed and implemented measures that will assess the 
effectiveness of the controls (see Chapter 6), then you can begin actually formalizing 
your agencys security policies (see Chapter 7). 

An assessment is one method agency officials can 
employ to help determine the current status of their 
information systems and agency-wide information 
security program. Ideally, assessments  on an 
ongoing basis should be conducted to systematically 
identify programmatic weaknesses and where 
necessary, establish targets for continuing 
improvement. 
NIST Special Publication 800-26, Guide for Information 
Security Program Assessments and System Reporting Form 

Chapter 4:
Phase IIAssess Security Risks

What 
Activities designed to identify, categorize, and prioritize the potential security risks to 
your IT systems. 
Why
Once you have assessed the risks, you can build risk mitigation strategies that 
ultimately form the basis of your security policies and procedures. 
Who 
The Security Policy Development Team assesses risks and proposes mitigation 
strategies. When the risks have been identified, prioritized, and quantified, senior 
management decides which risks will be the subject of agency policies 
and procedures. 
When 
The risk-assessment process begins after you complete the self-assessment process. 
You need to understand your information technology (IT) systems and how they are 
used before you can determine the risks inherent to the systems operation. 
Risk: 
An expectation of 
loss or threat that 
can be expressed 
as the probability 
that a particular 
threat (or set 
of threats) will 
exploit a particular 
vulnerability with 
particularly harmful 
results. 
Applying Security 
Practices to 
Justice Information 
Sharing, Global 
Justice Information 
Sharing Initiative 
Security Working 
Group 
Assessing the risk to your agencys IT assets is critical to the successful development 
of your information security policy. Failure to do so can ultimately lead to a potential 
compromise of your system. When you complete the self-assessment process, you are 
likely to expose a number of potential risks of which you were probably unaware. The 
goal of the risk-assessment is to protect the operation of the organization, and both 
IT personnel and management are responsible for this. 
Risk assessment contributes to an agencys effectiveness by: 
1. Identifying potential problems and thereby developing plans to protect IT 
assets that store and process data. 
2. Enabling well-informed decisions about how to address risks to the system. 
3. Providing managers with specific system information to justify IT budget 
expenditures in the area of security. 

Chapter 4 72

Why Is the Risk-Assessment Process 
Important? 

Risk assessment is: 
The process 
of examining all 
risks, then ranking 
those risks by level 
of severity. Risk 
analysis involves: 
determining what 
you need to protect, 
what you need to 
protect it from, and 
how to protect 
it. 
Applying Security 
Practices to 
Justice Information 
Sharing, Global 
Justice Information 
Sharing Initiative 
Security Working 
Group 

No system can be 100 percent secureunless it is unplugged. Period. But thats 
not realistic in this world where information has a mission-critical role in law 
enforcement. Also, to be effective, information must be captured, shared, and 
exchanged with automated systems. So law enforcement agencies must calculate every 
potential risk to their information systems and then balance the risks they are willing 
to accept and those they must avoid. 
The purpose of the risk assessment is to allow you to identify, classify, and prioritize 
the existing risks in your IT systems. Once this is done, and with input from 
management, you can determine how you are going to handle each specific risk. You 
will either choose to live with the risk orthrough developing security policies and 
controlsreduce or mitigate these risks to an acceptable level for your agency (well 
discuss risk mitigation in Chapter 5). 
By conducting a thoughtful analysis of the potential risks to an agencys information 
systems, executives and managers can build plans to address them. In addition, 
following a thorough investigation of potential exposures, managers can determine 
the costs of protecting the systems, both financially and in terms of human resources. 
Providing adequate security can be expensive. Given the limitations faced by most 
government agencies, there must be a fine balance in providing enough security but at 
an affordable level when addressing identified risks. 
Risk: The net 
negative impact 
of the exercise 
of a vulnerability, 
considering both 
the probability 
and the impact of 
occurrence. 
NIST Special 
Publication 
800-30, Risk 
Management Guide 
for Information 
Technology 
Systems 
Lets not forget that assessing risk is a fairly common practice for law enforcement. 
Every day officers assess risks to themselves, other officers, and the public while 
responding to calls for service. Assessing risk in these situations is instinctive and 
automatic. When officers respond to an address, for example, they survey the scene as 
they approach, observing multiple avenues of approach and retreat. Officers evaluate 
what is occurring on the other side of a door by listening before knocking and, as 
the door opens, they make a visual assessment of what is happening inside before 
entering. Perhaps most important, the agency, based on previous assessments of 
similar risk, has adopted policies and procedures for handling particular situations. 
Officers are trained to act according to policy and standard procedures, so they know 
exactly what to do when presented with a certain set of circumstances. 
We are talking about applying the same level of assessment and scrutiny to 
vulnerabilities associated with your agencys information systems. The goal is for IT 
risk assessment to become a routine activity within your department, just like any 
other type of risk assessment. 

Phase IIAssess Security risks 73 

Conduct a Risk Assessment 
Conducting a risk-assessment exercise is a relatively simple task, particularly now that 
you have completed the self-assessment in Chapter 3. Based on that exercise, you now 
know what policies and procedures you currently have, and where you may be lacking 
specific security policies. 
Original Tech Guide Icon, page 150
In the original Law Enforcement Tech Guide, risk management for IT projects and their 
implementation were explored. In that publication, risk management was defined 
as a forward-thinking process that requires project leaders to envision challenges 
or threats to the project and develop contingencies for handling such events. This 
definition easily applies to IT security risk assessments. 
SEARCH Icon
Record the 
identified risk and 
other risk-decision 
responses using 
the SEARCH IT 
Security Self- and 
Risk-Assessment 
Tool spreadsheet 
at www.search. 
org, or use the 
assessment 
worksheets and 
questions provided 
in Appendix A.
In the original Law Enforcement Tech Guide, we introduced several key steps for 
creating a risk management plan. Weve modified those a bit here and 
tailored them to the security risk-assessment process: 
Step 1: Based on the self-assessment, identify and write a description of the risk. 
Step 2: Categorize and quantify each identified risk. 
Step 3: Determine your tolerance for levels of risk. 
Step 4: Develop a risk-mitigation strategy. (This step is addressed in Chapter 5.) 
Step 1
Identify the Risk and Write a Description of It 
For each assessment question your team answered during the self-assessment, your 
team will assess its Effectiveness Ranking responses and write a description of the 
identified risk. For example: 
Based on the agencys responses to this assessment question 
Is appropriate background screening for assigned positions completed prior to granting 
access? 
This may be the description of the identified risk: 
Individuals who have not undergone background screening may be able to access the 
information system. 

Chapter 4 74

Step 2 
Categorize and Quantify the Identified Risks 
Original Tech Guide, page 150
Now it is time to put some rationale around each risk youve identified so that you 
can categorize them and, ultimately, prioritize the handling of them. Borrowing from 
our original Law Enforcement Tech Guide, categorizing risks consists of analyzing the 
likelihood that the risk will actually occur; how severe the risk is, ultimately; and what 
type of impact its occurrence would have on the organization, as well as on people 
both inside and outside of the agency. 
Determine the Likelihood of the Risk 
In dealing with likelihood, take each identified risk and rate the possibility that it will 
occur: 
 Remote: The risk probably will not occur because the risk would be difficult to 
realize, or there are solid means in place to limit the risk appropriately. 
 Possible: The risk has a chance of occurring, but it may be difficult or there are 
controls in place to help avoid the risk. 
 Likely: The risk, due to conditions and capabilities, is likely to occur. 
In assessing likelihood, ask the following questions about each risk: 
1. Who or what would cause the risk to occur (e.g., a former employee)? 
2. Is there a motivating factor in operation to cause someone or something to 
expose the risk (e.g., the employee was recently fired and is disgruntled)? 
3. Does your existing environment have any mechanisms at this point that would 
lessen the risk (e.g., immediately upon an employees separation for any reason, 
the organization removes all of the employees identifiers, passwords, etc., from 
the system)? 
Answering these questions for each risk will allow you to properly determine whether 
there is a possibility of the risk occurringfrom remote to highly likely. 
Determine the Severity of the Risk 
Next, its time for the team to make judgments about the consequences of a particular 
risk by ranking its severity as high, medium, or low. You have enough information to 
make an overall judgment about each particular risk, but it still is a clearly subjective 
exercise. As you analyze all data youve collected about the risk so far, give it one of the 
following overall rankings: 
 Low: The risk is manageable through planning and action and the impacts 
generally are minimal. 
 Medium: The risk will be mitigated through planning and action, although if it 

Phase IIAssess Security risks 75

occurs, it will still have some impact on some more important areas of concern. 
 High: The risk will have serious impact and, without extensive planning and 
action, its consequences will be severe. 
Identify the Area of Impact of the Risk 
This risk category is not captured in the Assessment Tool, but is information 
that will be valuable to your teams decision-making process. Here, you and 
your team need to contemplate all of the ways damage can be caused if a risk is 
realized. Some risks can cause damage in multiple areas both within and outside of 
your organization. We suggest organizing the areas of potential impact into several 
categories, such as these: 
Human 
 Loss of life or injury 
 Jeopardy to reputations 
Liability 
 To the organization and/or parent agency such as city, county, state 
 To individuals 
Operations 
 Impede or disable ability to conduct business 
 Impede or disable decision-making 
Financial 
 Lost revenue 
 Cost to correct damage 
System data and information 
 Data integrity 
 Availability of the system and/or data 
 Confidentiality of data and/or information 
Public 
 Loss of confidence 
 Jeopardy to citizen safety 
You may choose to add other categories of impact, such as political or managerial. For 
each risk, you should articulate the impact in detail. 

Chapter 4 76

Figure 13 shows how we took one of the self-assessment questions and illustrates how 
we would analyze it as a risk. 

Assessment Question:
Is appropriate background 
screening for 
assigned positions 
completed prior to 
granting access? 
Description of Identified Risk: 
Individuals who have not undergone 
background screening may 
obtain access to the information 
system. 
Likelihood: Possible 
Severity: Medium 
Impact: 
 Liability 
 Systems data and integrity 
 Financial 

Figure 13: Illustration of risk decision responses to an Assessment Question 
Step 3 
Determine Your Tolerance for Levels of Risk 
SAERCH Icon
Use the 
Assessment Tool 
to capture risk-
tolerance decisions 
for each identified 
risk. 
Having categorized and quantified the identified risk, the policy team should next 
develop recommendations on the specific tolerance level for that risk and present 
them to the management team. Tolerance decisions are based on facts, research, and 
other information compiled by the team, but executive sponsors make the final 
tolerance determination for each risk. The tolerance decision begins to drive your 
strategy toward mitigating each risk. 
There are the four levels of risk tolerance: avoid, assume, mitigate, or transfer. 
You should assign one Tolerance Level to each identified risk. Figure 14 provides 
a detailed definition of each tolerance level, and provides two scenarios of how two 
sample agencies would choose to avoid, assume, mitigate, or transfer risk. 

Phase IIAssess Security risks 77

Avoid 
Avoidance is often used for risks 
that have the capacity for negative 
impact, but have little known 
recourse. In security projects, a 
decision to avoid a risk often means 
a decision not to let your agency 
put itself in the situation where it 
could incur the risk. Therefore, your 
decision would also be to avoid the 
cause of the risk. This is an extreme 
decision, but one where the benefit 
of automated systems to the agency 
would be negated entirely compared 
to the risks the technology would 
expose the agency to. Generally 
the decision here is that the system 
or component of a system would 
be shut down or eliminated to 
completely avoid the risk. 
Example 1
A police departments records 
management system (RMS) did 
not use encryption and the RMS 
data were stored in plain text on 
the server. Anyone who could gain 
physical access to the server could 
potentially get to confidential data. 
To avoid this risk completely, the 
department may consider replacing 
or upgrading the RMS altogether 
with encryption-based software. 
Example 2
An agency is interested in 
implementing new intrusion 
detection software that requires 
an upgrade of new routers within 
the system. However, the purchase 
of the new routers is not within 
the current budget. Without the 
upgraded routers, the software will 
not function properly. The software 
has a known attack if the existing 
routers are used. 
The agency can avoid the risk by 
simply not implementing the new 
software and seeking other solutions 
compatible with its current routers. 
Assume 
In this case, the decision to assume 
a risk means accepting the risk 
as-is, and not implementing any 
policies or procedures to lessen it. 
This is often the decision in cases 
where the risk is so minimal and 
of limited impact should it occur 
that the cost of implementing a 
mechanism to minimize or reduce 
it would be far greater than the 
agencys concern. 
Example 1
The department could decide to 
merely assume the risk and not 
do anything about it. Given the 
potential for major impact on 
the system and the department, 
as well as the liability involved, 
this certainly would not be a 
recommended decision. 
Example 2
The agency implements a newer 
operating system for a portion of its 
network. The new operating system 
allows for more than eight-character 
passwords. However, several 
parts of the network still have 
an operating system that allows 
only six-character passwords. 
The agency chooses to allow the 
use of six-character passwords 
as its standard because the cost 
to upgrade all systems would be 
prohibitive. 
Mitigate 
This is the most common decision 
to make for identified risks: to 
implement policies, procedures, and 
other security controls to limit the 
risk to an acceptable level. 
Example 1
The decision to mitigate would be 
made based on the critical role 
the RMS plays in the department 
and the conduct of business. If the 
department decides to mitigate 
risk, then it needs to balance the 
need for this RMS with the risk and 
determine strategies for mitigation, 
such as physically locking the 
server in a separate room, adding a 
lock to the server enclosure, limiting 
the number of individuals who are 
authorized to access the server, 
or moving the server to a secure 
location within the agency. 
Example 2
The agency has a six-character 
password for users to enter 
a database containing gang 
intelligence files. The current 
software in use does not allow for 
a more secure password to these 
sensitive and attack-prone files. 
Management recognizes that this 
is insufficient to protect the data 
contained on the system and limits 
the risk by isolating the systems in 
use to an office occupied only by 
the gang investigators and who are 
the only ones who have a key to 
that office. 
Transfer 
Pass the buck! Seriously, though, 
one option is to transfer the 
responsibility for a system or the 
risk itself to another party that can 
better accept and deal with the risk 
and/or has the resources necessary 
to properly mitigate the risk. 
Example 1
The department could potentially 
transfer the risk by outsourcing the 
server and its security to the city or 
county IT department, if that agency 
had appropriate controls to manage 
the risk.
Example 2 
The agency outsources data storage 
for its system to another agency in 
a multiagency project. The risks 
associated with maintaining the 
information is transferred to the 
agency that actually maintains the 
data. 
Figure 14: risk tolerance Levelsdefinitions and examples 

Chapter 4 78

Make Your Risk Assessment Easier by Using 
the SEARCH Assessment Tool 

SEARCH Icon
The Assessment 
Tool was developed 
using Microsoft 
Excel. If you do 
not have this 
application, you 
can download a 
free Excel reader 
at www.microsoft. 
com/downloads. 
To complete your risk assessment, use the SEARCH IT Security Self- and Risk-
Assessment Tool. Visit www.search.org to download this Microsoft Excel 
spreadsheet tool, or use the worksheets provided in Appendix A. 
In Chapter 3, we described how your team answers each assessment question in the 
Assessment Tool by filling in responses in the Effectiveness Ranking section of 
each worksheet. In this way, your team recorded the current status of your system 
by recording the level of documented, implemented, tested, and integrated policies, 
procedures, and controls in your agency. 
Now, for each assessment question, you will record responses in the Risk Decisions 
section. Using the Assessment Tool during your risk assessment will help your team to 
walk through the process and record answers in one location, providing a simple and 
concise methodology by which to assess risk. It also provides decision-makers with a 
graphical view of your systems and risk assessments. 
When you begin to use the worksheet, which is located on page 123 (in Appendix A) 
or the Microsoft Excel spreadsheet Assessment Tool at www.search.org, you will 
notice a header titled Risk Decisions. As in the self-assessment, the team reviews 
each question. Using this chapter as a guide, assess your risk decisions about each 
question in the Assessment Tool and document your risk. 
First, write a statement that describes the identified risk. Then you will be able to 
record issues such as the likelihood of occurrence, the potential severity of a realized 
risk, the tolerance level you choose to accept for that risk, and a numeric priority for 
action on that risk. 
So how does the Assessment Tool make this easier for your team to answer the 
questions? As your team reviews the questions, use the <arrow> keys to highlight the 
specific field under the Risk Decisions section and record an answer for that particular 
question (Figure 15). 

Phase IIAssess Security risks 79

Risk Decisions 
Description of Identified Risk Likelihood Severity Risk Tolerance Action Priority 

Image of Risk Decisions Questions Guide

Figure 15: risk decisions Questions in the Assessment tool 
The Description of Identified Risk is a free-form text field that allows your team to 
record the risk statement. (This process will build off of the Effectiveness Ranking 
questions your team already answered in Phase I.) When highlighted, the four other 
fields in the Risk Decisions section display a down arrow. Clicking on the arrow 
displays a drop-down menu that has different answers, depending on the field. There 
are four fields: Likelihood, Severity, Risk Tolerance, and Action Priority. The 
drop-down answer options for each column are: 
Check out the 
following pages 
of this IT Security 
Tech Guide for 
descriptions of: 
Likelihood 
(page 74) 
Severity 
(page 74) 
Tolerance 
(page 76) 
 Likelihood 
 Remote 
 Possible 
 Likely 
 Severity 
 High 
 Medium 
 Low 
 Tolerance 
 Avoid 
 Mitigate 
 Assume 
 Transfer 
 Action Priority (1 being highest priority, and 3 the lowest priority) 
 1 
 2 
 3 

Chapter 4 80

To facilitate a quick visual evaluation, each of these answers also has a corresponding 
color that appears in the block along with the answer (Figure 16). This again allows 
the team to quickly view its responses to its risk assessment and provides managers 
with a quick visual overview of the entire process. Heres a completed example of the 
analysis of an identified risk: 
Risk Decisions 
Description of Identified Risk Likelihood Severity Risk Tolerance Action Priority 
Not conducting thorough 
background checks 

Image of Risk Decisions Respnses Worksheet
Figure 16: Example risk decisions responses in the Assessment tool 

Whats Next? 
So far you have conducted a self-assessment (Chapter 3) of your systems and 
determined your security risks (Chapter 4). The next phase of the IT security policy 
development process requires you to develop your risk mitigation strategy, which 
includes developing security controls for each risk that your team has determined 
needs to be mitigated. So, keep up the good work and lets move on to Chapter 5! 

It must be recognized that justice information 
technology systems are a vital part of the nations 
critical infrastructure, and as such, information 
technology infrastructure requires comprehensive 
security architecture. Protecting this critical resource 
is not just a matter of operational good sense; it 
is increasingly a matter of national security and 
public safety. 
Applying Security Practices to Justice Information Sharing 
Global Justice Information Sharing Initiative Security Working Group 

Chapter 5:
Phase IIIDevelop a Risk-Mitigation Strategy

What 
Once you know your information technology (IT) systems exposure to risk, you must 
establish controls and procedures to safeguard your information system. 
Why 
Establishing the risk-mitigation strategy is the heart of protecting your IT assets from 
compromise. It fulfills the management directive regarding risk tolerance. 
Who 
The Security Policy Development Team designs the strategy. A variety of individuals 
will be responsible for helping to design and implement security controls and 
document their effectiveness. 
When 
This process occurs after you complete the self- and risk-assessment processes and 
have made risk-tolerance decisions. 

Process to Identify 
and develop 
controls 
Prioritize risks 
Build security 
controls 
Document the 
controls 
Select which 
controls to 
implement; assign 
responsibility for 
these 
Develop an 
implementation 
plan 
With your self-assessment results in hand, and after you have categorized and 
quantified all risks and made decisions about your agencys tolerance for each 
identified risk, you are ready to create a strategy to mitigate those risks. 
Remember, the goal here is to implement risk-mitigation strategies that will reduce 
the likelihood of system harm should it be exposed to the security vulnerabilities 
your team has identified. Here are a few points to keep in mind as you develop 
mitigation strategies: 
 If there is a high probability that the risks will occur, multiple layers of security 
controls may be the most effective method to mitigate this exposure. 
 When addressing the issue of hacking or other criminal attack, if the cost of 
attacking the system is relatively minimal compared to the potential gain for the 
attacker, you should develop controls that will dramatically increase the cost of 
an attack. A basic security axiom states: Your fence should be a foot higher than 
your neighbors. This discourages attackers from tampering with your system. 

Chapter 5 84

 If the potential for loss to the agency is extremely largemonetary, political, or 
otherwiseyour agency needs to consider some more rigorous approaches to 
risk mitigation. Among them are: 
 Redesigning the entire system (this could be a lengthy and 
costly process).
 Shutting the system down.
 Adding both technical and nontechnical protections that would limit 
the extent of the attack (properly implemented, these protections may 
provide the best solution). 
Mitigating your risks primarily comprises developing controlsspecific measures 
you implement that are designed to lessen or negate the impact of a risk that actually 
occurs. This chapter outlines a process that will help your team identify and develop 
these controls. 
Prioritize Your Agencys Risks 
Before developing security controls, your first task is to rank, in order of concern, 
the risks identified during the risk-assessment exercise. Once you have categorized, 
quantified, and established a tolerance level for all these identified risks, it should 
become readily apparent which risks rise to the top of the list. Management can now 
use this list to determine its IT security priorities. 
What Are Security Controls? 
Security controls 
are the methods 
you put into place 
to lessen the 
impact or negate 
the effect, if any, of 
an identified risk. 
Developing security controls is the heart of your mitigation strategy and well spend 
a great deal of the rest of this chapter focused on showing how you can properly 
develop these controls. 
Security controls are processes your agency puts into place to adequately protect your 
information system. They seek to control the likelihood of each risk occurring. You 
will establish numerous controlsthere can be one or more controls implemented 
for each risk exposure you are trying to mitigate. The controls are developed based on 
your completion of the two previous phases: Phase I, self-assessment, and Phase II, 
risk assessment. You will not be able to properly develop security controls if you have 
not properly assessed your system and determined your systems risk. 
This chapter addresses the development of security controls that are required 
to mitigate the identified security risks of your IT system. Once the controls are 
implemented, you also need a way to verify that the controls are performing as 
designedin other words, that they are effectively mitigating the specific identified 
risks. These activities are discussed in Chapter 6, which focuses on how to develop and 
implement a security measurement process. 

Phase IIIDevelop a risk-mitigation Strategy 85

Security Controls Defined 
According to the National Institute of Standards and Technology (NIST), 
Security controls are the management, operational, and technical safeguards or 
countermeasures prescribed for an information system to protect the confidentiality, 
integrity, and availability of the system and its information.13
In other words, a control is a mechanism you put in place to mitigate a risk you 
identify. It can range from:
 A change in management strategy (such as how the agency deals with securing 
systems in general) 
 To using software applications within the system that automatically implement 
particular controls (such as enforcing a password) 
 To changing mandates on personnel (such as requiring each system user to 
include a biometric when logging onto the system, or instituting a policy 
requiring passwords to be changed once a month). 
Because we conducted the self-assessment and risk assessment across the three critical 
areas of management, operations, and technology, you should develop security 
controls that focus on those same issues. 
Management controls affect how IT systems are managed. An example of such a 
control might be the development of a physical security plan for IT assets. 
Operational controls address security methods implemented and executed by people 
(as opposed to systems), such as using an enhanced password methodology. 
Technical controls address security mechanisms that a computer system executes, such 
as using encryption to control access to sensitive data. 
13 NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems, 
February 2005. 

Chapter 5 86

There are literally thousands of possible controls that can be applied to IT systems 
security depending on the risks identified, so listing all of them here does not make 
sense. Instead, we refer you to NIST literature that addresses this subject at http:// 
csrc.nist.gov/publications/nistpubs. That web site provides many documents 
containing examples of controls. 
Another document that provides many excellent examples of controls used in 
managing and operating information sharing systems is Applying Security 
Practices to Justice Information Sharing. This resource document, prepared by 
the Global Justice Information Sharing Initiative Security Working Group, is designed 
to educate justice executives and managers in good, basic, foundational security 
practices that they can deploy within their enterprise and between multiple enterprises. 
This document and its companion CD contain background information, overviews 
of best practices, and guidelines for secure information sharing. The document (in 
PDF) and CD (a browser-style, graphical overview of the document) are available at 
http://it.ojp.gov/global. 
Meanwhile, lets take a look at how you should develop controls. NIST proposes a 
structure for security controls that includes these three components: 
1. Control
A control is the mechanism that is adopted to mitigate a risk.
2. Supplemental guidance 
Supplemental guidance provides further detail on how the control will be 
implemented or any exception to its implementation. 
3. Control enhancements 
Control enhancements provide the detail and results of implementing the 
control. 

Phase IIIDevelop a risk-mitigation Strategy 87

Lets look at an example of this structure taken from NIST Special Publication 
800-53 regarding how to deal with Unsuccessful Login attempts. 
UNSUCCESSFUL LOGIN ATTEMPTS 
Control: The information system enforces a limit of [organization-defined 
number] consecutive invalid access attempts by a user during a [organizationdefined 
time period] time period. The information system automatically [locks 
the account/node] for an [organization-defined time period], and delays the next 
login prompt according to [organization-defined delay algorithm], when the 
maximum number of unsuccessful attempts is exceeded. 
Supplemental guidance: Due to the potential for denial of service, automatic 
lockouts initiated by the information system are usually temporary and 
automatically release after a predetermined time period established by the 
organization. 
Control enhancements: The information system automatically locks the 
account/node until released by an administrator when the maximum number 
of unsuccessful attempts is exceeded. 

Chapter 5 88

Lets also look at an example of how controls are established to mitigate a risk, as 
illustrated in the Global document Applying Security Practices to Justice 
Information Sharing. 
In this example, a common risk of Identification of Unauthorized Hardware Attached to 
a System is used. This example shows that a risk occurs when agency personnel attach 
unauthorized hardware to an existing system, an action that may compromise the 
systems integrity. In this case, the agency has articulated its policy directives, followed 
by the controls it established to mitigate the risk. 
Identification of Unauthorized Hardware Attached to a System 
Establish policies to limit employees from attaching unauthorized hardware 
to the office system. Unauthorized hardware includes computers, modems, 
terminals, printers, and disk or tape drives. The policies should also restrict 
software that employees may load onto the office system. Implement policies 
regarding opening unidentified e-mail attachments and downloads off the 
Internet. 
 Perform monthly audits of all systems and peripherals attached to the 
network infrastructure. 
 Make random inspections of equipment to search for unauthorized 
hardware attached to the network. 
 Identify missing or misplaced hardware. 
 Search and identify any unauthorized hardware attached to the network. 
 Inspect computers and networks for signs of unauthorized access. 
 Search for intrusion or tampering with CD-ROMs, tapes, disks, paper, 
and system components that are subject to physical compromise by 
damage, theft, or corruption. 

Phase IIIDevelop a risk-mitigation Strategy 89

Stop Sign Icon
No set of security 
controls will 
ever completely 
eliminate risk from 
your agency. 
Build Your Agencys Controls in Six Steps 
How do you build your security controls? We created a six-step process to make 
building security controls easier (Figure 17). A worksheet for building each control, as 
described in this chapter, is provided in Appendix B. The worksheet is titled SEARCH 
IT Security Control Development Worksheet. We suggest that you make 
numerous copies of this worksheet and get ready to build your controls! 

BuILdING A coNtroL 
Step 1 Identified risk Start with an identified risk that must be mitigated 
Step 2 Existing controls List controls, either full or partial, that currently exist for the risk 
Step 3 All other possible controls List all possible controls that could be used to mitigate the risk 
Step 4 Control implications Analyze the implications associated with each control 
Step 5 Control recommendation Make a recommendation to management regarding a control to adopt 
Step 6 Management control decision Management makes a decision as to which controls to implement 
Figure 17: the Six Steps to Building a control 

Step 1
Start with an identified risk that must be mitigated 
As discussed earlier, conducting a risk assessment of your system results in 
identified areas of risk. In developing appropriate controls, you must start with 
an identified area of risk. As an example, lets use an actual question from the 
SEARCH IT Security Self- and Risk-Assessment Tool that illustrates a risk: 
Question 6.2, Section 6, Personnel Security, of the Assessment Tool. 
Is appropriate background screening for assigned positions completed prior to 
granting access? 
Lets assume an agency used the Assessment Tool to answer the questions, as shown 
in Figure 18. 

Chapter 5 90
 
Image of Effectiveness Ranking
Figure 18: example effectiveness ranking responses in the Assessment tool 

The answers given by the agencys security team using the Assessment Tool indicates 
that the agency: 
 Has no written policy (Level 1) 
 Has partially defined procedures for conducting background screening of the 
assigned positions (Level 2) 
 Has partially implemented those procedures (Level 3) 
 Has not yet determined methods for measuring the effectiveness of such a 
control (Level 4) 
 Has no continuous feedback method to determine compliance with the policy, 
procedure, or implemented control (Level 5). 
After analyzing the responses in the Effectiveness Ranking section, the agency 
records its risk decisions, as shown in Figure 19. It determines that Not conducting 
thorough background checks is the identified risk; that it is likely this risk will occur; 
the severity of this risk is high; and the agency chooses to mitigate the risk as a #1 top 
priority. Now the agency will build controls to mitigate this risk. 

Image of Risk Decision Response Strategy
Figure 19: example risk decisions responses in the Assessment tool 

Phase IIIDevelop a risk-mitigation Strategy 91

Enter the identified risk in Step 1 of the Security Control Development Worksheet, as 
shown below. 

Step 1 Identified risk : 
Personnel who have not undergone thorough background checks have access to 
information systems. 
Step 2 
Reminder: 
See Appendix B for 
the entire SEARCH 
IT Security Control 
Development 
Worksheet. 
Photocopy and use 
this worksheet to 
build your controls. 
List controls, either full or partial, that currently exist 
for the risk 
You may already have some formal or informal procedures in place to address the risk 
identified in Step 1 and for which this control is being built. Refer to the 
analysis you did during your self-assessment and the effectiveness rankings you 
identified during that part of the process to help you define the existing controls. 
Enter the existing controls for this risk in Step 2 of the Worksheet. 
Step 2: existing controls 
New employees who will have access to the agencys IT systems receive a criminal 
background check. 
Step 3 
List all possible controls that could be used to 
mitigate the risk 
Here your team should brainstorm all possible controls that would be available 
to your organization to mitigate the risk. These should include all possibilities 
regardless of their cost or effect on the system. Developing as complete a list of 
controls as possible will give your team several options for selecting the most 
appropriate control. 
Enter a list of all possible controls in Step 3 of the Worksheet. 
Step 3: All other possible controls 
 Conduct background checks of all agency employees who may not be authorized 
to use the system, but who still could get access to the system. 
 Enhance background screening by adding a reference check for each new 
employee. 
 Establish a rapback process so that any new activity on an employees criminal 
record is made available to the agency. 

Chapter 5 92 

Step 4
Analyze the implications associated with each control 
Every identified control has certain implications for the agency. Many controls 
may provide a solution to mitigate an identified riskbut which particular one 
will best meet your users needs and protect the data to the level you require? Each 
control must be realistic in its concept and within the ability of the organization to 
implement. Will a simpler control be as effective? Each agency must decide which 
control fits its individual needs through some analysis. 
Such analysis can include looking at the financial impact of a particular control, the 
required staff expertise to implement and manage it, and any needed changes (such 
as revisions to organizational policy or training requirements). Costs may include the 
cost of the control itself, installation, maintenance, and updates. 
Budget considerations 
A major consideration regarding a control is the fiscal implications of 
developing, implementing, and monitoring it. An option to consider is to 
conduct a cost-to-benefit analysis. 
For example, if an agency wishes to purchase a firewall to help protect a system, 
the cost to implement this control could include: 
a) The purchase price of the firewall. 
b) The installation of the firewall (even if it is done by agency personnel). 
c) Regular firewall maintenance. 
d) Review of firewall logs for irregularities. 
e) Checking for and updating firewall firmware. 
Implementation 
For each control you identify, you also need to analyze whether your current 
staff are capable of implementing the controls. Do they have the technical 
knowledge, the resources, the training, and the funding to exercise a 
particular control? Do you have the technical expertise in the agency or will 
you have to hire outside experts? Perhaps you will need additional training 
for the personnel responsible for the control. Everyday users may also have 
to be trained if they are required to implement or be involved in any part 
of a control. 
Depending on your analysis, you may need to train staff prior to control 
implementation or bring an outside consultant in to assist your agency and 
staff. Each of these decisions will surely have budget implications. 

Phase IIIDevelop a risk-mitigation Strategy 93 

After analyzing the implications for the identified control(s), enter a list of these implications 
in Step 4 of the Worksheet. 
Step 4: control implications 
 Overtime cost of assigning personnel additional duties 
 Loss of patrol/detective personnel due to reassignment to background 
investigations 
 Forty hours of training required per assigned officer 
Step 5
Make a recommendation to management regarding a 
control to adopt 
Review all of the controls your team has assembled and prepare a recommendation 
to the executive management about the best control to adopt. Determining which 
control is best, as discussed in the steps leading up to your decision, is based on an 
evaluation of the risk, the possible controls you can implement to mitigate the risk, 
anything you can add to enhance that control, the costs to implement the control, and 
the expertise required to implement and maintain that control. 
This is the tough part of the process. The teams expertise and detailed knowledge of 
the system and your available resources is a key asset at this point. Executive managers 
will be expecting the team to deliver an informed recommendation for controlling 
the agencys risk. 
Enter the policy development teams control recommendation in Step 5 of the Worksheet. 
Step 5: control recommendation 
 Use internal resources to conduct thorough background checks 

Chapter 5 94
Step 6
Management decides which controls to implement 
Management must decide which control(s) to implement to mitigate the risk 
identified in Step 1 of the Worksheet. Management may have a variety of controls 
from which to selectany of which might suffice. In this example, the agency chooses 
a solution that is financially acceptable and offers a solid mechanism for 
eliminating risk. 
Record managements control decision in Step 6 of the Worksheet. 
Step 6: management control decision 
Conduct background investigations internally using our own employees. 
Training will be provided by a neighboring agency that conducts its own 
investigations. Access to a public information database will be purchased 
and a policy will be written to ensure that proper background investigations 
are conducted. 
Document the Controls 
As your team develops the controls, it is critical that the controls are effectively 
documented in some detail. It is during this phase that your security policy is 
beginning to emerge. Ultimately, the controls you settle on during this phase 
of the process will require effective policy statements to guide their successful 
implementation. Even though we save the discussion about writing the agencys 
formal security policy until Chapter 7, you will find that it is at this stage that writing 
the policy and completing the rest of the tasks set forth in this guide are often done 
simultaneously. See Chapter 7 for details on how to formalize your information 
security policy. 
Select Which Controls to Implement and Assign 
Responsibility 
By now you should have mostif not allof the information necessary to select the 
most effective security controls to address each identified risk. Now the management 
team needs to select what security controls to implement. 
Next, identify the appropriate person(s), both within and outside of your agency, who 
will implement, manage, and be responsible for each security control. 

Phase IIIDevelop a risk-mitigation Strategy 95

Develop an Implementation Plan 

Original Tech Guide Icon, page 207
The 
Implementation 
Plan is the blueprint 
for completing the 
project. 
A solid strategy for implementation is key to ensuring the controls are properly 
developed, applied, and maintained. Here your team should develop a plan that 
specifically articulates decisions made, individual and group responsibilities, and 
how each control is implemented. 
In the original Law Enforcement Tech Guide, a process for developing a project 
implementation plan is described in Chapter 16. Although that chapter focuses 
on project implementation plans, many of its principles apply directly to security 
implementation plans, so we encourage you to read it. 
Your implementation plan should contain much of the information you have gathered 
through the self-assessment and risk-assessment exercises. It should contain a list 
of the controls management has decided to implement and should indicate who 
is responsible for each control. This plan should also contain detailed schedules for 
implementing the control, monitoring the control, and revisiting the control to 
determine its effectiveness and viability. 
Congratulations! You have now implemented security controls that will go a long 
way to reduce security risks and exposure to your agency. Keep in mind that the 
implementation of these controls does not end the process. A critical next step is 
the evaluation and measurement of those controls to ensure that they continue to 
effectively protect your organization. 
At this point you have conducted a self-assessment (Chapter 3) of your systems, 
determined your security risks (Chapter 4), and developed controls in this chapter 
to mitigate that risk. The next phase of the IT security policy development process 
requires you to measure your security controls. This next phase in the process is 
discussed fully in Chapter 6. 

The success of an information security program 
implementation should be judged by the degree to 
which meaningful results are produced. 
NIST Special Publication 800-55, 
Security Metrics Guide for Information Technology Systems 

Chapter 6:
Phase IVMeasure Your Security Controls

What
Creating and implementing a program that allows you to continuously measure, 
monitor, and provide feedback on your security program. 
Why
To find out if you have created an effective security program, and modify the program 
if its found to be deficient. 
Who
The Security Policy Development Team designs the measures. A variety of individuals 
will be responsible for helping measure the controls and document the results. 
When
This process often occurs in parallel with determining the security controls youll put 
in place (the outcome of the risk-assessment exercise). When deciding on the control, 
you need to ask how you will measure its performance and cost-effectiveness. 
Note: Strong 
measures to 
determine the 
effectiveness of 
your controls are 
key. However, you 
should NOT limit 
your policies based 
on your current 
ability to measure 
them. 
Sometimes the approaches you take to mitigate a risk just dont work. Sometimes 
they work for a while, but as technology and other processes change, they lose their 
effectiveness over time. We already know how mission-critical it is to keep the law 
enforcement agencys information technology (IT) systems secure. Today, we are 
also obligated to consistently assess how well the security program we put in place is 
working: That is the mission of the security-measurement program. 
The key goal here is to develop measurements (sometimes referred to as metrics) 
that show, in quantifiable terms, the agencys effective implementation and 
maintenance of the security controls you developed. Each control should be easily 
measured and produce repeatable results that can be tracked to identify conformance 
to your policy. You gain maximum benefit with controls that are designed to be 
measured regularly and, thereby, can show trends over time. Your measures provide 
hard evidence that the operation of your IT system and your control implementation 
conforms to the risk mitigation you intended for your agency. As such, measuring is 
not a one-time activity! 
The purpose of this program is to put in place a permanent methodology that will 
monitor, on a continuous basis, security controls and provide feedback to determine 
if corrective action is required. An effective measurement program is one that is 

Chapter 6 100

integrated into the daily operation of the system. A comprehensive program of 
measurement often incorporates multiple tracking mechanisms that document and 
quantify the performance of all adopted measures.14 
What Are Security Measures? 
Security measures are tools you put into place to help facilitate your decision-making. 
They can improve your systems performance and its accountability by collecting and 
analyzing data, and providing a report of performance. Measures allow your security 
team to monitor specific controls and take corrective action, if necessary. 
Measuring can be complex, but its design is to simplify and organize an agencys 
approach to achieving the best security program for IT systems as possible. The 
fundamental product of measuring and testing is to ensure that you collect valid 
information about the performance of your system. It also is an iterative process that 
helps to analyze the security data and determine what changes need to be made to the 
system to ensure its security. 
Develop and Select Measurement Methods 
Tips Icon
If risk avoidance 
or transference is 
used or considered 
for a particular 
risk, that risk may 
not immediately 
need a process in 
place to measure 
it because your 
team consciously 
decided to avoid 
or transfer your 
risk. Therefore, the 
controls that do 
require ongoing 
measurement will 
naturally rise to the 
top of your list of 
concerns. 
The measurement development process deals with creating and implementing 
metrics. This is a critical part of the overall policy development process 
because it provides the necessary feedback to control and ultimately improve 
the security of your system. In addition, each of these steps is designed to feed 
back into the entire process that we have described so far in this Tech Guide. Your 
measurement program, therefore, should be able to continually self-correct and guide 
improvements to the security of the system. 
After your security policy team conducted your agencys risk-assessment, it prioritized 
the risks from the greatest to the least (as described in Chapter 4). This was done so 
the team could focus on the most critical risks first. Your policy team then decided 
which specific risks your agency intended to mitigate through the development of 
security controls (as described in Chapter 5). 
14 For more information on performance measurement, see Law Enforcement Tech Guide for Creating 
Performance Measures that Work: A Guide for Executives and Managers funded by the COPS Office 
(publication pending). 

Phase IVmeasure Your Security Controls 101
 
A measurement example: 
Measuring Password Strength within an Agency 
Lets assume that agency X has performed the self-assessment, risk assessment, 
and risk mitigation processes described so far in this Guide and have used the 
SEARCH IT Security Self- and Risk-Assessment Tool. During those exercises, the 
agency analyzed all of the pertinent information regarding its password usage. For 
example, Question 15.1.6, located in Section 15, Identification and Authentication, 
of the Assessment Tool, asks the following: 
Are passwords unique and difficult to guess (e.g., do passwords require 
alphanumeric, upper/lower case, and special characters)?
The agency identified a risk to its system because it had no policy regarding 
password usage. Using the control development process, the team selected the 
following control, which agency management approved as the proper control for 
password usage on its system: 
All passwords must be at least eight characters long and contain at least 
one digit and at least one character. In addition, no English words of four 
characters or less may be used. 
The agency then took the following actions to establish a control and a way to 
measure this control in the agency: 
First, after advising users of the new control to regulate passwords and the need 
for it, all passwords were reset so that at the next login the user had to enter a 
new password. 
Second, the agency implemented procedures, educated users, and conducted 
testing to confirm that 100 percent of passwords met or exceeded the 
established standard. The testing gave the security policy team specific data on 
the use of the control. In this instance, the control was a success. 
But there are other factors outside the control that may negate its effectiveness 
over time. In this same situation, the other data that play into measuring the 
effectiveness of the control is an environmental scan. Agency X did some 
research on eight-character passwords and found that, due to increases in 
computer power and better cracking programs, eight-character passwords can 
be broken in 10 seconds or less. This could lead to a refinement of the initial 
policy whereby passwords must now contain at least one special character in 
addition to the other existing requirements. 
The passwords are tested, measured, and evaluated on a regular basis and any 
deviations from the standards or new technological impacts are addressed in a 
timely fashion. 

Chapter 6 102

Three Methods to Measure Security Controls 
There are three methods to measure the security controls in place in your system. 
Each of these methods can be used by any agency, depending on its needs and 
ability. Method 1 is a simple method of monitoring a security control and developing 
feedback on its success. That may be all an agency needs if the identified risk that the 
control was intended to mitigate is small. However, implementation of Methods 2 or 
3 may be warranted, depending on the complexity of the control being measured. 
 Method 1. Monitor the Level of Implementation and Develop Feedback 
This is perhaps the easiest and the most commonly used method to measure your 
security controls on a single system or application. Your team starts with an identified 
risk your agency chose to mitigate. Your team then extracts relevant data related to 
that risk from the system. Your agency reviews and processes these data to determine 
whether the security control has mitigated that risk in the manner the agency 
intended. This information can then be used as feedback into the policy development 
process to ensure compliance and that expectations are met. If they are not, this tells 
the agency that an improved control is needed. 
Monitor and Feedback example: 
One of your security controls may be that a confidential system containing 
criminal history information requires the reauthentication of the current 
user every 5 minutes. You develop a method to measure this control by 
implementing a program that extracts logs of personnel usage information 
and creates a report of how long your users were active before being 
challenged by an authentication request. If you determine that one or more 
sessions violate your standards, then the process is reviewed for changes 
that can be made so the original control is met. 
 Method 2. Analyze Multiple System Results 
This method looks at the measurement results developed for multiple individual 
systems or applications using the same process used in Method 1. Your policy team 
will then concurrently review and analyze the measurements from these activities and 
agency policies. This helps to develop an understanding of the overall security of the 
IT system and its security program. Based on this review, law enforcement managers 
can determine what changes should be made to multiple systems, if any, to achieve 
and or maintain the security controls originally established, based on the risk 
to the systems. 

Phase IVmeasure Your Security Controls 103 

Analyze Results example: 
Lets say that you determine that two or more persons are accessing 
a confidential program from multiple systems with authenticated 
connectivity to the program. The users do so within a 5-minute window. 
The agency can review the activity from multiple systems concurrently to 
determine if there is proper use occurring on their systems by these users. 
Based on this information, management evaluates the user controls in place 
to determine if they are effective. Any new decisions then feed back into the 
overall policy development process to help modify the agencys IT security 
policies, guidance documents, and/or procedures. 
 Method 3. Assess Overall Agency Effectiveness 
This method is used to determine whether an agencys overall information security 
program is effective and whether it meets or exceeds the agencys security goals and 
objectives. The team collects information using either Method 1 or 2. When compiled, 
these data are then used to provide senior managers with the organizations overall 
picture of information security health. Based on the analysis of these data, feedback 
is generated back into the policy development process so the agency can modify and 
improve its initial goals and objectives. 
Build Your Agencys Measures in Seven Steps 
Stop Sign Icon
There are 
commercial 
products that 
can assist you in 
building security 
measures. A quick 
Internet search will 
provide a list of 
those vendors. 
How do you build your security measurements? Again, we created a seven-step 
process to make building security measures easier (Figure 20). A worksheet for 
building each measurement, as described in this chapter, is provided in Appendix 
B. The worksheet is titled SEARCH IT Security Measurement Development 
Worksheet. We suggest you make numerous copies of this worksheet and get ready 
to build your measures! 
Tips Icon
The first two steps to building a measure require you to list an 
identified risk and the control(s) that management decided upon 
building a control process (Phase III, described in Chapter 5)! 
Therefore, you can pull this information directly from the SEARCH IT Security Control 
to mitigate this risk. You have already completed these steps in the 
Development Worksheet. 

Chapter 6 104

BuILdING A meASuremeNt 

Step 1 Identified risk - Start with an identified risk that your agency decided must be mitigated 
Step 2 Management control decision - List the control your agencys management decided upon to mitigate this risk 
Step 3 Existing measures - List any existing measures in place for assessing the effectiveness of this control 
Step 4 All other possible measures - List all possible measures that could be used to assess the effectiveness 
of this control 
Step 5 Measure implications - List the implications associated with each possible measure 
Step 6 Measure recommendation - Make a recommendation to management regarding measures to adopt 
Step 7 Measure implementation - Management decides which measure(s) to implement 

figure 20: the Seven Steps to Building a measurement 

Step 1
Start with an identified risk that your agency decided 
must be mitigated 
As we have already discussed, conducting a risk assessment of your systems results 
in identified areas of risk. In Chapter 5, we discussed controls your agency would 
develop and implement to mitigate these risks. Now, youll want to measure those 
controls to determine their effectiveness. 
In developing measures to assess these controls, you must first start with an identified 
area of risk. During Phase III, as outlined in Chapter 5, you already identified 
areas of risk and developed appropriate controls. This information was recorded 
on the SEARCH IT Security Control Development Worksheet. Use this 
information to help you fill out Steps 1 and 2 of the Security Measurement 
Development Worksheet. 
reminder: 
See Appendix B for 
the entire SEARCH 
IT Security Measurement 
Development 
Worksheet. 
Photocopy and 
use this worksheet 
to build your 
measures. 
As an example, lets say your agency, through the risk-assessment process, identified 
this risk: Your agency is not conducting thorough background screening of staff who 
had access to information systems. 
Write the identified risk in Step 1 of the Measurement Development Worksheet, as shown 
below, copying it from Step 1 of the Control Development Worksheet. 

Step 1: Identified risk 
Personnel who have not undergone thorough background checks have access to 
information systems. 

Phase IVmeasure Your Security Controls 105
 
Step 2 
List the control your agencys management decided 
upon to mitigate this risk 
In Step 2, you will list the control that management selected to mitigate the particular 
risk, as determined by your agency in Phase III. 
Write the management control decision in Step 2 of the Measurement Development 
Worksheet, as shown below, copying it from Step 6 of the Control Development Worksheet. 
Step 2: management control decision 
Conduct background investigations internally using our own employees. Training will 
be provided by a neighboring agency that conducts its own investigations. Access to 
a public information database will be purchased and a policy will be written to ensure 
that proper background investigations are conducted. 
Step 3 
List any existing measures in place for assessing the 
effectiveness of this control 
Your agency may already have some measures in place to assess the effectiveness of 
the control for which this measure is being built. Refer to the analysis you did during 
your self-assessment and the effectiveness rankings you identified during that part of 
the process to help you define these existing measures. 
List existing measures in place at your agency that assess the effectiveness of the control listed 
in Step 2 of the Worksheet. 
Step 3: existing measures 
New employees who will have access to the agencys IT systems must complete a 
personal history statement. 

Chapter 6 106

Step 4
List all possible measures that could be used to 
assess the effectiveness of this control 
Here your team should brainstorm all possible measures that could be used by your 
organization to gauge the effectiveness of the control. These should include all 
possibilities, regardless of their cost or effect on the system. Developing as complete a 
list as possible gives your team options for selecting the most 
appropriate measurements. 
Enter a list of all possible measures in Step 4 of the Worksheet. 
Step 4: All other possible measures 
 The agency will establish a policy requiring that background investigations be 
audited every 6 months to ensure that investigations are completed according to 
procedures. 
 The agency will complete an annual review of the training received by 
investigators who conduct the background investigations. 
 The agency will review the policy governing background investigations every 2 
years for currency. 
Step 5
List the implications associated with each possible measure 
Every suggested measure will have some implication for the agency. Those 
implications can include the cost of the measure, its installation, maintenance, and 
update. Your team should discuss and analyze these implications. 
Analyze the implications for all possible measures listed in Step 4, and enter them in Step 5 
of the Worksheet. 
Step 5: measure implications 
Personnel time expended to review measures. 

Phase IVmeasure Your Security Controls 107
 
Step 6
Make a recommendation to management regarding 
measures to adopt 
Review all of the possible measures your team has assembled and prepare a 
recommendation to the agencys executive management about the best measure(s) to 
implement. Determining which measures are best, as discussed in the steps leading 
up to your decision, is based on an evaluation of the risk, the controls you implement 
to mitigate the risk, the costs to implement the measure, and the expertise required to 
implement and maintain the measure. Your agency management will be 
expecting your team to provide a substantive recommendation for measuring the 
agencys controls. 
Enter your teams measure recommendation in Step 6 of the Worksheet. 
Step 6: measure recommendation 
 The agency will establish a policy requiring that background investigations be 
audited every 6 months to ensure that investigations are completed according to 
procedures. 
 The agency will complete an annual review of the training received by 
investigators who conduct the background investigations. 
Step 7
Management decides which measure(s) to implement 
Management now makes a decision as to the measure(s) to implement to evaluate the 
control listed in Step 2 of the Worksheet. Management may have a variety of possible 
measures to select fromany of which may effectively assess the control. In this 
example, the agency chooses a solution that is financially acceptable and effectively 
measures the control. 
Record managements measurement decision in Step 7 of the Worksheet. 
Step 7: measure implementation 
The Personnel Division commander will conduct an annual audit of the background 
investigations section to ensure that they are complying with the agency policy. 
As we near the end of this process, you have conducted a self-assessment (Chapter 3) 
of your systems, determined your security risks (Chapter 4), developed controls to 
mitigate the risks (Chapter 5), and in this chapter developed measures to assess the 
effectiveness of these controls. The next phase of the IT security policy development 
process is actually formalizing and writing your policy, discussed fully in Chapter 7. 

Producing an information security policy should 
not be seen as a difficult task. What is important 
is that it should give clear policy direction and 
management support for the implementation and 
maintenance of information security. Sound 
policies are the basis for good information security. 
Department of Trade and Industry, United Kingdom 

Chapter 7:
Formalize Your IT Security 
Policies

What 
Writing a security policy involves first reviewing your agencys self-assessment results 
and identifying your risks. Then it requires that you document your agencys risk 
decision process and prioritize your response. 
Why
Management is responsible for properly developing and implementing all 
organizational policies. A properly written policy allows for consistent administration 
of a formal information technology (IT) security plan agencywide. 
Who 
Agency leadership (chief, sheriff, and upper management) and the Security Policy 
Development Team. 
When 
This is the tricky part. You wont be able to complete your written policy until Phases I 
through IV have been finalized, but your documentation should begin as early as your 
self-assessment and continue as you work through the phases. 

Congratulations! If you have worked through the Tech Guide to this point, you have 
made it through the most rigorous aspects of completing your security policy. Now, 
all you have to do is formalize the policy for your organization. At this point, when 
you actually begin writing your agencys IT security policies, your team will have 
already completed significant areas of the policy development process. You will have 
completed a self-assessment and risk assessment of your systems; you will have 
determined controls to mitigate your identified risks; and you will have determined 
how you plan to measure the effectiveness of those controls. 
The process up to the point of formalizing your security polices has been a laborious 
endeavor for any agency. However, now that you and many others have completed 
the processes in this Tech Guide, you have a better understanding of your system, the 
risks associated with maintaining it, and, as a result, a rigorously developed policy 
statement. Your security policy is the foundation for providing continuous and effective 
information security for your agency. Now, quite frankly, all that is left to do is write it! 

Chapter 7 112 

Remember, a security policy is a document that spells out specific rules and adds 
structure to the organizations procedures. It gives your agency staff guidance 
regarding how they should act and respond to given events or situations. 
Also keep in mind what we told you in Chapter 1. Security policies must be: 
 Implementable 
 Enforceable 
 Responsible 
 Documented. 
Before you begin writing, here are some frequently asked questions about 
documenting security policies: 
Should the policy be specific or general in nature? 
Policy: A plan or 
course of action, as 
of a government, 
political party, or 
business, intended 
to influence 
and determine 
decisions, actions, 
and other matters. 
The answer is: It depends. Lets take an example that involved a large 
agency that had many different IT systems. When it came to password 
control, the security group agreed on what it considered an acceptable password 
policy at that time. However, because the agency had so many different systems 
(different operating systems and applications), its target password policy could not be 
technically implemented equally on all of its systems. 
So, what could be done? The security group had two choices: 
1) It could formulate an individual policy for each system or groups of systems 
that can be configured in the required manner. 
2) It could write one policy that includes a general exception or language that will 
accept the strongest password controls available on each system. 
As an example, if it chose the latter, the security group could develop a policy that 
looks something like this: 
All corporation IT computer systems will require a unique user ID and an 
eight-character password for access. In addition, the password may not be a 
dictionary word and it must contain at least one numeric or special character 
and at least one alphabetic character. If a system cannot be configured to 
meet this policy, the security group should be contacted immediately to 
gain an exception to this policy. It is managements goal to implement the 
strongest possible password controls on each IT system that cannot meet the 
above guidelines. 
Should the policy be all-inclusive or specific in nature? 
The answer, again, is: It depends. You may want to create a policy just for a specific 
system that has a specific solution. However, if other systems are then installed with 

Formalize Your IT Security Policies 113 

the same characteristics, you would have to go through the policy development 
process for each new system. 
A generalized policy statement dealing with encryption of the case history database 
might look something like this: 
All case investigation data shall be encrypted when stored on any department 
computer or IT server.
The implication of this policy is that not only should the case history database be 
encrypted, but if any investigation data are stored on department PCs or laptops, 
the data must also be encrypted. This greatly expands the scope of this policy. 
Management needs to provide guidance in this area if you want to generalize 
the policies. 
When should the policy be reviewed? 
Of course, that always depends on the agency involved, the size of the systems, 
and the perceived risks to the system. At a minimum, if no new risks arise, you 
should review your policy annually. However, that being said, if new risks arise or 
new systems or applications are put into service, then your agency should review all 
relevant policies to ensure that they still apply. Also, when conducting your review, 
maintain a record of your previous reviews and any changes you made. This will make 
reviewing a new policy easier if you have a record of the previous area of concern. 
Write an Information Security Policy in Six Steps 
How do you write security policies? Before you can even think about writing security 
policies, your agency must first complete the self-assessment and risk assessment 
of its IT systems. As described in earlier chapters, the purpose of these assessment 
processes is to fully identify the risks inherent in your systems. Only after a full system 
assessment can you successfully create and write comprehensive security policies. 
Once your team completed the risk assessment and identified the risks in your 
systems, the team presented this list of risks to your senior management. 
Management will have responded with thoughts about the risks that are acceptable 
and those that are not. (Remember the four levels of risk tolerance? They are avoid, 
assume, mitigate, or transfer.) In addition, management will have provided ideas 
on how much the unacceptable risks need to be reduced to be acceptable. 
How do you start writing your information security policies? We have developed 
a six-step process to make it easier to write these policies (Figure 21). A worksheet 
for writing your policy, as described in this chapter, is provided in Appendix B. The 

Chapter 7 114

worksheet is titled SEARCH IT Security Policy Development Worksheet. 
We suggest you make numerous copies of this worksheet and get ready to write 
your policies! 
Stop Sign Icon
Remember: your 
worksheets and risk 
statements should 
not be accessible to 
anyone outside of 
your organization. 
you do not want 
to advertise your 
vulnerabilities! 
This step-by-step process will help guide you through the process of writing your 
security policy. You should create one Security Policy Development Worksheet for 
each risk identified during the risk-assessment process. Only one risk should be 
enumerated on each sheet. Remember, these worksheets are not designed to be 
published. You really dont want to advertise what risks you have so the bad guys 
know where your weaknesses are! 

Writing An IT Security Policy
Step 1 Identified risk - Start with an identified risk that your agency decided must be 
mitigated (Phase II) 
Step 2 Management control decision - List the control your agencys management decided upon to mitigate 
this risk (Phase III) 
Step 3 Measure implementation - List the measure(s) your agency management decided to implement 
in order to assess the effectiveness of this control (Phase IV) 
Step 4 Existing policy - Document any existing policy the agency has that addresses the risk 
identified in Step 1 
Step 5 Proposed security policy - List any proposed security policy 
Step 6 Policy recommendation - Make a recommendation to management regarding security policy 
to adopt 

Figure 21: the Seven Steps to writing an It Security Policy 

Again, much of your writing here should be informed by the work completed in the 
preceding phases of your security policy development process, as outlined in Chapters 
3 through 6. For each step below, well indicate which source documents you should 
use to help complete that particular step. 
Source document 
Control 
Development 
Worksheet 
reminder: 
See Appendix B for 
the entire Security 
Policy Development 
Worksheet. 
Photocopy and 
use this worksheet 
when writing your 
policies. 
Step 1
Start with an identified risk that your agency decided 
must be mitigated (Phase II) 
Conducting a risk assessment of your system, as done in Phase II, results in specific 
identified areas of risk. Your agency will determine which ones to mitigate through 
the development of controls, as done in Phase III. 
Remember we said that writing a policy will build on work you have already done? 
Since you have already identified areas of risk, you can use that information now! 

Formalize Your IT Security Policies 115

Need a refresher 
course? 
Phase II: Identify 
risk areas 
(Chapter 4) 
Phase III: Select 
controls 
(Chapter 5) 
Phase Iv: Select 
measures 
(Chapter 6) 

The specific identified risk was recorded on the SEARCH IT Security Control 
Development Worksheet. Use this to help you fill out the Security Policy Development 
Worksheet. Lets use the same risk example cited earlier in this Guideinadequate 
background checks of agency personnel. 
Write the identified risk in Step 1 of the Policy Development Worksheet, as shown below, 
copying it from Step 1 of the Control Development Worksheet. 
Step 1: Identified risk 
Personnel who have not undergone thorough background checks have access to 
information systems. 
Step 2 
List the control your agencys management decided 
upon to mitigate this risk (Phase III) 
In Step 2, you will list the management control decision made to mitigate the risk, as 
determined by your agency in Phase III. 
Source document 
Control 
Development 
Worksheet 
Write the management control decision in Step 2 of the Policy Development Worksheet, as 
shown below, copying it from Step 6 of the Control Development Worksheet. 
Step 2: management control decision 
Conduct background investigations internally using our own employees. Training will 
be provided by a neighboring agency that conducts its own investigations. Access to 
a public information database will be purchased and a policy will be written to ensure 
that proper background investigations are conducted. 
Step 3 
List the measure(s) your agency management decided 
to implement in order to assess the effectiveness of 
this control (Phase IV) 
In Step 3, you will list the measure(s) your agency management implemented for this 
control, a task completed in Phase IV. Remember, the measure is intended to assess 
Source document 
the controls effectiveness at mitigating the stated risks. 
Measurement 
Development 
Worksheet 
Write the measurement implementation statement in Step 3 of the Policy Development 
Worksheet, as shown below, copying it from Step 7 of the Measurement Development Worksheet. 
Step 3: measure implementation 
The Personnel Division commander will conduct an annual audit of the background 
investigations section to ensure that they are complying with the agency policy. 

Chapter 7 116

Source documents 
Existing agency 
policy documents 
Documents 
collected during the 
self-assessment 
process 
Step 4
Document any existing policy the agency has that 
addresses the risk identified in Step 
Your agency may already have some policies in place to aid in the security of your 
systems. You should list all of them here that pertain to the statement identified in 
Step 1. Refer to the analysis you did during your self-assessment exercise and the 
effectiveness rankings you identified during that exercise to help you identify 
these policies. 
In Step 4 of the Worksheet, document any existing policy the agency has that relates to the 
risk identified in Step 1. 
Step 4: existing policy 
No current policy statement exists within the agency for this identified risk. 
Step 5
List any proposed security policy 
Now lets write your proposed security policy. This is where you actually begin to create 
the policy statement for this risk, which can be used to guide your organization. The 
policy statement should focus only on the item listed in Step 1. You are merely trying 
to (a) create a policy that (b) refers to the measurement that (c) is related to a specific 
control that (d) deals with a specific identified risk in your organization. The policy 
statement should not simply reiterate the identified risk stated in Step 1. The policy 
should be as clear and unambiguous as possible. 
Things to consider when writing a policy statement: 
Who will be affected by the policy? 
Describe what portion of the agency will be affected by this policy. You need to 
clearly describe the roles and responsibility of those who will implement the policy 
and for anyone else the policy affects. 
What will be allowed and what will not? 
The policy should describe not only what will be allowed, but what will not be 
allowed. It is important to clearly define the things that your personnel can and 
cannot do. 

Formalize Your IT Security Policies 117

What will happen if the affected agency personnel do not comply
with the policy?
Compliance is always an important factor in policy development. Your policy 
should clearly delineate what will happen if personnel fail to comply with the 
policy or any of its provisions.
Record your agencys proposed policy statement in Step 5 of the Worksheet. 
Step 5: Proposed security policy
This policy will affect all members of the agency. The agency will immediately begin 
conducting thorough background checks of all employees, civilian or sworn, who 
have access to agency systems. The checks will be conducted by the background 
unit, which will be an ancillary responsibility of the Detective Division commander. 
Any personnel failing to complete the background process will be administratively 
suspended until such time as the background can be properly completed. Personnel 
who, through the investigation, do not obtain a satisfactory background check shall be 
referred to the personnel section for reassignment within the agency. 
Step 6
Make a recommendation to management regarding 
the security policy to adopt 
The IT security policy team makes a recommendation to the agency management 
about the security policy that it has determined should be adopted. Using the Security 
Policy Development Worksheet, your team can show management the lengthy and 
in-depth process involved in making a policy determination for the agency. With the 
recommendation and the supporting development process in hand, your executive 
management can make a well-educated policy determination. 
Record your teams security policy recommendation in Step 6 of the Worksheet. 
Step 6: Policy recommendation 
 This policy will affect all new employees who have been given a conditional offer 
of hire. 
 A thorough background check of the new hire will be completed prior to the 
persons assignment to a position that will give him or her access to the agencys 
system. 
 Under the direction of the commander in charge of Administration, the detectives 
assigned to background investigations will conduct a thorough background 
check according to the procedures developed at the direction of the commander 
and approved by the chief of the agency. 
 Due to the sensitive nature of the background check process, only the 
commander in charge of Administration, the agency assistant chief, the 
agency chief, and the agency counsel will be allowed to review the completed 
background information. 
 New hires failing to complete the background process will be promptly notified 
of their status and referred to the personnel section. 

118

Conclusion
Throughout this process you have evaluated your agency and its systems. You 
looked at the systems and determined their associated risk. You have developed 
controls and measurements for those controls. Last, you have worked on 
developing policy based on all the reviews you have completed of your system. 
Each step in the process of writing the IT security policy has been fed from 
another phase of the process. The work you did in each phase has helped to 
determine the direction that your organization desired to take. 
Based on everything you have done up to this point, you will have a better 
understanding of your system. You will have developed a cohesive working group 
to determine future risk to the system. You will have developed controls that will 
assist you in protecting your system. By implementing a process for regularly 
assessing the effectiveness of those controls, you will also have developed 
measures that will help to maintain the security of your system. Finally, you will 
have developed a set of comprehensive policy statements that can help to guide 
your agency with its continuing requirements to protect your systems. 

Appendix A:
Assessment Worksheets
and Questions
from the 
SEARCH IT Security Self- and Risk-Assessment Tool 

SEARCH Icon
The Assessment 
Tool was developed 
using Microsoft 
Excel. If you do 
not have this 
application, you 
can download a 
free Excel reader 
at www.microsoft. 
com/downloads. 
The following are the assessment questions from the SEARCH IT Security 
Self- and Risk-Assessment Tool, a Microsoft Excel-based spreadsheet tool that 
enables an agency to perform assessments of its IT systems. (See Chapter 3 for 
an overview of this Assessment Tool, which can be downloaded at 
www.search.org.) 
The questions are listed here to enable you to replicate the exercises in this 
Assessment Tool spreadsheet on paper. This appendix includes the following: 
 Blank Effectiveness Ranking/Risk Decisions response worksheets. We 
recommend that you photocopy additional copies of these because you 
will fill one copy of these out for each question in the Assessment Tool. 
The response worksheets include these fields: 
-Effectiveness Ranking, Levels 1 through 5. 
-Description of Identified Risk (a narrative text description). 
-Risk Decisions, which include Likelihood, Severity, Risk Tolerance, 
and Action Priority.
-Comments (narrative text).
 An Effectiveness Ranking table, which describes the five effectiveness 
ranking levels, includes comments on each level that are available in the 
online Assessment Tool, and provides the appropriate response key (Y for 
yes, N for no, Partial, N/A). 
 A Risk Decisions table, which lists the four types of risk decisions that 
need to be answered for each identified risk, and provides the appropriate 
response key for each risk decision. 

Appendix A 122

 Eighteen groups of assessment questions, which are divided into four main categories. 
The questions include reference document notations, and comments, if any. 
Management 
1. Risk Management 
2. Review of Security Controls
3. Lifecycle 
4. Authorize Processing (Certification and Accreditation) 
5. System Security Plan 
Operational 
6. Personnel Security 
7. Physical and Environment Protection 
8. Production, Input/Output Controls 
9. Contingency Planning 
10. Hardware and System Software Maintenance 
11. Data Integrity 
12. Documentation 
13. Security Awareness, Training, and Education 
14. Incident Response Capability 
Technical 
15. Identification and Authentication 
16. Logical Access Controls 
17. Audit Trails 
State and Local Law enforcement-Specific It Security 
18. FBI CJIS Compliance 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 123 

Question # ____________
Effectiveness Ranking 
Descriptionof Identified Risk 
Risk Decisions 
commentsLevel 1 Level 2 Level 3 Level 4 Level 5 Likelihood Severity Risk Tolerance 
ActionPriority 
Question # ____________
Effectiveness Ranking 
Descriptionof Identified Risk 
Risk Decisions 
commentsLevel 1 Level 2 Level 3 Level 4 Level 5 Likelihood Severity Risk Tolerance 
ActionPriority 

Appendix A 124

LEvEL 1: Documented Policy 
Does your agency have a formally documented and disseminated policy on that security control? 
Does the policy define 1) purpose and scope of the policy, 2) responsibilities required for its 
execution, and 3) compliance requirements and penalty specification? 

LEvEL 2: Documented Procedures 
Does your agency have formal, complete, and well-documented procedures for the policies 
defined at level 1? 
Do the procedures: 
 List the control areas and clearly state the agencys position? 
 Document their applicabilityclearly list when, where, how, to whom, and about what the 
procedure applies? 
 List the assignment of IT responsibilities and define explicit behavior? 
 Identify points of contact and where supplementary information can be found? (not applicable)

LEvEL 3: Implemented Procedures and Controls 
Have the procedures and controls been implemented? 
Are the following statements true? 
 Are the owners and users aware of the security policies and procedures? 
 Have the policies and procedures been formally adopted and the technical controls installed? 
 Is a security metrics program in place? (ongoing security compliance measurement) 
 Has management formally authorized the use of the system? 
 Have employee job descriptions been updated to include security responsibilities that the 
implemented controls require? 
 Have employees been trained on security procedures? 

LEvEL 4: Tested and Evaluated Procedures and Controls
Is a metrics program in place that routinely evaluates the adequacy and effectiveness of security 
policies, procedures, and controls? 
Are the following elements in place? 
 An effective program for evaluating the adequacy and effectiveness of security policies, 
procedures, and controls. 
 A mechanism for identifying vulnerabilities revealed by security incidents or security alerts. 
 A process for reporting significant security weaknesses and ensuring rapid and effective 
remedial action. 

LEvEL 5: Fully Integrated Procedures and Controls 
Does your agency have a fully operational, comprehensive security program that is an integral 
part of your agencys culture? 
Are the following statements true? 
 There is an active agencywide security program that achieves cost-effective security. 
 IT security is an integrated practice within the asset (IT system). 
 Security vulnerabilities are understood and managed. 
 Threats are continually reevaluated, and controls are adapted to a changing security 
environment. 
 Additional and/or more cost-effective security alternatives are identified as the need arises. 
 Costs and benefits of security are measured as precisely as practicable. 
 Status metrics for the security program are established and met.

Each Level must be answered with a Yes, No, Partial, or N/A (Not Applicable)

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 125

Risk Decision Response Key 
Likelihood 
REMOTE: The risk probably will not occur because the risk would be difficult to realize, or there are 
solid means in place to limit the risk appropriately. 
POSSIBLE: The risk has a chance of occurring, but it may be difficult or there are controls in place to 
help avoid the risk. 
LIKELY: Due to conditions and capabilities, the risk is likely to occur. 
Severity 
LOW: The risk is manageable through planning and action, and the impacts generally are minimal. 
MEDIUM: The risk will be mitigated through planning and action, although if it occurs, it will still 
have some impact on some of the more important areas of concern. 
HIGH: The risk will have serious impacts and without extensive planning and action, its 
consequences would be severe. 
Risk Tolerance
AVOID: Avoidance is often used for risks that have the capacity for negative impact, but have little 
known recourse. In security projects, a decision to avoid risks often means a decision not to let your 
agency put itself in the situation where it could incur the risk. Therefore, your decision would also be 
to avoid the cause of the risk. 
ASSUME: The decision to assume a risk means accepting the risk as-is, and not implementing any 
policies or procedures to lessen it. This is often the decision in cases where the risk is so minimal 
and of limited impact should it occur that the cost of implementing a mechanism to minimize or 
reduce it would be far greater than the agencys concern. 
MITIGATE: This is the most common decision to make for identified risks: to implement policies, 
procedures, and other security controls to limit the risk to an acceptable level. 
TRANSFER: Transfer the responsibility for a system or the risk itself to another party that can better 
accept and deal with the risk and/or has the resources necessary to properly mitigate the risk. 
Action Priority 
Ranking the risk according to your categorization, quantification, and tolerance of each based on the 
likelihood, severity, and tolerance levels. This simple weighting allows for the agency to easily rank 
the priority of action required to eliminate the greatest risks first. 
Examples of possible weighting: 
1 = Likely + High + Assume 
2 = Possible + Medium + Mitigate 
3 = Remote + Low + Transfer 

Appendix A 126

MANAGEMENT 
1. Risk Management
Ref: NIST SP 800-53 RA-2; OMB Circular A-130, III
ASSESSMENT QUESTIONS 
1.1. Critical Element: Is risk periodically assessed?
Ref: None
1.1.1 Is the current system configuration documented, including links to other systems? 
Ref: None 
1.1.2 Are risk assessments performed and documented on a regular basis or whenever the 
system, facilities, or other conditions change, and is management made aware of 
any new risks? 
Ref: None 
1.1.3 As changes are made to the system, are risk assessments completed and presented to 
management? 
Ref: None 
1.1.4 Have data sensitivity and integrity of the data been considered? 
Ref: NIST SP 800-53 RA-2; FISCAM SP-1 
1.1.5 Have threat sources, both natural and man-made, been identified? 
Ref: NIST SP 800-53 RA-3; FISCAM SP-1 
1.1.6 Have you identified, documented, and maintained a current list of known system 
vulnerabilities, system flaws, or weaknesses that could be exploited by threat 
sources? 
Ref: NIST SP 800-53 CA-5, RA-3; NIST SP 800-30 
1.1.7 Has an analysis been conducted that determines whether the security requirements 
in place adequately mitigate vulnerabilities? 
Ref: NIST SP 800-53 RA-3; NIST SP 800-30 
1.2. Critical Element: Does the manager responsible for the system understand 
the risk to systems under his or her control and determine the acceptable 
level of risk? 
Ref: None 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 127

1.2.1 Are final risk determinations and related management approvals documented and 
maintained on file? 
Ref: NIST SP 800-53 RA-3; FISCAM SP-1 
1.2.2 Has a mission/business impact analysis been conducted? 
Ref: NIST SP 800-53 RA-3; NIST SP 800-30 
1.2.3 Have controls been identified to sufficiently mitigate identified risks? 
Ref: NIST SP 800-53 CA-5, RA-3; NIST SP 800-30 
COMMENTS 
1.1 IT systems exist in ever-changing environments. Consequently, the risk profile 
of your IT system changes over time. Does your agency have any policy that 
requires a reassessment of IT system risk on a periodic basis? This needs 
to be done to manage the overall risks of the IT system and keep the level of risks 
acceptable to management. 
1.1.1 In order to understand the risks to your IT system, the system must be fully 
documented. At a minimum, it should contain the following: 1) a description of all 
functions, 2) a data dictionary of all data collected / used by the system, and 3) a 
description of all reports / output data. In addition, links to other systems must be 
fully documented. This documentation should contain: 1) a description of the link 
(what it is, how it is established, and so forth), and 2) a description of the data sent 
over the link and under what circumstances. 
1.1.2 Your agency should have a policy that requires periodic security reassessments of 
IT systems. Your agency should document the results of the assessments and store 
them for reference. 
1.1.4 Sensitive data  Any data whose release could cause adverse consequences to your 
agency. 
Data integrity  The high probability that data are not altered inadvertently. 
All data collected and processed in your IT system should be classified as to their 
sensitivity and by their integrity requirements. Data such as social security numbers, 
child protective services case data, and investigative data would be considered 
sensitive data. Data such as drug test results would require a high level of integrity. 

Appendix A 128

1.1.5 Threat  The potential that something bad may happen to your IT system. 
Some natural threat sources are earthquake, tsunamis, or fire. Some man-made 
threat sources are theft of hardware, fire, hacking, theft of data, etc. 
1.1.6 Your agency should have a policy in place that requires a periodic assessment of the 
potential threats to your IT system. Write this list down and maintain it. 
Your agency will need to conduct research to determine what threats might apply to 
your IT system. If you are using commercial software, your vendor may be able to 
help you with the list. 
1.1.7 This question assumes the following: 
1) An existing security policy program is in place. 
2) Your management team has reviewed the prepolicy risks and recommended 
security policies. 
3) You have developed security controls, contained within security policies, that 
are expected to reduce the risks to acceptable levels. 
From the above information, you need to determine the probability that the security 
controls will reduce the risk exposures down to levels that are acceptable to the 
management team. 
1.2 Management must be involved in all levels of risk-management activities. 
Senior management sets and determines the acceptable risk levels for your agency. 
1.2.1 Written records are one of the keys to an effective risk-management program. 
Without written records, you cannot keep track of where your agency started or why 
the decisions were made to bring you to where you are now. 
1.2.2 The risk-management process first identifies risks associated with your IT system. 
The impact analysis refers to what would happen if one or more of these risks 
became reality. The impact focuses on the three security goals of integrity, 
availability, and confidentiality. You need to quantify, for each risk, the loss of 
integrity, the loss of availability, and the loss of confidentiality. 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 129

2. Review of Security Controls 
Ref: NIST SP 800-53 CA-1; OMB Circular A-130, III; 
FISCAM SP-5; NIST SP 800-18 
ASSESSMENT QUESTIONS 
2.1. Critical Element: Have the security controls of the system and 
interconnected systems been reviewed? 
Ref: None 
2.1.1 Has the system and all network boundaries been subjected to periodic reviews? 
Ref: NIST SP 800-53 CA-2; FISCAM SP-5.1 
2.1.2 Has an independent review been performed when a significant change occurred? 
Ref: NIST SP 800-53 CA-4; FISCAM SP-5.1; OMB Circular A-130, III; 
NIST SP 800-18 
2.1.3 Are routine self-assessments conducted? 
Ref: NIST SP 800-53 CA-2; NIST SP 800-18 
2.1.4 Are tests and examinations of key controls routinely made, i.e., network scans, 
analyses of router and switch settings, penetration testing? 
Ref: NIST SP 800-53 CA-2; OMB Circular A-130, 8B3; NIST SP 800-18 
2.1.5 Are security alerts and security incidents analyzed and remedial actions taken? 
Ref: NIST SP 800-53 IR-4; FISCAM SP-3-4; NIST SP 800-18 
2.2. Critical Element: Does management ensure that corrective actions are 
effectively implemented? 
Ref: None 
2.2.1 Is there an effective and timely process for reporting significant weakness and 
ensuring effective remedial action? 
Ref: NIST SP 800-53 CA-4; FISCAM SP-5.1, 5.2; NIST SP 800-18 
COMMENTS 
2.1 Very few IT systems are stand-alone systems. Most systems receive data from and/or 
supply data to other systems. The security of your target system under review is 
dependent on the security of these other systems. It is critical that you identify ALL 
interconnected systems and understand how they relate to your target system. 

Appendix A 130

Management has the responsibility to request a review of these security 
interrelationships. 
2.1.1 Systems and networks change all the time. You should have a policy in place that 
requires a formal review of system and network interconnections relating 
your IT systems. 
2.1.2 A common human tendency is to be oblivious to various facts at various times. 
It is simply difficult for any single person to see all the security issues concerning 
a particular IT system. An independent review brings another set of eyes to look 
at your system and perhaps see things that you missed. You should encourage 
independent reviews of your system to gain this perspective. 
2.1.3 The self-assessment process is not an all-or-nothing activity. You may choose to do 
a simple self-assessment on an annual basis for small systems. Only if you identify 
that complex changes have occurred should you do a more in-depth self-assessment. 
It is really up to you to determine how often self-assessments should be conducted. 
2.1.4 These tests and examinations are part of the security measurement program. The 
purpose of this program is to establish ongoing tests to verify that your security 
controls (which derive from your security policies) are effective in reducing risks as 
expected. These tests and subsequent reporting should be as automated as possible 
to reduce the possibility that someone will fail to accomplish a required task. 
2.1.5 This activity is part of the security metric program. You should verify that 
management has appointed a person or a group that is responsible for reacting to 
and handling security alerts and incidents. 
2.2 Management should mandate that corrective actions must be implemented for 
security issues. This will generally require some form of communication on security 
issues to be presented to management on a recurring basis. 
2.2.1 Identify how management has elected to receive input on security matters. If there is 
no formal process, a process needs to be created to ensure effective communication. 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 131

3. Lifecycle 
Ref: NIST SP 800-53 SA-1; OMB Circular A-130, III; FISCAM CC-1.1 
ASSESSMENT QUESTIONS 
3.1. Critical Element: Has a system development lifecyle methodology been 
developed? 
Ref: None 
Initiation Phase 
3.1.1 Is the sensitivity of the system determined? 
Ref: NIST SP 800-54 RA-1; OMB Circular A-130, III; FISCAM CC-1.1, 1.2; NIST SP 
800-18 
3.1.2 Does the plan document the resources required to adequately secure the system? 
Ref: NIST SP 800-53 SA-2; Clinger-Cohen 
3.1.3 Are authorizations for software modifications documented and maintained? 
Ref: NIST SP 800-53 CM-3; FISCAM CC-1.1 
3.1.4 Does the budget request include the security resources required for the system? 
Ref: NIST SP 800-54 RA-1; GISRA 
Development/Acquisition Phase 
3.1.6 During the system design, are security requirements identified? 
Ref: NIST SP 800-54 SA-4; NIST SP 800-18 
3.1.7 Was an initial risk assessment performed to determine security requirements? 
Ref: NIST SP 800-54 RA-3, SA-4; NIST SP 800-30 
3.1.8 Is there a written agreement with program managers on the security controls 
employed and residual risk? 
Ref: NIST SP 800-54 RA-3; NIST SP 800-18 
3.1.9 Are security controls consistent with and an integral part of the IT architecture of 
the agency? 
Ref: NIST SP 800-54 CM-2; OMB Circular A-130, 8B3 
3.1.10 Do the solicitation documents (e.g., requests for proposals) include security 
requirements and evaluation/test procedures? 
Ref: NIST SP 800-54 SA-4; NIST SP 800-18 

Appendix A 132

3.1.11 Do the requirements in the solicitation documents permit updating security 
controls as new threats/vulnerabilities are identified and as new technologies are 
implemented? 
Ref: NIST SP 800-54 SA-4; NIST SP 800-18 
Implementation Phase 
3.2. Critical Element: Are changes controlled as programs progress through 
testing to final approval? 
Ref: None 
3.2.1 Are design reviews and system tests run prior to placing the system in production? 
Ref: NIST SP 800-54 SA-8, SA-11; FISCAM CC-2.1; NIST SP 800-18 
3.2.2 Are the test results documented? 
Ref: NIST SP 800-54 SA-8, SA-11; FISCAM CC-1.1, 1.2; NIST SP 800-18 
3.2.3 If required to meet a required federal standard, is certification testing of security 
controls conducted and documented? 
Ref: NIST SP 800-54 CA-4, SA-5; NIST SP 800-18 
3.2.4 If security controls were added since development, has the system documentation 
been modified to include them? 
Ref: NIST SP 800-54 SA-5; NIST SP 800-18 
3.2.5 If security controls were added since development, have the security controls been 
tested and the system recertified? 
Ref: NIST SP 800-54 CA-4; FISCAM CC-2.1; NIST SP 800-18 
3.2.6 Has the application undergone a technical evaluation to ensure that it meets 
applicable state, local, and federal laws, regulations, policies, guidelines, and 
standards? 
Ref: NIST SP 800-54 SA-11; NIST SP 800-18 
Operation/Maintenance Phase 
3.2.7 Has a system security plan been developed and approved? 
Ref: NIST SP 800-54 S5-1; OMB Circular A-130, III; FISCAM CC-2.1; NIST SP 800-18 
3.2.8 If the system connects to other systems, have controls been established and 
disseminated to the owners of the interconnected systems? 
Ref: NIST SP 800-54 CA-3; NIST SP 800-18 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 133

3.2.9 Is the system security plan kept current? 
Ref: NIST SP 800-54 PL-3; OMB Circular A-130, III; FISCAM CC-2.1; NIST SP-800-
18 
Disposal Phase 
3.2.10 Are official electronic records properly disposed of or archived? 
Ref: NIST SP 800-54 MP-6; NIST SP 800-18 
3.2.11 Are information or media purged, overwritten, degaussed, or destroyed when 
disposed of or used elsewhere? 
Ref: NIST SP 800-54 MP-6, MP-7; OMB Circular A-130, III; FISCAM CC-AC-3.4; 
NIST SP 800-18 
3.2.12 Is a record kept of who implemented the disposal actions and verified that the 
information or media were sanitized? 
Ref: NIST SP 800-54 MP-6, MP-7; NIST SP 800-18 
COMMENTS 
3.1 If your agency is considering implementing a major IT system, then you need to 
select one of the several system development life cycle methodologies available. It 
is not that one methodology is better that another, but it is far more important that 
one is selected and followed for the life of the project. 
3.1.1 The NIST guide SP 800-30 can assist you in determining the sensitivity of the 
system. The sensitivity of the system may be driven by the nature of the data or by 
specific legislation. In any event, you should understand why the system is sensitive 
before you begin the risk management process. 
3.1.2 The required elements to secure your system may come from several sources. Some 
of the sources may be: 
1) Management directive. 
2) Legislation. 
3) External controls (i.e., the FBI Criminal Justice Information Services [CJIS] 
Divisions CJIS Security Policy). 
3.1.3 As part of the security management process, your agency should record and file all 
changes to the system. This information is then referenced during subsequent self-
assessment activities. This is the only way you can successfully track modifications to 
and maintenance of your IT systems. 

Appendix A 134

3.1.4 Security needs to be designed into the system, not added on later. It is significantly 
less expensive to add security during the design process than after the system has 
been implemented. 
3.1.6 During or before system design, your agency should identify security risks through 
analysis of the data to be processed and/or research of legislation controlling or 
driving the process. 
3.1.7 The risk-assessment process is the best way to establish IT system security 
requirements. 
3.1.8 Since security controls may be implemented in various areas outside your agency, 
the agreements with outside entities should be in writing. 
For example: Assume your county IT department is responsible for all IT system 
operations. If your agency is running a sensitive application, then it would be 
reasonable that the systems manager perform background checks on all system 
personnel. Agreements of this type should be in writing. 
3.1.9 The first issue is: What is an IT architecture? 
An IT architecture is a set of decisions that describe how an IT system should be 
constructed, how the structural elements of the system should be created, and what 
the relationships should be between those elements. It is unlikely that your agency 
has an IT architecture. However, an IT architecture can be quite simple and 
very general. 
If your agency has an IT architecturewhich is really a set of design parameters 
that is applied generally to all systems in your organizationthen you can answer 
this question: If you have an IT architecture, does the specific system under review 
adhere to those parameters? If not, then you need to explain the differences and 
why the system deviates from the standards established for your agency. 
3.1.10 This question simply asks if security planning is part of the process. 
3.1.11 Does your agency, when contracting with outside suppliers, include security 
requirements and/or security specifications, either explicitly or by reference, in IT 
system acquisition contracts based on an assessment of risk? In other words, can the 
system be updated to handle new risks that are discovered during the lifetime of 
the system? 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 135

3.2.1 It is prudent to verify the proper operation of a system before it is placed 
into production. 
3.2.2 Like the rest of the risk management process, all test results should be documented. 
3.2.3 In support of the security accreditation process, the organization conducts an 
assessment of the security controls in the information system to determine the 
extent to which the controls are implemented correctly, operating as intended, and 
producing the desired outcome with respect to meeting the security requirements 
for the system. 
3.2.4 Is your documentation up to date? 
3.2.5 Depending on the complexity of the changes, you may choose to retest the system to 
verify proper operation of the security controls. 
3.2.6 This is one area that will require some investigation to determine what laws apply to 
your IT system. Since each state is different, you will need to have legal assistance to 
determine what legislation or policies apply to your system. 
For example, if you are a law enforcement agency and are using the FBIs National 
Crime Information Center (NCIC), then you will need to comply with CJIS Security 
Policy Version 4.0. 
3.2.7 The organization should ensure that 1) adequate documentation for the IT system 
and its constituent components is available, 2) it protects the documentation when 
required, and 3) distributes the documentation to authorized personnel. 
3.2.8 A security policy simply states what needs to happen. Security controls are either the 
programs or procedures that actually implement the intent of the security policies. 
For example, if you had a security policy that said all passwords must be at least 
eight characters in length, then the security control(s) would be anything that helped 
to enforce this policy. Depending on the system, the control may simply be a part of 
a configuration window that enforces a certain password length. For other systems, 
it may be a short section of code that controls the minimum password length. 
The question assumes that your agency has security policies that cover the security 
aspects of what happens when external systems interface with your systems. It also 
assumes that you have developed security controls that implement and enforce your 
security policies and that they have been designed for these foreign systems. The 
question is simply asking whether you have given these controls to the owners of the 
foreign systems and if they have been implemented. 

Appendix A 136

For example: You are responsible for the IT system that is used by child protective 
services. Another agency in the county government needs to have access to some 
of the data to do its job. Because of the sensitivity of the data and the legislation 
covering the use of the data, you have created a security policy that states that all 
users of the system must be identified before they can access the data. The other 
agency is using a batch program to access and process this data. Because of your 
policy, you need to be assured that security controls are in place so that only the 
authorized batch program has access to your data. Whether you developed the 
controls, or the other agency did, you need to verify that the controls are in place 
and effective in controlling access to your data. 
3.2.9 Is it the intent of management to fund the staff necessary to keep the security 
plan current? 
3.2.10 Official is whatever your policies say they are or how any controlling legislation 
defines them. The responsibility to dispose of or archive records rests solely on the 
legislative or policy definitions of the data. 
For example, if you have a database of what your group orders for lunch once 
a week, there probably would not be any issues connected with the disposal or 
archiving of this data. However, if you happen to have a backup tape that contains 
case records from child protective services, it is doubtful that you would be 
permitted to throw the tape away if part of the tape is thought to be defective. 
3.2.11 Do you have proven procedures and/or mechanisms to enable you to truly purge 
and/or destroy data? 
3.2.12 Depending on the classification or sensitivity of the data to be destroyed, do you 
keep records of these actions? 

Assessment Worksheets and Questions
from the SeArCH IT Security Self- and risk-Assessment Tool 137

4. Authorize Processing (Certification and Accreditation) 
Ref: NIST SP 800-53 CA-1; OMB Circular A-130, III; FIPS 102 
ASSESSMENT QUESTIONS 
4.1. Critical Element: Has the system been certified/recertified and authorized to 
process (accredited)? 
Ref: None 
4.1.1 Was a technical and/or security evaluation completed or conducted when a 
significant change occurred? 
Ref: NIST SP 800-53 CA-4; NIST SP 800-18 
4.1.2 Was a risk assessment conducted when a significant change occurred? 
Ref: NIST SP 800-53 RA-4; NIST SP 800-18 
4.1.3 Have rules of behavior been established and signed by users? 
Ref: NIST SP 800-53 PL-4; NIST SP 800-18 
4.1.4 Has a contingency plan been developed and tested? 
Ref: NIST SP 800-53 CP-2, CP-4; NIST SP 800-18 
4.1.5 Has a system security plan been developed, updated, and reviewed? 
Ref: NIST SP 800-53 PL-4; NIST SP 800-18 
4.1.6 Are in-place controls operating as intended? 
Ref: NIST SP 800-53 CA-4; NIST SP 800-18 
4.1.7 Are the planned and in-place controls consistent with the identified risks and the 
system and data sensitivity? 
Ref: NIST SP 800-53 RA-3; NIST SP 800-18 
4.1.8 Has management authorized interconnections to all systems (including systems 
owned and operated by another program, agency, organization, or contractor)? 
Ref: NIST SP 800-53 CA-3; NIST SP 800-18 
4.2. Critical Element: Is the system operating on a temporary or interim 
authorization in accordance with specified agency procedures? 
Ref: None 
4.2.1 Has management initiated prompt action to correct deficiencies? 
Ref: NIST SP 800-53 CA-5; NIST SP 800-18 

Appendix A 138

COMMENTS 
4.1.1 This activity is part of the security measurement process. Simply stated: A 
significant change could 1) increase risk, and/or 2) reduce risk, and/or 3) render 
existing security controls ineffective. The security evaluation is necessary to detect 
these potential changes. 
4.1.2 Depending on the complexity of the change, you may choose to do a full risk 
assessment on the system. 
4.1.3 Do the people using the system know how to treat the data under their care? A 
signed agreement with each employee working on sensitive data is perhaps the best 
way to communicate the proper behavior. 
4.1.4 All agencies or businesses should have a contingency plan for business continuity. If 
you dont have one, your agency should develop such a plan. 
4.1.5 This question is simply asking whether the system security plan is authorized by the 
proper authority. 
4.1.6 Part of the security measurement process includes the monitoring of security 
control operations. The processes to monitor the controls should be as automated 
and cost effective as possible. 
4.1.7 Was the security policy development process followed? Did management review 
the risks discovered during the self-assessment and approve the security controls 
necessary to mitigate the risks to levels acceptable to the agency? 
4.1.8 Management should be aware of all interconnections to external systems. This 
notification should be part of standard operating procedures. 
4.2.1 Has management funded and staffed personnel to handle security issues? Is there a 
charter that directs staff to deal with security issues promptly? 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 139

5. System Security Plan 
ASSESSMENT QUESTIONS 
5.1. Critical Element: Is a system security plan documented for the system and all 
interconnected systems if the boundary controls are ineffective? 
Ref: None 
5.1.1 Has the system security plan been approved by the managers of the affected parties 
(stakeholders) within and outside of the agency? 
Ref: NIST SP 800-53 PL-2; FISCAM SP-2.1; NIST SP 800-18 
5.1.2 Does the plan contain the topics prescribed in NIST Special Publication 800-18? 
Ref: NIST SP 800-53 PL-2; NIST SP 800-18 
5.1.3 Is a summary of a systems security plan incorporated into the agencys strategic 
information resources management plan? 
Ref: NIST SP 800-53 SA-2; OMB Circular A-130, III; NIST SP 800-18 
5.2. Critical Element: Is the plan kept current? 
Ref: None 
5.2.1 Is the plan reviewed periodically and adjusted to reflect current conditions and 
risks? 
Ref: NIST SP 800-53 PL-2; FISCAM SP-2.1; NIST SP 800-18 
COMMENTS 
5.1.1 Your agency management needs to be involved, as do external stakeholders. 
5.1.2 The NIST topics are guidelines onlygood guidelines, but not mandated. 
5.1.3 The security plan should be a part of an Information Resources Management (IRM) 
plan, which is an overarching plan that: 
1) Supports enterprise and agency vision, mission, goals, and objectives. 
2) Aligns the IT budget with the business plan. 
3) Identifies and tests innovative ways to use technology to serve customers and 
expand opportunities for public access. 
4) Improves agency efficiency by effectively managing information and 
technology. 

Appendix A 140

5) Promotes partnerships with other agencies, local/regional jurisdictions, and 
the private sector to create mutually beneficial IRM communities. 
6) Demonstrates compliance with city/county/state technical architecture 
and standards through IT asset inventory and the creation of application 
portfolios. 
7) Identifies IT and technical staff resources and training needs. 
5.2.1 All plans should be reviewed periodically and adjusted for changes in the 
environment. 
OPERATIONAL 
6. Personnel Security 
Ref: NIST SP 800-53 CA-1; OMB Circular A-130, III; FISCAM SP5; 
NIST SP 800-18 
ASSESSMENT QUESTIONS 
6.1. Critical Element: Are duties separated to ensure least privilege and 
individual accountability? 
Ref: None 
6.1.1 Are all positions reviewed for sensitivity level?
Ref: NIST SP 800-53 CA-2; FISCAM SP-5.1
6.1.2 Are there documented job descriptions that accurately reflect assigned duties and 
responsibilities and that segregate duties? 
Ref: None 
6.1.3 Are sensitive functions divided among different individuals? 
Ref: None 
6.1.4 Are distinct systems support functions performed by different individuals? 
Ref: NIST SP 800-53 CM-5; FISCAM SD-1.1 
6.1.5 Are mechanisms in place for holding users responsible for their actions? 
Ref: NIST SP 800-53 PS-6; OMB Circular A-130, III; FISCAM SD-2, 3.2; NIST SP 
800-18 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 141

6.1.6 Are hiring, transfer, and termination procedures established for personnel who have 
access to sensitive agency IT data? 
Ref: NIST SP 800-53 PS-2, PS-5; FISCAM SP-4.1; NIST SP 800-18 
6.1.7 Is there a process for requesting, establishing, issuing, and closing user accounts? 
Ref: NIST SP 800-53 PAC-2; FISCAM SP-4.1; NIST SP 800-18 
6.2. Critical Element: Is appropriate background screening for assigned positions 
completed prior to granting access? 
Ref: None 
6.2.1 Are individuals who are authorized to bypass significant technical and operational 
controls screened prior to access? 
Ref: NIST SP 800-53 PS-3; FISCAM SP-4.1; OMB Circular A-130, III 
6.2.2 Are confidentiality or security agreements required for employees assigned to work 
with sensitive information? 
Ref: NIST SP 800-53 PS-6; FISCAM SP-4.1 
6.2.3 When access controls cannot adequately protect your information assets, are 
individuals accessing the data screened prior to access? 
Ref: NIST SP 800-53 PS-3; OMB Circular A-130, III 
6.2.4 Are there conditions for allowing system access prior to completion of screening? 
Ref: NIST SP 800-53 PS-6; FISCAM AC-2.2; NIST SP 800-18 
COMMENTS 
6.1.1 The question depends on whether your agency deals with data that are defined as 
sensitive. If you have any such data that are defined as sensitive by either policy or 
legislation, this is a legitimate question to ask. 
6.1.2 The need to separate duties may be related to the sensitivity of the data or the need 
to separate duties. 
For example, in an accounting environment, you do not want the person who 
requests a payment to also be able to authorize the payment. Only if you have 
sensitive data would you need to write controls into the job descriptions. 
6.1.3 Sensitive functions should be divided. One of the questions that should be asked is: 
Should the person who enters or creates data also have the authority to remove the 
data? Essentially, you want two or more persons involved in the lifecycle of 
sensitive data. 

Appendix A 142

6.1.4 Another way to look at this issue is: Have you established checks and balances within 
the system support functions? 
6.1.5 How are violations of rules or procedures handled in your organization? As it relates 
to security, can security issues be handled in a similar fashion? 
6.1.6 All organizations should have clear and unambiguous personnel policies that cover 
hiring, transfer, and termination of employees. 
6.1.7 As employees join, transfer, or leave your department or agency, are there written 
procedures to follow that cover the adding or removal of user accounts? 
6.2.1 System support personnel, network engineers, and others who have broad powers 
over your computing facility need to be held to a higher standard due to their ability 
to bypass technical and operational controls within your IT system. 
6.2.2 These confidentiality or security agreements help clarify what is expected of 
employees who access sensitive data. 
6.2.3 If this can happen, are the procedures to screen an employee documented, and has 
management signed off on this process? 
6.2.4 If personnel can access sensitive data before they are fully cleared by the screening 
process, is management fully aware of the risks? Ultimately, management bears 
responsibility for this risk. 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 143

7. Physical and Environmental Protection 
Ref: NIST SP 800-43 PE-1 
ASSESSMENT QUESTIONS 
Physical Access Control 
7.1. Critical Element: Have adequate physical security controls been 
implemented that are commensurate with the risks of physical damage or 
access? 
Ref: None 
7.1.1 Is access to facilities controlled through the use of guards, identification badges, or 
entry devices such as key cards or biometrics? 
Ref: NIST SP 800-53 PE-2, PE-3; FISCAM AC-3; NIST SP 800-18 
7.1.2 Does management regularly review the list of persons with physical access to 
sensitive facilities? 
Ref: NIST SP 800-53 PE-2, PE-3; FISCAM AC-3.1 
7.1.3 Are deposits and withdrawals of tapes and other storage media from the library 
authorized and logged? 
Ref: NIST SP 800-53 PE-16; FISCAM AC-3.1 
7.1.4 Are keys or other access devices needed to enter the computer rooms and tape/ 
media libraries? 
Ref: NIST SP 800-53 MP-4; FISCAM AC-3.1 
7.1.5 Are unused keys or other entry devices secured? 
Ref: NIST SP 800-53 PE-3; FISCAM AC-3.1 
7.1.6 Do emergency exit and reentry procedures ensure that only authorized personnel 
are allowed to reenter after fire drills, etc? 
Ref: NIST SP 800-53 PE-3; FISCAM AC-3.1 
7.1.7 Are visitors to sensitive areas signed in and escorted? 
Ref: NIST SP 800-53 PE-7; FISCAM AC-3.1 
7.1.8 Is entry access to restricted IT assets regularly reviewed and entry codes changed 
periodically? 
Ref: NIST SP 800-53 PE-3; FISCAM AC-3.1 

Appendix A 144

7.1.9 Are physical accesses monitored through audit trails and apparent security 
violations investigated and remedial action taken? 
Ref: NIST SP 800-53 PE-6, PE-8; FISCAM AC-4 
7.1.10 Is suspicious access activity investigated and appropriate action taken? 
Ref: NIST SP 800-53 AC-13; FISCAM AC-4.3 
7.1.11 Are visitors, contractors, and maintenance personnel authenticated through the use 
of preplanned appointments and identification checks? 
Ref: NIST SP 800-53 PE-7; FISCAM AC-3.1 
Fire Safety Factors 
7.1.12 Are appropriate fire suppression and prevention devices installed and working? 
Ref: NIST SP 800-53 PE-13; FISCAM SC-2.1; NIST SP 800-18 
7.1.13 Are fire ignition sources, such as failures of electronic devices or wiring, improper 
storage materials, and the possibility of arson, reviewed periodically? 
Ref: NIST SP 800-53 RA-3; NIST SP 800-18 
Supporting Utilities 
7.1.14 Are heating and air conditioning systems regularly maintained? 
Ref: NIST SP 800-53 PE-14; NIST SP 800-18 
7.1.15 Is there a redundant air cooling system? 
Ref: NIST SP 800-53 PE-14; FISCAM SC-2.2 
7.1.16 Are electric power distribution, heating plants, water, sewage, and other utilities 
periodically reviewed for risk of failure? 
Ref: NIST SP 800-53 PE-9; FISCAM SC-2.2; NIST SP 800-18 
7.1.17 Are locations of building plumbing lines known and do they not endanger 
the system? 
Ref: NIST SP 800-53 PE-15; FISCAM SC-2.2; NIST SP 800-18 
7.1.18 Has an uninterruptible power supply or backup generator been provided? 
Ref: NIST SP 800-53 PE-11; FISCAM SC-2.2 
7.1.19 Have controls been implemented to mitigate other disasters, such as floods, 
earthquakes, etc.? 
Ref: NIST SP 800-53 RA-3; FISCAM SC-2.2 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 145

Interception of Data 
7.2. Critical Element: Is data protected from interception? 
Ref: None 
7.2.1 Are computer monitors located to eliminate viewing by unauthorized persons? 
Ref: NIST SP 800-53 PE-5; NIST SP 800-18 
7.2.2 Is physical access to data transmission lines controlled? 
Ref: NIST SP 800-53 PE-4; NIST SP 800-18 
Mobile and Portable Systems 
7.3. Critical Element: Are mobile and portable systems protected? 
Ref: None 
7.3.1 Are sensitive data files encrypted on all portable systems? 
Ref: NIST SP 800-53 AC-19; NIST SP 800-18 
7.3.2 Are portable systems stored securely? 
Ref: NIST SP 800-53 AC-19; NIST SP 800-18 
Wireless Use Within the System 
7.4. Critical Element: Is wireless access controlled within the system? 
Ref: None 
7.4.1 Are all wireless access points attached to the system known? 
Ref: None 
7.4.2 Are regular searches conducted for rogue wireless access points? 
Ref: None 
PDA Use Within the System 
7.5. Critical Element: Is the use of PDAs and other similar devices controlled 
within the system? 
Ref: None 
7.5.1 Are PDAs and similar devices that are allowed access to IT systems controlled? 
Ref: None 

Appendix A 146

7.5.2 Are PDAs and similar devices that are allowed access to IT systems required to have 
access control enabled on the devices and/or encryption of sensitive data? 
Ref: None 
COMMENTS 
7.1 
The basic question that needs to be asked is this: Are senior managers aware of the 
current risks inherent with your agencys IT systems, and are they willing to accept 
this level of exposure? 
7.1.1 1) Identify how access is gained to your facilities. 
2) Collect the policies and procedures associated with this access. 
3) If you are using commercial hardware and/or software to control physical 
access, obtain the user and system manuals to document the processes. 
4) Create a list of persons responsible for controlling this process. 
7.1.2 1) If any controlled access is in place, obtain copies of authorization policies and 
access lists. 
2) Determine if management, at any level, has at any time reviewed these lists for 
accuracy. 
3) Determine if any policies or procedures exist for this review process and, if so, 
obtain copies. 
7.1.3 1) Determine if any tapes or other storage media are created in the normal 
course of business. The tape library may be anything from a bottom drawer in 
someones desk to a formally organized tape library. 
2) If tapes or other storage media are created, determine if policies, 
procedures, or logs exist. If so, obtain copies of them. 
7.1.4 1) Determine if physical devices (keys, fobs, etc.) are required to enter the 
computer room, tape library, or other controlled area. 
7.1.5 1) Determine which person or persons have control of the keys or access devices. 
2) Determine if a sign-out list exists for these items. If so, obtain a copy. 
3) Determine if extra or backup items are available. 
4) Are these items secured? If so, document where they are kept and the policies 
and procedures used to control them. 
7.1.6 1) If there are emergency exits within the computer room, tape library, or other 
secured area, determine how people regain entrance after exiting. 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 147

2) Determine if procedures exist for the reentry process. If so, obtain copies of 
the procedures. 
7.1.7 1) Determine how visitors gain access to secured areas. 
2) Are there policies, procedures, or sign-in lists that control visitor access to the 
facility? If so, obtain copies of the documents. 
3) Determine if visitors simply sign in and enter the facility or if they must be 
escorted. 
7.1.8 1) If the controlled entry to the sensitive areas require codes, determine how often 
they are changed. 
2) If there are policies or procedures to change the codes, obtain copies. 
3) Determine how code changes are propagated to authorized personnel. 
4) Watch out for maintenance access codes. They often are very simple and seldom 
changed. You should make sure to change these codes at regular intervals. 
7.1.9 1) Determine if physical access is monitored and recorded, either manually or 
automatically, by the access system. 
2) If audit trails exist, determine if anyone reviews these for violations. Obtain 
examples of the audit trails, if they exist. 
3) If violations occur, determine what remedial actions should be taken. 
7.1.10 1) Determine how personnel report suspicious access activity. 
2) Determine if agency training covers this subject. 
3) Determine what actions are to be taken when unauthorized access is detected. 
4) Determine who is required to investigate these issues. 
7.1.11 1) Determine how people are authorized to enter the sensitive areas. 
2) Determine if there are policies or procedures that cover access by visitors, 
contractors, or maintenance personnel. 
7.1.12 1) You may need to contact the city or county building department to determine 
what appropriate fire suppression and prevention devices are required. 
2) Building codes change over time. Accordingly, you should verify the building 
code year that covers your facility. 
7.1.13 1) Determine who or what agency is responsible for this activity. 
2) If these items are reviewed, how are the results communicated to your 
management? 

Appendix A 148

7.1.14 1) Identify who maintains the heating and air conditioning systems. 
2) Determine if there is a maintenance contract. If so, obtain a copy for your 
records. 
7.1.15 1) If there is a redundant system, determine how it is activated and/or used when 
the main system fails. 
7.1.16 1) Determine who or what agency is responsible for your physical plant. 
2) Determine if there is any risk review on major building subsystems. 
7.1.17 1) Contact your building manager or other responsible party and determine where 
water, sewer, and gas lines run in and around your IT areas. 
7.1.18 1) This backup power facility may not be required for your agency. 
2) If it has been provided, determine how often it is tested. The minimum test 
period should be annually. 
7.1.19 1) Determine what disaster planning has been done for your local jurisdiction. 
2) Determine if the plans are tested. 
3) Determine how the controls are expected to reduce the impact of these 
natural disasters. 
7.2.1 1) From your list of systems that contain sensitive data, identify monitors used to 
access this data. 
2) Physically inspect each monitor location to verify difficulty in viewing data by 
unauthorized persons 
7.2.2 1) You may require assistance from system and/or network staff to determine how 
network lines are run. 
2) Determine physical access to areas where these lines run. 
7.3.1 1) In todays environment, this is a very critical issue. 
7.3.2 1) In todays environment, this is a very critical issue. 
2) Have users of portable systems been trained in how to use and store them 
securely on the road and in the office? 
7.4.1 1) In todays environment, this is a very critical issue. 
7.4.2 1) In todays environment, this is a very critical issue. 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 149

8. Production, Input/Output Controls 
Ref: NIST SP 800-53 MP-1 
ASSESSMENT QUESTIONS 
8.1. Critical Element: Is there user support? 
Ref: None 
8.1.1 Is there a help desk or group that offers advice? 
Ref: NIST SP 800-53 IR-7; NIST SP 800-18 
8.2. Critical Element: Are there media controls? 
Ref: None 
8.2.1 Are there processes to ensure that unauthorized individuals cannot read, copy, alter, 
or steal printed or electronic information? 
Ref: NIST SP 800-53 MP-2, MP-4; NIST SP 800-18 
8.2.2 Are there processes for ensuring that only authorized users pick up, receive, or 
deliver input and output information and media? 
Ref: NIST SP 800-53 MP-2, MP-4, MP-5; NIST SP 800-18 
8.2.3 Are audit trails used for receipt of sensitive inputs/outputs? 
Ref: NIST SP 800-53 MP-2; NIST SP 800-18 
8.2.4 Are controls in place for transporting or mailing media or printed output? 
Ref: NIST SP 800-53 AC-15, MP-5; NIST SP 800-18 
8.2.5 Is there internal/external labeling for sensitivity? 
Ref: NIST SP 800-53 MP-3; NIST SP 800-18 
8.2.6 Is there external labeling with special handling instructions? 
Ref: NIST SP 800-18 
8.2.7 Are audit trails kept for inventory management? 
Ref: NIST SP 800-53 MP-2; NIST SP 800-18 
8.2.8 Are media sanitized for reuse? 
Ref: NIST SP 800-53 MP-6; FISCAM AC-3.4; NIST SP 800-18 
8.2.9 Are damaged media stored and/or destroyed? 
Ref: NIST SP 800-53 MP-4, MP-6; NIST SP 800-18 

Appendix A 150

8.2.10 Are hard-copy media shredded or destroyed when no longer needed? 
Ref: NIST SP 800-53 MP-7; NIST SP 800-18 
COMMENTS 
8.1.1 The second question that should be asked is: What help is the user support group 
permitted to offer? The range of users that the help desk is designed to help must be 
clearly defined. 
8.2.1 This awareness of how unauthorized persons can obtain copies of data will derive 
from the self-assessment process. Be sure to review the low-tech methods of stealing 
data. Methods such as dumpster diving are often very successful. 
8.2.2 How does your agency authorize and control the transfer of data? Whatever your 
processes are, document them clearly. 
8.2.3 If your agency is transferring sensitive data, you should consider creating audit trails 
to provide confirmation of data transfers. 
8.2.4 If your agency rarely has the need to transport or mail media or output, then you 
might not have a formal system to track these transactions. However, if this is done 
regularly, you should probably have a written log to document these transactions. 
8.2.5 Good labeling is an effective way to identify and track sensitive physical items. 
8.2.6 Often media will have both an internal label and an external label. Does the visible 
external label contain a brief explanation of how the data should be handled? 
8.2.7 Keeping audit trails could simplify inventory management of media in your agency. 
8.2.8 If you sanitize media for reuse as a cost-cutting measure, have you verified whether 
the process is effective in removing all data from the media? 
8.2.9 Your agency should have a policy that covers damaged media. 
8.2.10 If you dont have this service, your agency should consider using one of the many 
shredding services. These services are readily available and are very effective in 
destroying data. 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 151

9. Contingency Planning 
Ref: NIST SP 800-53 CP-1; OMB Circular A-130, III 
ASSESSMENT QUESTIONS 
9.1. Critical Element: Have the most critical and sensitive operations and their 
supporting computer resources been identified? 
Ref: None 
9.1.1 Are critical data files and operations identified and the frequency of file backups 
documented? 
Ref: NIST SP 800-53 CP-2, CP-9; FISCAM SC-SC-1.1, 3.1; NIST SP 800-18 
9.1.2 Are resources supporting critical operations identified? 
Ref: NIST SP 800-53 MA-6; FISCAM SC-SC-1.2 
9.1.3 Has management established and approved processing priorities? 
Ref: NIST SP 800-53 CP-7; FISCAM SC-SC-1.3 
9.2. Critical Element: Has a comprehensive contingency plan been developed and 
documented? 
Ref: None 
9.2.1 Is the plan approved by key affected parties? 
Ref: NIST SP 800-53 CP-2; FISCAM SC- 3.1 
9.2.2 Are responsibilities for recovery assigned? 
Ref: NIST SP 800-53 CP-2; FISCAM SC 3.1 
9.2.3 Are there detailed instructions for restoring operations? 
Ref: NIST SP 800-53 CP-2; FISCAM SC-3.1 
9.2.4 Is there an alternate processing site? If so, is there a contract or interagency 
agreement in place? 
Ref: NIST SP 800-53 CP-6, CP-7; FISCAM SC-SC-1.1, 3.1; NIST SP 800-18 
9.2.5 Is the location of stored backups identified? 
Ref: NIST SP 800-53 CP-6, CP-7; NIST SP 800-18 
9.2.6 Are backup files created on a prescribed basis and rotated off site often enough to 
avoid disruption if current files are damaged? 
Ref: NIST SP 800-53 CP-9; FISCAM SC-2.1 

Appendix A 152

9.2.7 Is system and application documentation maintained at the off-site location? 
Ref: NIST SP 800-53 CP-6, CP-7; FISCAM SC-2.1 
9.2.8 Are all system defaults reset after being restored from a backup? 
Ref: NIST SP 800-53 CP-10; FISCAM SC-3.1 
9.2.9 Are the backup storage site and alternative site geographically removed from the 
primary site and physically protected? 
Ref: NIST SP 800-53 CP-6, CP-7, CP-9; FISCAM SC-SC-1.1, 3.1 
9.2.10 Has the contingency plan been distributed to all appropriate personnel? 
Ref: NIST SP 800-53 CP-2; FISCAM SC-3.1 
9.3. Critical Element: Are tested contingency/disaster recovery plans in place? 
Ref: None 
9.3.1 Is an up-to-date copy of the plan stored securely off site? 
Ref: NIST SP 800-53 CP-5, CP-9; FISCAM SC-3.1 
9.3.2 Are employees trained in their roles and responsibilities? 
Ref: NIST SP 800-53 CP-3; FISCAM SC-2.3; NIST SP 800-18 
9.3.3 Is the plan periodically tested and readjusted, as appropriate? 
Ref: NIST SP 800-53 CP-4, CP-5; FISCAM SC-3.1; NIST SP 800-18 
COMMENTS 
9.1.1 This is your primary insurance on recovering your operations. During the self-
assessment, it is very important to identify all the linkages between systems. These 
linkages will help you identify related data in other systems. Having only part of a 
backup is not a good thing. 
9.1.3 Priorities should be derived during the self-assessment phase of the security policy 
development process. The priorities are set when management reviews the results of 
the self-assessment and determines the risk level for the agency. 
9.2 All business and civil agencies should have a contingency recovery plan in place for 
their IT systems. 
9.2.1 Contingency planning should involve all parties that use a system. All parties need 
to understand their role in an emergency. With respect to your question, users 
need to understand what changes occur when the system is recovered in a 
contingency situation. 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 153

9.2.3 Part of any contingency recovery plan should call for duplication of the recovery 
instructions and their storage in multiple places. During a disaster, your agency 
should have several options for where to obtain this information. 
9.2.4 The choice of an alternate processing site is critical. If the disaster is local to a single 
building, then there is normally no problem moving to the recovery site. However, if 
there is a general disaster, and many companies need services, then having an ironclad 
contract to deliver services is necessary. 
9.2.5 This is not a silly question. The key to disaster planning is dont assume anything! 
Your recovery instructions must contain the location of backups, as well as codes 
and/or passwords to gain possession of the media. 
9.2.6 This is often one of the weak links in the contingency recovery process. After the 
backup program has been in place for a while, people get lazy and forget to move 
the backup tapes off site as soon as they should. This is an area that should have an 
automated check to verify movement of the tapes or media off site. 
9.2.7 All documentation to recover your operations should be stored off site. A good 
contingency recovery plan forces a formal documentation process that will ensure 
that up-to-date manuals are printed and moved off site. 
9.2.8 Test, Test, Test. The only way to catch these types of problems is to conduct full 
contingency recovery tests. 
9.2.9 This question is formulated for a general or regional disaster. The more remote the 
recovery site, the better the chance that it will be available for use. 
9.2.10 In any contingency recovery plan, communication is the key. The contingency 
recovery plan should include the creation of What do I do now packages for each 
member of the contingency recovery team. The packages outline the steps each 
person is expected to perform during a recovery operation. 
9.3.1 Multiple copies of the plans should be SECURED off site in multiple locations and 
documented for each contingency recovery team member. 
9.3.2 Testing the contingency recovery plan verifies that the plan will work, and also trains 
members of the contingency recovery team. 
9.3.3 Test contingency recovery plans annually because of regular changes that occur in 
most IT systems. 

Appendix A 154

10. Hardware and System Software Maintenance
Ref: NIST SP 800-53 MA-1; OMB Circular A-130
ASSESSMENT QUESTIONS 
10.1. Critical Element: Is access limited to system software and hardware? 
Ref: None 
10.1.1 Are restrictions in place on who performs maintenance and repair activities? 
Ref: NIST SP 800-53 CM-5, MA-2, MA-4, MA-5; OMB Circular A-130, III; FISCAM 
SS-3.1; NIST SP 800-18 
10.1.2 Is access to all program libraries restricted and controlled?
Ref: NIST SP 800-53 AC-3, MA-4; FISCAM CC-3.2, 3.3
10.1.3 Are there on-site and off-site maintenance procedures (e.g., escort of maintenance 
personnel, sanitization of devices removed from the site)? 
Ref: NIST SP 800-53 MA-2, MA-3, MA-5; NIST SP 800-18 
10.1.4 Is the operating system configured to prevent circumvention of the security software 
and application controls? 
Ref: NIST SP 800-53 CM-5; FISCAM SS-1.2 
10.1.5 Are up-to-date procedures in place for using and monitoring the use of 
system utilities? 
Ref: NIST SP 800-53 CM-5; FISCAM SS-3.1 
10.2. Critical Element: Are all new and revised hardware and software authorized, 
tested, and approved before implementation? 
Ref: None 
10.2.1 Is an impact analysis conducted to determine the effect of proposed changes on 
existing security controls, including the required training needed to implement 
the control? 
Ref: NIST SP 800-53 CA-7, CM-4, MA-2; NIST SP 800-18 
10.2.2 Are system components tested, documented, and approved (operating system, 
utility, applications) before promoted to production? 
Ref: NIST SP 800-53 CM-3; FISCAM SS-3.1, 3.2, CC-2.1; NIST SP 800-18 
10.2.3 Are software change request forms used to document requests and 
related approvals? 
Ref: NIST SP 800-53 CM-3; FISCAM CC-1.2; NIST SP 800-18 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 155

10.2.4 Are detailed system specifications prepared and reviewed by management? 
Ref: NIST SP 800-53 CM-4; FISCAM SS-3.1 
10.2.5 Is the type of test data to be used specified, i.e., live or made up? 
Ref: NIST SP 800-53 SA-11; NIST SP 800-18 
10.2.6 Are settings of security features set to the most restrictive mode? 
Ref: NIST SP 800-53 CM-6; PSN Security Assessment Guidelines 
10.2.7 Are software distribution implementation orders, including the effective date, 
provided to all locations? 
Ref: NIST SP 800-53 CM-2; FISCAM SS-3.1 
10.2.8 Is there version control? 
Ref: NIST SP 800-53 CM-3; NIST SP 800-18 
10.2.9 Are programs labeled and inventoried? 
Ref: NIST SP 800-53 CM-2, MP-3; FISCAM SS-3.1 
10.2.10 Are the distribution and implementation of new or revised software documented 
and reviewed? 
Ref: NIST SP 800-53 CM-3, SA-6, SA-7; FISCAM SS-3.1 
10.2.11 Are emergency change procedures documented and approved by management, 
either prior to the change or after the fact? 
Ref: NIST SP 800-53 CM-3; FISCAM SS-3.1 
10.2.12 Are contingency plans and other associated documentation updated to reflect 
system changes? 
Ref: NIST SP 800-53 CP-5; FISCAM SC-2.1; NIST SP 800-18 
10.2.13 Is the use of copyrighted software or shareware and personally owned software/ 
equipment documented? 
Ref: NIST SP 800-53 AC-20, SA-6; NIST SP 800-18 
10.3. Are systems managed to reduce vulnerabilities? 
Ref: NIST SP 800-53 CM-6 
10.3.1 Are systems periodically reviewed to identify and, when possible, eliminate 
unnecessary services (e.g., FTP, HTTP, mainframe supervisor calls)? 
Ref: NIST SP 800-53 CM-7, RA-5; NIST SP 800-18 

Appendix A 156

10.3.2 Are systems periodically reviewed for known vulnerabilities and are software 
patches promptly installed? 
Ref: NIST SP 800-53 SI-2; NIST SP 800-18 
COMMENTS 
10.1.1 System personnel often have broad authority and access to systems. You should 
know the background of the people who have these rights. You should also consider 
controls to track what they do as they perform maintenance and repair activities. 
10.1.2 Controlling access to program libraries simply avoids problems. You want your users 
not to have to worry about inadvertently doing something that adversely affects 
the system. 
10.1.3 While there should always be some procedures for on-site and off-site maintenance, 
the nature of your data is the determining factor. 
10.1.4 This is part of the security assessment and security control development process. 
The security controls should not be easily circumvented by simple changes to the 
operating system or application. 
10.1.5 System utilities often can be used to access data and bypass security controls. You 
should evaluate the need for system utilities access in the production environment. 
10.2 If an agency had unlimited funds, this would be a nonissue. However, hardware and 
software would not normally be tested in this fashion except for the more complex 
or sensitive IT systems. 
The basic issue is risk. Management simply needs to understand and accept the 
risk associated by not conducting this testing. Whatever your answer, the only thing 
that matters is that management is aware of and accepts the risks associated with 
the decision. 
10.2.1 All changes, especially to security controls, need to be thought through before they 
are implemented. 
10.2.2 This should be part of your agencys standard system implementation procedures. 
10.2.3 Communication is the key. Requests for changes should be documented and 
accepted by management before they are implemented. 
10.2.4 System specifications should be as explicit as possible and approved by management 
before the system is purchased or built. 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 157

10.2.5 Creating good test data is very difficult. Processing a copy of production data is 
good, but usually will not exercise the application completely. 
10.2.6 If the security controls can be set to different levels of control, then management 
must make the decision as to what settings are to be used. The most restrictive mode 
is not necessarily the one management will select. 
10.2.7 This question applies to situations where there is more than one production 
location. The goal is to keep the organization in sync with each other when the 
new system is moved into production. This question also applies to distribution of 
utilities, such as Microsoft Word. Essentially, you want all employees using the same 
level of software at the same time. 
10.2.8 Version control is also sometimes a difficult issue. In the best situation, you should 
have strong controls to limit the ability of users to use older or newer versions of a 
specific software product. 
10.2.9 This usually relates to original source media and documentation. 
10.2.10 Regardless of whether you are using electronic or manual software distribution, 
management should document and approve these activities. 
10.2.11 Emergency change procedures, while necessary, need to be designed carefully so the 
change can be backed out, if necessary. 
10.2.12 This is one of the major costs of maintaining a contingency recovery (CR) plan. IT 
systems are changed all the time. These changes must be reflected in your CR plans 
as quickly as possible. The procedures for making software changes or applying 
maintenance should include updating the CR plans as part of the process. 
10.2.13 Businesses and agencies should use only lawfully licensed software. If you permit 
your employees to use personally owned software, what happens when that 
employee leaves? Would you have to purchase a copy of the software to access the 
work product created with that software? 
10.3.1 Networks need to be protected because they often connect to the Internet. 
Unnecessary services should be disabled in the firewall or routers to protect the 
interior environment. In the mainframe arena, minimizing supervisor calls helps 
stabilize the application and reduces overhead. 

Appendix A 158

10.3.2 The application owner should ensure that available maintenance is tested and then 
applied on a regular basis. Researching for systems vulnerabilities does take time, 
but when these vulnerabilities are identified they can help specify what changes are 
needed in the system to avoid the problem. 
11. Data Integrity 
ASSESSMENT QUESTIONS 
11.1. Critical Element: Is virus detection and elimination software installed and 
activated? 
Ref: None 
11.1.1 Are virus signature files routinely updated?
Ref: NIST SP 800-53 SI-1, SI-3; NIST SP 800-16
11.2. Critical Element: Are data integrity and validation controls used to provide 
assurance that the information has not been altered and that the system 
functions as intended? 
Ref: NIST SP 800-53 SI-3 
11.2.1 Are reconciliation routines used by applications, i.e., checksums, hash totals, 
record counts? 
Ref: NIST SP 800-53 SC-8, SI-6, SI-7; NIST SP 800-18 
11.2.2 Is inappropriate or unusual activity reported, investigated, and appropriate 
actions taken? 
Ref: NIST SP 800-53 AC-13, SI-2, SI-6; FISCAM SS-2.2 
11.2.3 Are procedures in place to determine compliance with password policies? 
Ref: NIST SP 800-53 IA-1; NIST SP 800-18 
11.2.4 Are integrity verification programs used by applications to look for evidence of data 
tampering, errors, and omissions? 
Ref: NIST SP 800-53 SC-8, SI-7, MA-3; NIST SP 800-18 
11.2.5 Are intrusion detection tools installed on the system?
Ref: NIST SP 800-53 SI-4; NIST SP 800-18
11.2.6 Are the intrusion detection reports routinely reviewed and suspected incidents 
handled accordingly? 
Ref: NIST SP 800-53 SI-4; NIST SP 800-18 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 159

11.2.7 Is system performance monitoring used to analyze system performance logs in real 
time to look for availability problems, including active attacks? 
Ref: NIST SP 800-53 SI-2; NIST SP 800-18 
11.2.8 Is penetration testing performed on the system? 
Ref: NIST SP 800-53 CA-4; NIST SP 800-18 
COMMENTS 
11.1.1 When this self-assessment list was first created, spyware and adware were not issues. 
But they have now become serious issues and you should understand the risks and 
be prepared to deal with them. 
Every agency should have some form of antivirus, antispyware, and anti-adware 
installed on all workstations. The control files should be updated regularly. 
11.2.1 This is more a data integrity design issue. There are a number of mechanisms that 
can be used to check for data integrity. They should be deployed, as required, to 
meet managements goal for data integrity. 
11.2.2 The difficulty is detecting the inappropriate or unusual activity. Assuming the 
activity can be detected in your system, personnel need to be authorized to look into 
the problem and resolve it. 
11.2.3 Password policy concerning the structure of the password should be automatically 
enforced when a password is first entered or changed. 
11.2.4 This is a risk issue that management needs to approve. If management agrees, then 
programs and/or procedures need to be developed to look for and find evidence of 
data tampering, errors, and omissions. 
11.2.5 Intrusion detection is a complex topic. If intrusion detection system (IDS) tools are 
installed at your agency, they should be as automated as possible. An alternative 
would be to outsource the IDS function to a third party. These companies are much 
more efficient in monitoring and detecting intrusions into your network. 
11.2.6 The IDS function should be done by professionals and they should supply the 
reports. Few agencies have the technical depth to provide the monitoring level 
required to be effective in this arena. The reports should be reviewed and handled 
quickly. 

Appendix A 160

11.2.7 The decision to monitor system logs in real time is related to the criticality of the 
application. Real-time monitoring takes resources and should be a cost-effective use 
of agency funds. 
11.2.8 The issue involved here is the level of risk that management is willing to accept. 
Penetration testing takes time and money. If management is willing to forego the 
information that could be obtained by a pen-test, then that is its decision. 
12. Documentation
Ref: OMB Circular A-130, III
ASSESSMENT QUESTIONS 
12.1. Critical Element: Is there sufficient documentation that explains how 
software/hardware is to be used? 
Ref: None 
12.1.1 Is there vendor-supplied documentation of purchased software? 
Ref: NIST SP 800-53 SA-5; NIST SP 800-18 
12.1.2 Is there vendor-supplied documentation of purchased hardware? 
Ref: NIST SP 800-53 SA-5; NIST SP 800-18 
12.1.3 Is there application documentation for in-house applications? 
Ref: NIST SP 800-53 SA-5; NIST SP 800-18 
12.1.4 Are there network diagrams and documentation on setups of routers and switches? 
Ref: NIST SP 800-53 AC-8, CM-2; NIST SP 800-18 
12.1.5 Are there software and hardware testing procedures and results? 
Ref: NIST SP 800-53 SA-11; NIST SP 800-18 
12.1.6 Are there user manuals for all software and hardware in use on the systems? 
Ref NIST SP 800-53 SA-5; NIST SP 800-18 
12.1.7 Are there emergency procedures?
Ref: NIST SP 800-53 CP-2; NIST SP 800-18
12.1.8 Are there backup procedures?
Ref: NIST SP 800-53 CP-9; NIST SP 800-18

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 161

12.2. Critical Element: Are there formal, documented security and 
operational procedures? 
Ref: None 
12.2.1 Is there a system security plan? 
Ref: NIST SP 800-53 PL-2; OMB Circular A-130, III; FISCAM SP-2.1; NIST SP 800-18 
12.2.2 Is there a contingency plan? 
Ref: NIST SP 800-53 CP-2; NIST SP 800-18 
12.2.3 Are there written agreements regarding how data are shared between 
interconnected systems? 
Ref: NIST SP 800-53 CA-3, SA-9; OMB Circular A-130, III; NIST SP 800-18 
12.2.4 Are there risk-assessment reports? 
Ref: NIST SP 800-53 RA-3; NIST SP 800-18 
12.3. Critical Element: Are there formal service-level agreements? 
Ref: None 
12.3.1 Are formal service-level agreements in place for all outside agencies users? 
Ref: None 
COMMENTS 
12.1 The question is reasonably simple. Could a person, using the available 
documentation, access and/or run the system? While the development of 
documentation specifications occurred prior to this question, this question is simply 
asking if the documentation effort was successful. 
12.1.1 Most vendors have PDF versions of their documentation available. The issue is 
generally maintaining copies of older versions of the documentation. Not all 
vendors keep older documentation available online. 
12.1.2 Hardware documentation is generally available via PDF downloads from the 
Internet. Each agency should consider a common library for 
systems documentation. 
12.1.3 The documentation for in-house applications should be created and updated not 
only for the users of the system, but also for contingency recovery planning. 

Appendix A 162

12.1.4 You should determine if this documentation exists. This information may indicate 
that your system is exposed to outside risk. This question is also important for 
contingency planning activities or determining if there is outside access to a 
system or server. 
12.1.5 Your agency should develop testing plans for large hardware acquisitions. 
A major problem to be aware of is something called level creep. Level creep occurs 
in chip manufacturing. Changes or minor revisions are often introduced in the chip 
production line with minimal notification to end users. If you obtain a test unit 
for evaluation, be sure that truly identical units can be purchased when you have 
successfully completed your testing program. 
This can be a major problem for software distribution. The software drivers for one 
level of chips may not work with later revised chips. This problem would force you 
to maintain two or more versions of your software distribution prototype. 
12.1.6 User manuals should be available and cover all aspects of each job function. 
12.1.7 The previous contingency section dealt with the creation of the emergency 
procedures. This question is asking if the procedures are stand-alone and can be 
effectively used by themselves. Again, this is addressing the quality of the result, not 
necessarily its existence. 
12.1.8 Do written backup procedures exist? They are normally developed and refined as 
part of the contingency recovery process. 
12.2.1 This question deals with the effectiveness of the documentation. Is the 
documentation complete, is it readable, and has it been effectively distributed? 
12.2.2 Contingency planning is part of business resumption planning. Each agency should 
have a business continuity plan in place. 
12.2.3 Data that are either received from or sent to other systems need to be documented. 
In addition, if the ownership of these other systems lies outside of your agency, then 
you should have written agreements with the system owners concerning the 
data sharing. 
12.2.4 Risk-assessment reports should have been generated through the self-assessment 
process. These reports are important because they form the foundation for all risk 
analysis and subsequent security controls. 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 163

13. Security Awareness, Training, and Education 
Ref: NIST SP 800-53 AT-1; OMB Circular A-130, III 
ASSESSMENT QUESTIONS 
13.1. Critical Element: Have employees received adequate training to fulfill their 
security responsibilities? 
Ref: None 
13.1.1 Have employees received a copy of the rules of behavior? 
Ref: NIST SP 800-53 PL-4; NIST SP 800-18 
13.1.2 Are employee training and professional development documented and monitored? 
Ref: NIST SP 800-53 AT-4; FISCAM SP-42 
13.1.3 Is there periodic or annual refresher training? 
Ref: NIST SP 800-53 AT-3; OMB Circular A-130, III 
13.1.4 Are methods used to make employees aware of security, i.e., posters, booklets? 
Ref: NIST SP 800-53 AT-2; NIST SP 800-18 
13.1.5 Have employees received a copy of, or do they have easy access to, agency security 
procedures and policies? 
Ref: NIST SP 800-53 AT-2, AT-3; NIST SP 800-18 
COMMENTS 
13.1 Training is critical to creating a secure computing environment. 
13.1.1 The rules of behavior are essentially an application of the organizations 
security policies. 
13.1.2 The issue is employee efficiency. Tracking employee training and professional 
development permits supervisors to keep their teams up-to-date in 
new technologies. 
13.1.3 Annual refresher training usually deals with critical skills that need to be exercised 
perfectly on the job. 
13.1.4 Security awareness programs are useful in keeping employees focused on security. 
13.1.5 Unless there is a reason not to, security policies, procedures, and plans should be 
available to all employees. 

Appendix A 164

14. Incident Response Capability 
Ref: NIST SP 800-53 CA-1; OMB Circular A-130, III; FISCAM SP-5; NIST SP 800-18 
ASSESSMENT QUESTIONS 
14.1. Critical Element: Is there a capability to provide help to users when a security 
incident occurs in the system? 
Ref: None 
14.1.1 Is a formal incident response capability available? 
Ref: NIST SP 800-53 IR-4, IR-7, SI-5; FISCAM SP-3.4; NIST SP 800-18 
14.1.2 Is there a process for reporting incidents within the agency? 
Ref: NIST SP 800-53 IR-4, IR-6, SI-5; FISCAM SP-3.4; NIST SP 800-18 
14.1.3 Are incidents monitored and tracked until resolved?
Ref: NIST SP 800-53 IR-5, IR-6; NIST SP 800-18
14.1.4 Are personnel trained to recognize and handle incidents?
Ref: NIST SP 800-53 IR-2; FISCAM SP-3.4; NIST SP 800-18
14.1.5 Are alerts/advisories received and responded to?
Ref: NIST SP 800-53 SI-5; NIST SP 800-18
14.1.6 Is there a process to modify incident-handling procedures and control techniques 
after an incident occurs? 
Ref: NIST SP 800-53 IR-4; NIST SP 800-18 
14.2. Critical Element: Is incident-related information shared with appropriate 
organizations? 
Ref: None 
14.2.1 Is incident information and common vulnerabilities or threats shared with owners 
of interconnected systems? 
Ref: NIST SP 800-53 IR-6, RA-5; OMB A-130, III; NIST SP 800-18 
14.2.2 Is incident information shared with US-CERT concerning incidents and common 
vulnerabilities and threats? 
Ref: NIST SP 800-53 IR-6; OMB Circular A-130, III; GISRA 
14.2.3 Is incident information reported to the appropriate investigating law enforcement 
agency when necessary? 
Ref: NIST SP 800-53 IR-6; OMB Circular A-130, III; GISRA 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 165

COMMENTS 
14.1 This section is driven by OMB Circular A-130. It requires federal agencies to develop 
the capability to deal proactively with viruses, hackers, or software bugs. 
14.1.1 If your state, county, or city has mandated a security incident response program, 
then you should have funding for an incident response group. These persons will 
probably belong to other groups for their full-time jobs. The group is activated when 
an incident occurs and has the skills to handle the problems. 
14.1.2 As part of an incident response program, your agency should have a procedure for 
reporting incidents to the incident response team. This may be either directly to one 
of the team members or through your help desk. 
14.1.3 The incident response team should be responsible for tracking and 
resolving incidents. 
14.1.4 The incident response team needs to receive special or technical training to be able 
to deal efficiently and effectively with security incidents. 
14.1.5 Part of the incident response teams charter should cover reports to management. 
Management should be aware of the incidents and how they were resolved. 
14.1.6 Feedback is very important in the incident response process. Your incident response 
team should have a process in place to review an incident after it is resolved so 
lessons learned can be used to make the incident response team more effective. 
14.2 The ability to share incident information within your larger government structure is 
a way to drive down overall program costs. 
14.2.1 Depending on the written agreements you have with the owners of interconnected 
systems, you should seek to share this information with them. Your hope is that 
these owners will take action to reduce their vulnerability and, subsequently, your 
level of exposed risk. 

Appendix A 166

TECHNICAL 
15. Identification and Authentication 
ASSESSMENT QUESTIONS 
15.1. Critical Element: Are users individually authenticated via passwords, tokens, 
or other devices? 
Ref: None 
15.1.1 Is a current list maintained and approved of authorized users and their access? 
Ref: NIST SP 800-53 AC-2, AC-3, IA-4; FISCAM AC-2; NIST SP 800-18 
15.1.2 Are digital signatures used?
Ref: NIST SP 800-53 AU-10; NIST SP 800-18
15.1.3 Is emergency and temporary access authorized?
Ref: NIST SP 800-53 AC-2; FISCAM AC-2.2
15.1.4 Are personnel files matched with user accounts to ensure that terminated or 
transferred individuals do not retain system access? 
Ref: NIST SP 800-53 AC-2; FISCAM AC-3.2 
15.1.5 Are passwords changed periodically?
Ref: NIST SP 800-53 IA-5; FISCAM AC-3.2; NIST SP 800-18
15.1.6 Are passwords unique and difficult to guess (e.g., do passwords require 
alphanumeric, upper/lower case, and special characters)? 
Ref: NIST SP 800-53 IA-5; FISCAM AC-3.2; NIST SP 800-18 
15.1.7 Are inactive user identifications disabled after a specified period? 
Ref: NIST SP 800-53 AC-2, IA-4; FISCAM AC-3.2; NIST SP 800-18 
15.1.8 Are passwords not displayed when entered?
Ref: NIST SP 800-53 IA-5; FISCAM AC-3.2; NIST SP 800-18
15.1.9 Are procedures in place for handling lost and compromised passwords? 
Ref: NIST SP 800-53 IA-5; FISCAM AC-3.2; NIST SP 800-18 
15.1.10 Are passwords distributed securely and users told not to reveal their passwords to 
anyone (social engineering)? 
Ref: NIST SP 800-53 IA-5; NIST SP 800-18 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 167

15.1.11 Are passwords transmitted and stored using secure protocols/algorithms? 
Ref: NIST SP 800-53 IA-5; FISCAM AC-3.2; NIST SP 800-18 
15.1.12 Are vendor-supplied passwords replaced immediately? 
Ref: NIST SP 800-53 IA-5; FISCAM AC-3.2; NIST SP 800-18 
15.1.13 Is there a limit to the number of invalid access attempts that may occur for 
a given user? 
Ref: NIST SP 800-53 AC-7; FISCAM AC-3.2; NIST SP 800-18 
15.2. Critical Element: Are access controls enforcing segregation of duties? 
Ref: None 
15.2.1 Does the system correlate actions to users? 
Ref: NIST SP 800-53 AC-5; OMB Circular A-130, III; FISCAM SD-2.1 
15.2.2 Do data owners periodically review access authorizations to determine whether they 
remain appropriate? 
Ref: NIST SP 800-53 AC-2; FISCAM AC-2.1 
COMMENTS 
15.1 The basic questions are: Do you know who your users are, and how do you know? 
15.1.1 How does your agency authorize users into its systems? Does it maintain a list of 
these persons? 
15.1.2 Most agencies do not require digital signatures. This is primarily a federal 
requirement. However, if you do use digital signatures, you should investigate if 
your systems conform to the FIPS 186-2 standard. 
15.1.3 You should always develop a procedure for emergency access. The emergency 
procedure should still have as many controls as possible to minimize security 
exposure. The process needs to be properly authorized by management and logged 
for tracking access. 
15.1.4 Your agencys personnel department should have a procedure to notify system 
administrators that the status of an employee has changed. This is a very important 
process to have in place. 
15.1.5 The actual frequency of password changes needs to be set by management. The 90day 
limit is simply a recommendation developed within the security industry. 

Appendix A 168

15.1.6 Password complexity is a two-edged sword. If they are made too complex, 
passwords get written down and usually are accessible at a persons workstation. If 
they are too simple, then the risk of passwords being cracked or guessed increases. 
15.1.7 This is one specification that should be part of the system specifications. Security 
is more easily administered if some actions can be set on automatic. For example, 
management may specify that if a user does not log onto a system for 3 weeks, his 
or her account would be disabled. The time is set at 3 weeks to allow for a 2-week 
vacation period plus some holidays. 
15.1.8 Almost all systems today mask the password when entered. Some systems allow the 
password to be exposed, but generally this feature cannot be set automatically. 
15.1.9 Your agency should identify a limited number of people who are given the authority 
to reset lost or compromised passwords. The system should be designed to log 
password changes only by these persons. 
15.1.10 The secure distribution of passwords is often difficult. Generally, the system should 
be configured to require that a new password be established when the distributed 
password is used the first time. 
15.1.11 This is more of a systems question. The answer needs to be provided by the 
product vendor. 
15.1.12 The short answer is: They should be. Generally, however, they are not. This is one of 
the biggest exposures that most systems experience. Hackers have lists of these IDs 
and passwords on the Internet. 
15.1.13 Systems should be configured to only allow so many attempts before locking 
the account. Other approaches simply extend the time to make the change from 
milliseconds to 60 seconds or longer. 
15.2.1 The simple question is: Does the system associate specific activities with 
specific users? 
15.2.2 The data owner is that agency and/or persons who have the ultimate responsibility 
for the protection and preservation of the data. A simple question you should ask is: 
Who would be upset if certain data were irretrievably lost? This would generally 
help to identify the data owner. The data owner may also be set by legislation and/or 
policy within the agency. Whoever this person is, it is his or her responsibility to 
verify that only authorized persons gain access to their data. 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 169

16. Logical Access Controls 
Ref: NIST SP 800-53 AC-1; OMB Circular A-130, III; FISCAM AC-3.2; 
NIST SP 800-18 
ASSESSMENT QUESTIONS 
16.1. Critical Element: Do the logical access controls restrict users to authorized 
transactions and functions? 
Ref: None 
16.1.1 Can the security controls detect unauthorized access attempts? 
Ref: NIST SP 800-53 AC-3; FISCAM AC-3.2; NIST SP 800-18 
16.1.2 Are access control software or other measures in place to prevent a user from having 
all necessary authority or information access to allow fraudulent activity without 
collusion? 
Ref: NIST SP 800-53 AC-3, AC-5, AC-6; FISCAM AC-3.2; NIST SP 800-18 
16.1.3 Is access to security software restricted to security administrators? 
Ref: NIST SP 800-53 AC-2, AC-3, AC-6, IA-5; FISCAM AC-3.2 
16.1.4 Do workstations disconnect or screen savers lock the system after a specific period 
of inactivity? 
Ref: NIST SP 800-53 AC-11, AC-12; FISCAM AC-3.2; NIST SP 800-18 
16.1.5 Are inactive users accounts monitored and removed when not needed? 
Ref: NIST SP 800-53 AC-2; FISCAM AC-3.2; NIST SP 800-18 
16.1.6 If encryption is used, what encryption standard is used (is the federal 
standard considered)? 
Ref: NIST SP 800-53 AC-3, IA-7, SC-12, SC-13; NIST SP 800-18 
16.1.7 If encryption is used, are there procedures for key generation, distribution, storage, 
use, destruction, and archiving? 
Ref: NIST SP 800-53 SC-12, SC-13; NIST SP 800-18 
16.1.8 Is access restricted to files at the logical view or field? 
Ref: NIST SP 800-53 AC-3; FISCAM AC-3.2 
16.1.9 Is access monitored to identify apparent security violations and are such 
events investigated? 
Ref: NIST SP 800-53 AC-13; FISCAM AC-3.2 

Appendix A 170

16.2. Critical Element: Are there logical controls over network access? 
Ref: None 
16.2.1 Has communication software been implemented to restrict access through specific 
terminals? 
Ref: NIST SP 800-53 AC-3; FISCAM AC-3.2 
16.2.2 Are insecure protocols (e.g., UDP, FTP) disabled? 
Ref: NIST SP 800-53 CM-6, SC-7; PSN Security Assessment Guidelines 
16.2.3 Have all vendor-supplied default security parameters been reinitialized to more 
secure settings? 
Ref: NIST SP 800-53 CM-6, IA-5; PSN Security Assessment Guidelines 
16.2.4 Are there controls that restrict remote access to the system? 
Ref: NIST SP 800-53 AC-17; NIST SP 800-18 
16.2.5 Are network activity logs maintained and reviewed? 
Ref: NIST SP 800-53 AC-13, AU-6; FISCAM AC-3.2 
16.2.6 Does the network connection automatically disconnect at the end of a session? 
Ref: NIST SP 800-53 AC-12, SC-10; FISCAM AC-3.2 
16.2.7 Are trust relationships among hosts and external entities appropriately restricted? 
Ref: NIST SP 800-53 AC-3, IA-3, SC-7, SC-11; PSN Security Assessment Guidelines 
16.2.8 Is dial-in access monitored? 
Ref: NIST SP 800-53 AC-17; FISCAM AC-3.2 
16.2.9 Is access to telecommunications hardware or facilities restricted and monitored? 
Ref: NIST SP 800-53 PE-4, SC-7; FISCAM AC-3.2 
16.2.10 Are firewalls or secure gateways installed? 
Ref: NIST SP 800-53 AC-3, SC-7; NIST SP 800-18 
16.2.11 If firewalls are installed, do they comply with firewall policy and rules? 
Ref: NIST SP 800-53 AC-3, CM-6, SC-7; FISCAM AC-3.2 
16.2.12 Are guest and anonymous accounts authorized and monitored? 
Ref: NIST SP 800-53 AC-2, AC-14; PSN Security Assessment Guidelines 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 171

16.2.13 Is an approved standardized logon banner displayed on the system warning 
unauthorized users that they have accessed a U.S. Government system and 
can be punished? 
Ref: NIST SP 800-53 AC-8; FISCAM AC-3.2; NIST SP 800-18 
16.2.14 Are sensitive data transmissions encrypted? 
Ref: NIST SP 800-53 SC-7, SC-8; FISCAM AC-3.2 
16.2.15 Is access to tables defining network options, resources, and operator profiles 
restricted? 
Ref: NIST SP 800-53 AC-3; FISCAM AC-3.2 
16.3. Critical Element: If the public accesses the system, are there controls 
implemented to protect the integrity of the application and the confidence 
of the public? 
Ref: None 
16.3.1 Is the agencys privacy policy posted on the agency web site? 
Ref: NIST SP 800-53 AC-8; OMB Circular 99-18 
COMMENTS 
16.1.1 Security controls should be designed to detect and report unauthorized 
access attempts. 
16.1.2 This is one area that should be researched thoroughly when acquiring a new system. 
16.1.3 This needs to be researched before the software is acquired. 
16.1.4 Personnel need to be trained to set their screensavers to this mode. If the 
workstations are part of a domain, this can be done automatically. 
16.1.5 The access-control software should have this reporting capability. 
16.1.6 Generally, if you use encryption, the software will have been designed by the vendor 
to meet the federal standards. 
16.1.7 Key management is the most important and yet the most difficult aspect of using 
encryption. You need well-thought-out procedures to handle encryption keys. 
16.1.8 A logical view can be thought of as a special window into the data built just for you. 
The logical view will let you look at only the data that the security administrators 

Appendix A 172

want you to see. If the security is built at the field level, it may be possible for you to 
access data that are not logically related to your request and data that you are not 
supposed to view. 
16.1.9 Logging security violations is an important aspect of security. As part of your 
security program, you need to assign people to review these violations and take 
action, if required. 
16.2.1 The ability to restrict access to data based on the location of a physical terminal is a 
good security feature. 
16.2.2 All unnecessary network protocols should be disabled in a sensitive 
data environment. 
16.2.3 Does your system have the ability to change the default security settings? If this 
feature is available and implemented, it helps avoid the problem of someone 
inadvertently resetting his or her security parameters and losing his or her 
secure status. 
16.2.4 Unless absolutely required by your charter, remote access to a system should 
not be permitted. 
16.2.5 As with all logging activities, the maintenance and scanning of the logs need to be as 
automated as possible. Once detected, problems should be researched and resolved. 
16.2.6 The default network behavior needs to be understood. Remote access should 
automatically tear down a session either on timeout or logout. 
16.2.7 A trust relationship is established when one system permits a foreign system access 
to its secured data. Usually, this is independent of the actual user who is using the 
foreign system to gain access to the data. Trust relationships between systems can 
increase your security risk exposure. 
16.2.8 All remote access to your systems should be logged and monitored. 
16.2.9 Physical access to telecommunications equipment is a security exposure. If possible, 
this access should be logged and monitored. 
16.2.10 All connections to the Internet should be through firewalls or secure gateways. 
16.2.11 This question assumes that security policies have been developed concerning how 
firewall policies and rules are created. 

Assessment Worksheets and Questions  
from the SeArCH IT Security Self- and risk-Assessment Tool 173

For example: On Check Point Software Technologies firewalls, before you can create 
a rule, you must define the objects (networks, nodes, etc.) that will be protected. A 
security policy could be created that tells the network analyst how the Check Point 
objects should be named. While this may not seem like much, this is important so 
there is consistency in how objects are named. Overall, this helps reduce the chance 
for errors when the network analyst creates a firewall rule set. 
16.2.12 Unless required by your charter, all guest and anonymous accounts should 
be disabled. 
16.2.13 This should be standard operating procedure within your agency. 
16.2.14 They should be. 
16.2.15 Network documentation, while necessary, should be considered confidential and 
limited to people on a need-to-know basis. 
16.3 Effective and secure public access to a system is difficult. Generally, the best design 
separates the public access from the rest of the system. It is simply easier to control 
security when you totally control what information is sent to the public server. 
16.3.1 This is a federal policy. It required that all federal departments and agencies post 
clear privacy policies on their World Wide Web sites by September 1, 1999. Each 
policy must clearly and concisely inform visitors to the site what information the 
agency collects about individuals, why the agency collects it, and how the agency 
will use it. Privacy policies must be clearly labeled and easily accessed when 
someone visits a web site. 

Appendix A 174

17. Audit Trails 
Ref: NIST SP 800-53 AU-1; OMB Circular A-130, III; FISCAM AC-4.1; 
NIST SP 800-18 
ASSESSMENT QUESTIONS 
17.1. Critical Element: Is activity involving access to, and modification of, sensitive 
or critical files logged and monitored, and are possible security violations 
investigated? 
Ref: None 
17.1.1 Does the audit trail provide a trace of user actions? 
Ref: NIST SP 800-53 AU-2, AU-3, AU-10; NIST SP 800-18 
17.1.2 Can the audit trail support after-the-fact investigations of how, when, and why 
normal operations ceased? 
Ref: NIST SP 800-53 AU-2, AU-7; NIST SP 800-18 
17.1.3 Is access to online audit logs strictly controlled? 
Ref: NIST SP 800-53 AU-9; NIST SP 800-18 
17.1.4 Are offline storage of audit logs retained for a period of time, and if so, is access to 
audit logs strictly controlled? 
Ref: NIST SP 800-53 AU-2, AU-9, AU-11; NIST SP 800-18 
17.1.5 Is there separation of duties between security personnel who administer the access 
control function and those who administer the audit trail? 
Ref: NIST SP 800-53 AU-5, AU-6; NIST SP 800-18 
17.1.6 Are audit trails reviewed frequently? 
Ref: NIST SP 800-53 AU-13; NIST SP 800-18 
17.1.7 Are automated tools used to review audit records in real time or near real time? 
Ref: NIST SP 800-53 AU-13, AU-6, AU-7; NIST SP 800-18 
17.1.8 Is suspicious activity investigated and appropriate action taken? 
Ref: NIST SP 800-53 AU-6; FISCAM AC-4.3 
17.1.9 Is keystroke monitoring used? If so, are users notified? 
Ref: NIST SP 800-53 AU-8; NIST SP 800-18 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 175

COMMENTS 
17.1.1 Audit trails are good security tools that should be part of every system. 
17.1.2 The design of audit trails should be part of the system development process. They 
should be designed to provide sufficient data so both normal or abnormal activities 
can be detected. 
17.1.3 Access to audit logs should be very controlled. If possible, they should be captured 
on a separate system from the one being monitored. 
17.1.4 Audit trail logs need to be managed. You may not detect a problem for days or 
weeks, so it is important to be able to go back and access the appropriate audit log. 
17.1.5 Separation of function is a good thing to have within the security area. 
17.1.6 Security administration needs to be cost-effective. The review of audit trails should 
be as automated as possible. 
17.1.7 This is a management decision. There are direct costs associated with real-time 
review and this has to be part of managements overall risk-mitigation strategy. 
17.1.8 How are people trained in your agency to report suspicious activity? Whatever 
method is used, the process should result in the suspicious activity being recorded 
and reported to management. 
17.1.9 Your employees should be told if keystroke monitoring is taking place. This can be a 
serious morale issue and needs to be handled properly. 

Appendix A 176

STATE AND LOCAL LAW ENFORCEMENT-SPECIFIC IT 
SECURITY CONTROLS 
18. FBI CJIS Compliance 
ASSESSMENT QUESTIONS 
18.1. Critical Element: Has the agency implemented the minimum level of 
technical security controls, as outlined in the CJIS Security Policy? 
Ref: CJIS Security Policy, Version 4 
18.1.1 Is CJIS awareness training conducted for new employees within 6 months of 
appointment or assignment? 
Ref: CJIS Security Policy, Version 4, Section 4.3 
18.1.2 Has adequate physical security been provided at all times to protect against 
unauthorized access to or routine viewing of computer devices, access devices, and 
printed and stored data? 
Ref: CJIS Security Policy, Version 4, Sections 4.4.1 and 7.2 
18.1.3 Are all visitors to computer centers and/or terminal areas escorted by authorized 
personnel at all times? 
Ref: CJIS Security Policy, Version 4, Section 4.4.3 
18.1.4 Is personnel background screening conducted for all personnel who have systems 
access and computer terminal/records storage areas access? 
Ref: CJIS Security Policy, Version 4, Section 4.5.1 
18.1.5 Are all media disposed of or reused in accordance with CJIS policy? 
Ref: CJIS Security Policy, Version 4, Sections 4.6 and 4.7 
18.1.6 Are security incidents identified, investigated, and properly forwarded to the 
FBI CJIS Information Security Officer (ISO) or to the Computer Security Incident 
Response Center (CSIRC)? 
Ref: CJIS Security Policy, Version 4, Sections 5.3 and 5.4 
18.1.7 Are all criminal/noncriminal justice agency and contractor user agreements 
in place? 
Ref: CJIS Security Policy, Version 4, Sections 6.3, 6.4, and 6.6 

Assessment Worksheets and Questions 
from the SeArCH IT Security Self- and risk-Assessment Tool 177

18.1.8 Is the network configuration documented? 
Ref: CJIS Security Policy, Version 4, Section 7.1 
18.1.9 Is the identity of users authenticated according to the methods identified in the CJIS 
Security Policy (Virtual Private Network [VPN], biometrics, public key infrastructure 
[PKI], smart cards, and tokens), as applicable? 
Ref: CJIS Security Policy, Version 4, Section 7.3 
18.1.10 Are all nonsecure locations that access CJIS from any Internet, wireless, or dial-in 
connection using the proper level of authentication, as defined in this policy? 
Ref: CJIS Security Policy, Version 4, Section 7.3.2 
18.1.11 Are all secure locations that access CJIS from any Internet, wireless, or dial-in 
connection from a remote location using the proper level of authentication, as 
defined in this policy? 
Ref: CJIS Security Policy, Version 4, Sec. 7.3.3 
18.1.12 Are all mobile devices that have been removed from a police vehicle incorporating, 
at a minimum, the use of a unique password or other personal identifier (PIN), and 
do they meet the advanced authentication requirement, as well? 
Ref: CJIS Security Policy, Version 4, Section 7.3.2(b) 
18.1.13 Is each person who is authorized to store, process, and/or transmit information on 
an FBI CJIS system issued a unique identifier? 
Ref: CJIS Security Policy, Version 4, Section 7.4.1 
18.1.14 Do all passwords for access and authentication on criminal justice information 
systems comply with CJIS policy? 
Ref: CJIS Security Policy, Version 4, Section 7.4.2 
18.1.15 Is access control documented and controlled according to the guidance in Appendix 
C-8 of the CJIS policy? 
Ref: CJIS Security Policy, Version 4, Section 7.5 
18.1.16 Is Internet and dial-up access to the system controlled according to CJIS policy? 
Ref: CJIS Security Policy, Version 4, Sections 7.6 and 7.7 
18.1.17 Are data encryption standards, as outlined in the CJIS policy, being met? 
Ref: CJIS Security Policy, Version 4, Section 7.8; and FIPS Publication 140-2, 
Security Requirements for Cryptographic Models 

Appendix A 178

18.1.18 Are encryption keys that are used documented and managed by the agency? 
Ref: CJIS Security Policy, Version 4, Section 7.8.1; and Appendix C, Guidelines and 
Recommendations for Effective Encryption Key Management 
18.1.19 Do all wirelessly attached devices follow the guidelines, as set forth in the 
CJIS policy? 
Ref: CJIS Security Policy, Version 4, Section 7.9; and Appendix C, Wireless 
Implementation Guidelines 
18.1.20 Do firewalls used to protect the criminal justice information system meet the 
guidelines, as outlined in the policy? 
Ref: CJIS Security Policy, Version 4, Section 7.10; Appendix B, Firewall Security and 
Profile Web Sites; and Appendix C, Firewall Definitions 
18.1.21 Is virus protection used on the system? 
Ref: CJIS Security Policy, Version 4, Section 7.12 
18.1.22 Is criminal history information controlled according to CJIS policy? 
Ref: CJIS Security Policy, Version 4, Section 8.0 

Appendix B:
SEARCH IT Security Worksheets

SEARCH IT Security control development worksheet 
Step 1: 
Identified risk 
Step 2: 
existing controls 
Step 3: 
All other possible 
controls 
Step 4: 
control implications 
Step 5: 
control recommendation 
Step 6: 
management control 
decision 
For instructions on the use of this form, see pages 8994

Appendix B 182

SEARCH IT Security measurement development worksheet 
Step 1: 
Identified risk 
Step 2: 
management control 
decision 
Step 3: 
existing measures 
Step 4: 
All other possible 
measures 
Step 5: 
measure implications 
Step 6: 
measure 
recommendation 
Step 7: 
measure 
implementation 
For instructions on the use of this form, see pages 103107 

SEARCH IT Security Worksheets 183 

SEARCH IT Security Policy development worksheet 
Step 1: 
Identified risk 
Step 2: 
management control 
decision 
Step 3: 
measure 
implementation 
Step 4: 
existing policy 
Step 5: 
Proposed security policy 
Step 6: 
Policy recommendation 
comments: 
For instructions on the use of this form, see pages 113117

Appendix B 184

Sample completed It Security Policy development worksheet 
The sample responses recorded during the self- and risk-assessment processes, as shown in 
these graphics, eventually feed into the policy development, as illustrated below. 
Image of Sample Development Worksheets

SEARCH IT Security Worksheets 185

Step 1: Identified risk
Personnel who have not undergone thorough background checks have access to information 
systems. 
Step 2: management control decision
Conduct background investigations internally using our own employees. Training will be 
provided by a neighboring agency that conducts its own investigations. Access to a public 
information database will be purchased and a policy will be written to ensure that proper 
background investigations are conducted. 
Step 3: measure implementation 
The Personnel Division commander will conduct an annual audit of the background 
investigations section to ensure that they are complying with the agency policy. 
Step 4: existing policy 
No current policy statement exists within the agency for this identified risk. 
Step 5: Proposed security policy 
This policy will affect all members of the agency. The agency will immediately begin 
conducting thorough background checks of all employees, civilian or sworn, who have access 
to agency systems. The checks will be conducted by the background unit, which will be an 
ancillary responsibility of the Detective Division commander. Any personnel failing to complete 
the background process will be administratively suspended until such time as the background 
can be properly completed. Personnel who, through the investigation, do not obtain a 
satisfactory background check shall be referred to the personnel section for reassignment 
within the agency. 
Step 6: Policy recommendation 
 This policy will affect all new employees who have been given a conditional offer of hire. 
 A thorough background check of the new hire will be completed prior to the persons 
assignment to a position that will give him or her access to the agencys system. 
 Under the direction of the commander in charge of Administration, the detectives assigned 
to background investigations will conduct a thorough background check according to the 
procedures developed at the direction of the commander and approved by the chief of the 
agency. 
 Due to the sensitive nature of the background check process, only the commander in 
charge of Administration, the agency assistant chief, the agency chief, and the agency 
counsel will be allowed to review the completed background information. 
 New hires failing to complete the background process will be promptly notified of their 
status and referred to the personnel section. 
comments: 

Appendix C:
Glossary of Security Terms

Acceptable Risk 
A risk that management has decided to accept. It is managements responsibility to balance 
the cost of reducing risks against the cost to the organization if the risk actually occurs. 
Access Control 
A procedure used to limit access to a resource to authorized entities. 
Access Control Policy 
A policy that management has approved and which forms the basis for allowing access to 
physical or logical objects. 
Access Control Procedures 
Procedures that are created and implemented to permit effective control of access to either 
physical or logical objects. The control mechanisms may use software, hardware, or people 
alone, or in any combination. 
Advanced Encryption Standard (AES) 
A block cipher algorithm that was adopted in 2001 as an encryption standard by the 
U.S. government. 
Authorization 
The act of granting access rights to someone or something. The control of authorization is 
based on the authentication of the object. 
Biometrics 
A method of authenticating or verifying an individual based on physical or
behavioral characteristics.
Certificate Authority (CA) 
A system that issues and manages security credentials and/or public keys that are used for 
message encryption. A CA is part of a Public Key Infrastructure (PKI). 
CERT 
Computer Emergency Readiness Team. The official name is the CERT Coordination Center. 
It is located at Carnegie-Mellon University in Pittsburgh, Pennsylvania. CERT provides 
official worldwide Internet emergency support. 

Appendix C 190

Contingency Plan 
A plan that has been created to permit a company or agency to recover from an 
emergency or other unanticipated event. The plans usually focus on business 
resumption activities at an alternate location. 
Countermeasure 
Any activity that reduces a systems vulnerability to a threat. 
Computer Security Act (CSA) 
The Computer Security Act (Public Law 100-235) was passed by Congress in 1987. 
In general, the act declares that improving the security and privacy of sensitive 
information in Federal computer systems is in the public interest, and hereby creates 
a means for establishing minimum acceptable security practices for such systems, 
without limiting the scope of security measures already planned or in use. 
Demilitarized Zone (DMZ) 
A portion of an internal network that is exposed to an external networkusually the 
Internet. The amount of exposure is highly controlled. The DMZ serves as a buffer 
zone between the internal, trusted network and the outside, nontrusted network. 
Federal Information Processing Standards (FIPS) 
Under the Information Technology Management Reform Act (Public Law 104-106), the 
Secretary of Commerce approves standards and guidelines that are developed by the 
National Institute of Standards and Technology (NIST) for federal computer systems. 
Firewall 
A network appliance that is designed to control network traffic according to a set of 
rules. A firewall is normally connected to two or more different networks. Firewalls are 
usually installed to control network traffic between the Internet and a users 
private network. 
Government Information Security Reform Act (GISRA) 
A Federal law (Public Law 106-398) that requires federal agencies to perform an internal 
risk assessment of their electronic information systems and security processes. 
Internet Control Message Protocol (ICMP) 
A protocol that is used to send control messages between hosts on a network. One 
example of the use of this protocol is when someone tries to send a packet to a host 
that has been turned off or is no longer available. In this case, the last active network 
appliance will detect this problem and will send a host unreachable ICMP message 
back to the originating host. 

Glossary of Security Terms 191

Intrusion Detection Systems (IDS) 
An IDS seeks to detect intrusion or unauthorized entry into a computer system or 
network by observation of network traffic. 
Lifecycle 
The phases of a system as it moves from development through design and 
implementation, and finally to deactivation and disposal. 
Local Area Network (LAN) 
A network that is local to your organization. Generally, it is rather small and uses 
private Internet Protocol (IP) addressing. 
Mandatory Access Controls (MAC) 
MAC requires information to be categorizedsuch as Secret, Top Secret, or 
Confidentialand individuals are granted access to a specific category based on their 
security clearance. 
National Institute of Standards and Technology (NIST) 
NISTs mission is to promote U.S. innovation and industrial competitiveness by 
advancing measurement science, standards, and technology  . 
Physical Security Policy 
A document that defines which physical items need to be protected and at what level. 
Risk 
The probability that a loss of data or a specific threat will occur. 
Risk Analysis/Risk Assessment 
The risk-assessment process begins with a self-assessment of the target system. Once 
the system is thoroughly investigated and understood, then the system is analyzed for 
possible security risks. Risk analysis involves determining what risks are present, and 
which risks need to be mitigated. 
Security Goal 
A measurable event that relates to successful implementation of security policies. 
Security Objectives 
There are five security objectives that organizations should try to achieve: 
integrity, availability, confidentiality, accountability, and assurance. 
Security Policy 
A statement that defines specific behavior of individuals or systems that, when 
achieved, result in reaching a specific security goal. 

Appendix C 192

Virtual Private Network (VPN) 
A method of logically connecting a remote host over a network so the remote host is 
unaware that it is remotely connected. 
Vulnerability 
An identified weakness in a system that is open to exploitation by anyone. 
Vulnerabilities are identified during the risk-assessment process. Management must 
decide how each vulnerability needs to be addressed in order to reduce the overall risk 
of the organization to an acceptable level. 

Appendix D:
Security Resources

Key NIST Security Publications 
While there are dozens of National Institute of Standards and Technology (NIST) 
publications relating to a variety of security topics, your agency should review the following 
key manuals prior to starting its security policy development effort. Please note that most of 
these manuals contain numerous references to other NIST, Federal Information Processing 
Standards (FIPS), and General Services Administration (GSA) manuals. Following these 
references will provide you with additional detail, should you require it. These key NIST 
security publications are available at http://csrc.nist.gov/publications/nistpubs/. 
Special Publication (SP) 800-12: An Introduction to Computer Security: The NIST Handbook, 
October 1995 
This is an excellent introduction to computer security. This manual will be one of your 
key references as your agency develops computer policies. 
SP 800-18: Guide for Developing Security Plans for Information Technology Systems, December 
This guide provides an excellent introduction to the process of developing security 
plans for a law enforcement agency. 
SP 800-26: Security Self-Assessment Guide for Information Technology Systems, November 2001 
This manual outlines a methodology for conducting self-assessments of your IT 
systems. The manual provides sample questionnaires with detailed instructions for 
their use. 
SP 800-30: Risk Management Guide for Information Technology Systems, July 2002 
This manual provides an excellent overview of the risk-management process. Major 
sections address risk assessment, risk mitigation, and evaluation and assessment. 
SP 800-35: Guide to Information Technology Security Services, October 2003 
This guide provides a good overview of the roles and responsibilities within an IT 
organization. It also provides information regarding the security services lifecycle. 
SP 800-53: Recommended Security Controls for Federal Information Systems, February 2005 
This manual contains an overview of the security control process and provides 
extensive tables of security controls. The manual provides a cookbook-like approach 

Appendix D 196

to listing and explaining the different levels of security controls. The controls are 
organized into three groups: low, moderate, and high. 
SP 800-55: Security Metrics Guide for Information Technology Systems, July 2003 
This guide forms the core of the security metrics process. It is the key component that 
helps you establish the security control structure that is necessary to monitor and track 
security mitigation activities in your systems. 
Additional NIST Security Publications 
NIST manuals cover a wide variety of security subjects. Depending on your security project, 
there may be a manual that could be of great assistance to your security team. These 
additional NIST security publications are available at http://csrc.nist.gov/publications/ 
nistpubs/. 
Key FIPS Security Publications 
NIST, under the Information Technology Management Reform Act (Public Law 104-106), 
develops standards and guidelines for federal computer systems. These standards and 
guidelines are issued for governmentwide use and are titled Federal Information Processing 
Standards. While there are many FIPS publications, most are too specialized or technical for 
use in general security policy development activities. 
Two current FIPS publications would be helpful to your security program. Check online at 
http://csrc.nist.gov/publications/fips/index.html to see if updates have been made to 
either manual. The two manuals are: 
FIPS 191: Guideline for the Analysis of Local Area Network Security, November 1994 
Discusses threats and vulnerabilities and considers technical security services and 
security mechanisms for local area networks. 
FIPS 199: Standards for Security Categorization of Federal Information and Information Systems, 
February 2004 
Provides security categorization standards for information and information systems. 
These standards provide a common framework and method for expressing security in a 
quantitative manner. 
Other Federal Documents 
Global Justice Information Sharing Initiative Security Working Group, Applying Security 
Practices to Justice Information Sharing, March 2004 (version 2.0) 
This publication is available at http://it.ojp.gov/global. It is designed to educate 
justice executives and managers in basic, foundational security practices that they can 
deploy within their enterprise and between multiple enterprises. 

Security resources 197

General Services Administration, A Guide to Planning, Acquiring, and Managing Information 
Technology Systems. 
This manual is available at www.acqsolinc.com/pastperfdoc/acqguid.pdf (the web site 
of the GSA contractor that developed the guide). 
Federal Information System Controls Audit Manual (FISCAM). 
This manual describes the computer-related controls that should be considered when 
assessing the integrity, confidentiality, and availability of computerized data. Available at 
http://csrc.nist.gov/sec-cert/. 
Office of Management and Budget (OMB ) CIRCULAR NO. A-130 
This document establishes policy for managing federal information resources. Available at 
www.whitehouse.gov/omb/circulars/a130/a130trans4.html#2 
Other Security Resources of Interest 
Carnegie-Mellon University Software Engineering Institute: www.sei.cmu.edu 
Carnegie-Mellon University: www.cmu.edu 
Computer Emergency Response Team: www.cert.org 
Defense Information Systems Agency: www.disa.mil 
Department of Homeland Security: www.dhs.gov 
Generally Accepted Information Security Principles Committee: www.issa.org/gaisp/gaisp.html 
Information Security Forum: www.securityforum.org 
Information Systems Audit and Control Association: www.isaca.org 
Information Systems Security Association: www.issa.org 
International Organization for Standardization: www.iso.org 
Internet Security Alliance: www.isalliance.org 
Microsoft TechnetThe Security Risk Management Guide: www.microsoft.com/technet/ 
security/topics/policiesandprocedures/secrisk/default.mspx 
National Security Agency: www.nsa.gov 
SANS: Systems Administration, Audit and Network Security Institute: www.sans.org 
Systems and Network Attack Center (NSA): www.nsa.gov/snac 
The Center for Internet Security: www.cisecurity.org 
US-CERT: U.S. Computer Emergency Readiness Team: www.us-cert.gov 

Image of Department of Justice Seal

For More Information
U.S. Department of Justice
Office of Community Oriented Policing Services 
1100 Vermont Avenue, N.W. 
Washington, DC 20530 

To obtain details on COPS programs, call the 
COPS Office Response Center at 800.421.6770 
Visit COPS Online at www.cops.usdoj.gov 
e01071252