Health Articles

Draft agenda sia standards committee meeting - 2009/04/0

SIA Standards Committee
ISC West – Las Vegas, NV
Committee Meeting
Wednesday, April 1, 2009
10:00 a.m. to 12:00 noon
Room 507 (Venetian)
DRAFT AGENDA
1. Administrative a. Call to Order . Knight b. Attendance / Roll Call . Rigano c. Membership . Rigano d. Rigano 2. Approval of the Draft Agenda…. Knight 3. Approval 4. Chair Pro-Temp Remarks . Knight 5. External Liaison Reports a. Physical Security Equipment Action Group (PSEAG) / Security Equipment Integration Working Group (SEIWG) Update . Hernandez b. Update on SEIWG ICD-0101, Integrated Command Control Display Equipment Interface Control c. Interagency Security Committee (ISC) Update. Martin 6. SIA Standards Activities Updates a. Discussion of New Project Proposals b. Reports of Standards Subcommittee Activities Security Applications Standards Subcommittee . Peterson  SIA/OSIPS ACGO-01, Access Control for Gate Operations  SIA/OSIPS CUIS-01, Common User Interface Standard Pan Industry Data Models & Bindings Standards Subcommittee . Knight  SIA/OSIPS-01,  SIA/OSIPS IDM-01, Identity and Carrier Management Data Model  SIA/OSIPS ACR-01, Access Control Role Data Model Component Interface and Performance Standards Subcommittee . Hanssen  SIA/OSIPS APC-01, Access Point Controller Data Model. Knight  SIA/OSIPS DVI-01, Digital Video Interface Data Model . Hanssen Field Devices Interface and Performance Standards Subcommittee . (vacant)  SIA CP-01, Control Panel Standard - Features for False Alarm Reduction. Nesse  SIA PIR-01, PIR False Alarm Immunity Standard. Paton Maintenance Issues. SIA Standards VC c. SIA Standards Committee Activities SIA BoD Liaison Update . Zivney/ Knight/ Report on Other SDO and Standards Related Activities . Rigano Report on Officer Issues / Calls for Volunteers. Rigano Continuous Maintenance Update Discussion. Rigano Discussion on SIA Standards Ad Hoc . Rigano d. SISC Position Preparation . Rigano [Review Agenda Items Requiring a Vote and Prepare SIA Positions] a. Chair Candidates to Answer Questions/ - 3 minutes each then Q&A
8. Next Meeting and Adjournment . Knight

Security Equipment Integration Working
Group (SEIWG)
Briefing to Security Industry Association
1 April 09
Mr. Chris Hernandez
SEIWG Liaison to SIA

 Who is the SEIWG?

SEIWG Interface Control Documents (ICDs)
SEIWG Architecture Tasks
Vehicle Gate Work
– SIA Access Control for Gate Operations
Joint Gatekeeper Software
What is the SEIWG?
 The SEIWG is a standing
subcommittee of the
Physical Security
Equipment Action Group
(PSEAG)
 An action officer level-
working group, made up of
members of the four
services

Mission & Execution
 Mission: to coordinate and influence the
system architecture, technical design, and
systems integration of all Physical Security
Equipment (PSE) to be used within the
Department of Defense.
 Accomplished by: building and
documenting a DOD physical security
architecture.
– Operational, Systems, and Technical Views
–
Interface Control Documents (ICDs)
SEIWG Service Representatives
Current SEIWG Chair and AF Rep (Chair rotates every 2 years)
– Mr. Edward Layo,
US Marine Corps Rep
SEIWG Project Lead
– Danielle Fennelly –
– Dr. Robert Rains,
SEIWG Industry Partners
Via the AF's Integrated Base Defense Security
System ID/IQ contract, the SEIWG has used
industry partners to help prepare architecture
documents and perform Verification and
Validation (V&V) on SEIWG ICDs
– Abacus Technology Corporation, Chevy Chase, MD
ECSI International, Clifton, NJ
L-3 Communications Gov't Services, Chantilly, VA
Northrop Grumman Space and Mission
Systems Corp, Carson, CA
 SEIWG is developing "to-be" Joint Force Protection
Architecture (referred to as "holistic")
– Based on the Integrated Unit Base Installation Protection
(IUBIP) Detect, Assess, Warn, Defend, and Recover
(DAWDR) framework.
– High-level representation of Joint Force Protection suitable
for use by programs to tailor to their needs and level of detail.
– Includes select OV's, SV's, and TV-1
 Planned for Sep 09 completion.
Interface Control Documents
 SEIWG-ICD-0101- Integrates Command
Control Display Equipment (CCDE) to force
protection sensors
– CCDE to CCDE
–
More to come on this document
 SEIWG 005C- Interface Specification (Rf Data
Transmission Interfaces) For DoD Base And
Installation Physical Security Systems
SEIWG-005 A/B/C – Interface Specification for the
DoD Base and Installation Security System (BISS) –
published November 2008
– This specification defines the RF data transmissions among
physical security system components.
– SEIWG-005B is a two page addendum to 005A which
assigns a new message code to LKMD and corrects errors in
the list of unassigned message codes.
– SEIWG-005C, also an addendum to A, assigns a new
message code to BAIS.
Why use SEIWG ICDs?
 Increased interoperability
 Increased "plug and play" solutions
 Minimized RDT&E costs
 Minimized training time and costs
 Minimized sustainability costs
SEIWG-0400, the Technical Standards
Profile Technical View 1 (TV-1) is:
A listing of standards and protocols currently
available for use by the Services in the
development and procurement of physical
security systems, equipment and components
within their domain and those proposed by the
Services for use within the next 18 months.
FY09 SEIWG Efforts
 SEIWG will proceed with those items they have
in-house expertise for, including:
– Update SEIWG-ICD-0101
Address RFI comments and update SEIWG-005C
Obtain feedback on CCDE to IBDC2 use cases
SEIWG working with Air Force Institute of Technology
(AFIT) Systems Engineering Department to evaluate
 Participating in various working groups to increase
awareness of SEIWG products
Additional SEIWG Efforts
 Maintaining SEIWG SharePoint Website
– Site noted on HERBB with instructions on how to
– 230 members and increasing
–
SEIWG posts draft documents on the site for
comments from industry
 Automated Gate Operations
– Joint Gatekeeper Software (JGS) Development
–
SIA Access Control for Gate Operations
JGS Development Summary
Determine if Enabler satisfies the need for "middleware" to conduct identity management in conjunction with ACS for all services. Interface Enabler eNode server to new authoritative database(s).
Phase II Testing - Implement/demonstrate connectivity between
Enabler eNode server and notional gate access control system (ACS). Phase III Testing – Gap analysis and testing of additional
capabilities to Enabler to satisfy JGS requirements.
Develop an interface between external authoritative databases and COTS access control systems. Enabler Phase II Test Configuration
SIGNIFICANT ACCOMPLISHMENTS (To Date)
PROJECTED ACCOMPLISHMENTS (FY 2009-2011)
• Dvlpmt of JGS middleware task assigned to SEIWG Mar 08 • Phase II Enabler Testing – if authorized. Feb-Sep 09• Presented 3 Phase test plan to determine Enabler suitability to • Phase III Enabler Testing – if authorized May 09-Mar 11 • Received approval to commence Enabler Phase I test Sep 08 • Completed Phase I testing and submitted test Report. Jan 09 • Began examining various authoritative databases for potential Phase II connectivity to Enabler server. Feb - Mar USAF 642 ELSS/FPJ
POINT OF CONTACT: Mr. Roy Higgins
PHONE #: (781) 377-4790
 PSEAG Initiative: Develop Joint Gatekeeper Software
(JGS) Middleware system
– Established as SEIWG project (Mar 08 Executive PSEAG).
–
Focus: Interface between external authoritative databases and
COTS ACSs.
 SEIWG testing of Enabler System
– SEIWG accepted action to test Enabler system for viability of
providing some or all JGS capability.
– Test Enabler in 3 Phases
• Phase I – Demonstrate Current Enabler Capabilities.
• Phase II – Test Enabler/ACS Connectivity.
• Phase III – Perform Enabler/JGS Requirements Analysis/Test.
Phase I test successfully conducted 8 – 19 Dec 08
Enabler Phase II
Objectives
 Primary
Implement Enabler connectivity to COTS installation access control system
at Eglin AFB Site C-3.
Demonstrate Enabler functionality across notional enterprise installation
access control system (eNode  ACS).
Integrate/Test Enabler with additional Authoritative Database(s), e.g.,
IDProTECT, etc.
 Interface Development
Enabler  ACS interface will adhere to Enabler ICD to maximum extent
possible within bounds of directed system architecture.
Enabler  Authoritative Database interface implementation projected to
adhere to interface design/criteria imposed by Authoritative Database
Access Control for Gate Operations
 SIA Security Applications Subcommittee

Has seen broad DoD Support
– All services have participated in the development
 Can this SIA standard help move JGS towards true
Force Protection SEIWG Repository
 Open to government agencies and their contractors (an
account is necessary for access)
 Intended as a means of sharing information with the DoD
Force Protection community
 Site contains approved and draft documentation managed by
the SEIWG.
 SEIWG approved documents (e.g. SEIWG ICD 005, 0101, TV-1)

SEIWG draft documents (e.g. CCDE-IBDC2 Use Cases, V&V reports)
Miscellaneous documents (e.g. CCDE- IBDC2 White Paper, SEIWG
article, etc.)
Currently Posted Documents
 SEIWG ICD-0101 CCDE Information Interchange using XML
– Approved Jan 2009
– Defines the structure and sequencing of information for communication between
the Command and Control Display Element (CCDE) and sensors. The
prescribed interface uses the eXtensible Markup Language (XML) 1.0, as defined
by the World Wide Web Consortium. The focus of the ICD is to satisfy
requirements for Force Protection information exchange.
 SEIWG 0400 Joint Anti-Terrorism/Force Protection Technical Standards
Profile Technical View 1 (TV-1)
– Approved Nov 08
– A listing of standards and protocols currently used by the Services in the
development and procurement of physical security systems, equipment and
components within their domain and those proposed by the Services for current
and use prior to 2008. The purpose of the development of the TV-1 is to present,
through the SEIWG, a truly joint services "Technical View" by collecting and
assimilating as much applicable data from the USAF, USA, USN, and USMC.
– To be updated annually
Other useful Draft SEIWG documents are posted including:
– CCDE to IBDC2 use cases
How to get SEIWG documents
 Distribution is authorized to government agencies
and their contractors only.
 For access, see instructions on Hanscom AFB
Electronic Request for Proposals Bulletin Board
(HERBB)

Roy Higgins (AF)
Edward Layo (Navy)
Rodney Rourk (USMC)
Richard Goehring (Army)
Architecture Advisor:
Dr. Robert G. Rains (MITRE)
Why Use the TV-1?
 Saves time
– No need to conduct "open-ended" search for applicable
– The bulk of the search effort is already done for you
–
In-sync with DISR (DoD Information Technology
Standards Registry) mandated standards
– Easy to identify standards related to your particular
– Current titles and version numbers available for contract
 Creates consistency across programs
– All PMs draw from the same pool of standards
Use consistent standard versions
Security Equipment Integration Working
Group (SEIWG)
Briefing to Security Industry Association on SEIWG-ICD-0101 Danielle Fennelly SEIWG Project Manager What is it?
 Official title: Command and Control Display Equipment
(CCDE) Information Interchange using XML
 An Interface Control Document (ICD) describing XML
communication between Physical Security Equipment
sensors and CCDEs/Annunciators
 Defines the structure and sequencing of information
between system components
 Also known as SEIWG-ICD-0101 (published 5 JAN 2009)

Supercedes SEIWG ICD-0100 (currently being used
within the DoD and by industry)
What is it? - continued
SEIWG-ICD-0101 defines a set of XML messages and
supporting XML schemas describing communication
between CCDEs/annunciators and physical security
devices including:
 Two-State Detection Sensors
 Fixed Surveillance/
Line of Detection Sensors
 Delay/Denial Systems
Wide Area Detection Sensors
 Remotely Operated
Video Motion Detection
 Explosive Detection Systems
 Mass Notification Systems
 Access Control Systems
 Peer, backup or remote
CCDE nodes
Who uses the ICD?
 Government (including DoD) acquisition and
 Government agencies seeking interoperability

Security equipment vendors
System integrators to integrate equipment
manufactured by different vendors
 System Operators/Network Administrators to
properly configure the network and various
equipment interfaces
Why use the ICD?
 Increased interoperability
 Increased "plug and play" solutions
 Minimized Research, Development,
Testing, & Equipment (RDT&E)
costs
 Minimized training time and costs
 Minimized sustainability costs
Precursors to 0101 have been successfully
used in the following:
 Force Protection Joint Experiment

Joint Force Protection Advanced Security
System Joint Capability Technology
Demonstration (JFPASS JCTD)
 Tactical Automated Security System (TASS)

Secure Border Initiative - DHS program
Where does it apply?
Cameras, radar, IR
Detectors, Video,
Explosive Detection
Systems…
 Main body contains general functional information
– Network transport and communications
Issues and contingencies
– Each tab identifies message flows for specific device
 .xsd Schema files
– Embedded in Word document
.xsd files contain formatted messages found in ICD
Sample Text – Main Body
Sample Text – Appendix
Sample Schema – Basic Types
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSpy v2008 rel. 2 (http://www.altova.com) by Ravi Saxena (Raven LLC) -->
<!-- edited with XML Spy v4.4 U (http://www.xmlspy.com) by Henry C Foster (TRW) -->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:documentation>Basic types used in the Force Protection Enterprise.</xs:documentation>
<xs:documentation>Enumerates all ICD version numbers supported by the current schemas. This
approach is used instead of a numeric approach, since the ICD revision numbers vary so dramatically. The version is used in the
PlatformStatusReport and DeviceStatusReport elements, identifying which version of the ICD the device supports. This element
is also optional on the SubscriptionConfiguraitonReport.</xs:documentation>
</xs:annotation>
Device identification types
Development and Approval
 Drafting and review of ICD-0101 completed by:
SEIWG government team
All 4 DoD Services reviewed and approved ICD-
 A verification and validation was completed on
ICD-0101 to ensure that XML messages worked in
"real-world" implementations.
 To ensure this ICD remains robust, the SEIWG
encourages government agencies and industry to
propose changes/enhancements and comments.
 Changes/enhancements to this ICD may be
proposed in the following manner:
– Provide an XML schema (.xsd file)
–
Provide a clear and concise recommendation
Provide a detailed rationale for the change/enhancement.
 Proposed changes/enhancements should be sent to
How to get SEIWG documents
 SEIWG documents are located on a password
protected Sharepoint website.
 Distribution is authorized to government agencies
and their contractors only.
 For access, see directions on Hanscom AFB
Electronic Request for Proposals Bulletin Board
(HERBB)

 SEIWG Principles
Mr. Roy Higgins (USAF) – Mr. Edward Layo (USN) –
Mr. Rodney Rourk (USMC) –
Mr. Richard Goehring (USA) –
 SEIWG Project Manager
Danielle Fennelly –
 SEIWG Chief Architect
Dr. Robert Rains –
Changes from -0100
 SEIWG-ICD-0100 was published October 2006 and
has been widely used.
 SEIWG-ICD-0101 expands the basic schemas
presented in 0100 to include the communications
between
– a primary CCDE and a secondary CCDE
–
a CCDE and an access control system
SEIWG-ICD-0101 also updates the XML schemas
as appropriate and adds a new .xsd file,
(GeometryReport.xsd), which has been used to
transmit plume data from CBRNE sensors.
1. Source of the Proposed Project OSIPS Security Applications Standard for Design, Deployment, and
Operation of Video Technology for Detection, Assessment, and Forensic
Analysis
1.2 Date Submitted February 27, 2009
Rick Kelley, Security Access Design LLC
Hunter Knight, Integrated Command Software
Mark Peterson, M.C. Peterson & Associates
Gary Kleinfelter, Consultant
Per Hanssen, Salient Systems
Carolyn Ford, ITS / NTIA / U.S. Dept. of Commerce
2. Process Description for the Proposed Project 2.1 Project Type (Development or Revision) "D"
2.2 Type of Document Proposed American National Standard developed as a standard under OSIPS
Project.
2.3 Definitions of Concepts and Special Terms This standard will establish criteria for
1. the selection of video technological capabilities based on application
2. the deployment of such technology including its integration,
3. the operation of the deployed system including the operator actions,
maintenance actions, and proper practices for users of the captured
information to ensure that a predictable level of effective operation is always
present, and
4. conformity assessment test procedures and test cases as needed to provide
quality verification of claimed results.
Scenes, geographical areas of security interest, will be analyzed to establish a
classification scheme based on the use case to be served by of the application of
video for surveillance. The criteria will likely respond to a diverse set of physical
scene characteristics, behavioral characteristics, and threat characteristics and it is
expected that an abstraction of this work will permit the classification scenes in
such a way that the applicability of different types of video technology to
monitoring scenes may be developed.
Again, related to these criteria, deployment standards and operational standards
will be developed so that compliant deployed systems may be expected to deliver
the requisite images for forensic, detection, and assessment components of the
use cases.
2.4 Expected Relationship with Approved Reference Models, Frameworks, Architectures, etc. This activity will comply with and be compatible with current SIA Standards
activities including:
• ANSI / SIA OSIPS Framework
• ANSI / SIA DVI
• ANSI / SIA ACGO
• Other relevant standards as identified during the initial phases of this activity.
It is expected that other related works will be identified and added to the above list.
2.5 Recommended SIA Development Subcommittee It is recommended that this Standard be developed by the SIA Security Applications
Standards Subcommittee
2.6 Anticipated Frequency and Duration of Meetings It is anticipated that development time will fall between 18 and 24 months. It is
anticipated that eight face-to-face two-day meetings and 10 to 18 electronic
meetings averaging two hours in duration will be held during the course of this
activity.
2.7 Target Date for Initial Public Review 3rd quarter of 2010.
2.8 Estimated Useful Life of Standard or Technical Report There is no anticipated expiration time frame for the usefulness of this Standard.
3. Business Case for Developing the Proposed Standard or Technical Report The essential goal of this activity is a description of the uses of video technology,
the means to deploy it to achieve those uses, and the means of operating and
managing the deployed systems.
3.2 Existing Practice and the Need for a Standard Currently there is no prescription of this process and a need to obtain one is
essential to the implementation of the OSIPS Standards.
3.3 Implementation Impacts of the Proposed Standard 3.3.1 Development Costs The estimated time period for development of this Standard (6 to 12 months)
would include a total of 8 face-to-face meetings to be held in the offices of
the Association or other locations as determined from time to time by the
participants. Approximately six conference call meetings with 8 participants
each (estimated) for duration of 2 hours each.
It is recommended that a Technical Editor be identified for this project. The
estimated total time for the editor is 500 person hours.
3.3.2 Impact on Existing or Potential Markets The creation of this Standard will allow for greater predictability in
deployment of this technology. This will benefit the Specifier and End User
3.3.3 Costs and Methods for Conformity Assessment Conformity assessment practices will be a part of the development of the
standard, which will include a well defined set conformity assessment
program as prescribed within the OSIPS Project.
3.3.4 Return on Investment There is no known method to extrapolate the ROI or conformity assessment
costs at this time however the increased acceptance of this technology by
implementers of IT security solutions will open new markets.
3.4 Legal Considerations 3.4.1 Patent Assertions There are no known patent assertions known to the proposer.
3.4.2 Dissemination of the Standard or Technical Report There are no known IPR issues known that could hinder distribution of this
document.
4. Related Standards Activities 4.1 Existing Standards There are no known existing standards that may be affected by the proposed
project. Section 2.4 above identifies several known activities that may affect
this activity.
4.2 Related Standards Activity Section 2.4 above identifies several known activities in this area.
5. Units of Measurement used in the Standard Indicate units of measurement used in the Standard: · _ International Systems of Units (SI) · XX Not Measurement Sensitive
Project Proposal
1. The Open Security Exchange
1.1 Standardized Identity Provisioning into Building Access Control Applications
1.2 Date Submitted October 16, 2008
1.3 Proposed by the Open Security Exchange Board of Directors and Executive Director
(including Quantum Secure, HID, TYCO, HHS, DMDC) 2. The project will utilize industry experts to develop a standard for exchanging Personal Identity Verification
(PIV) enrollment data with other systems that manage PIV identity. This may include Physical Access Control System (PACS), Identity Management System (IDMS) and Facilitate Background Investigations. The purpose for defining these interfaces is to enable more automated provisioning and de-provisioning. This will include all identity attributes acquired through the US Government PIV process. The standard will consider all necessary security protocols to protect private data for identification documents and tokens (cards) whether they are stored and produced in a central site or distributed across multiple facilities. End users will need to be engaged to help the effort understand how this standard applies to government and commercial needs. • Standardize and simplify the interoperability between PIV Credentials, C-PSIMS, PACS, LACS and the Identity Management System to manage identity information from different data sources. • Define an XML-based framework for exchanging PIV Cardholder's provisioning/de-provisioning information between C-PSIMS and PACS (Physical Access Control Systems). • Incorporate existing data exchange formats for PIV credentials already defined The PACS must fulfill PIV requirements for credential validation from highest to lowest assurance levels leveraging OCSP, LDAP, Authorized Identity Bridge, etc based on an organization's implementation. PACS will be a fully integrated and tightly coupled physical and logical access control system. This system will provide federal agencies, organizations and their support contractors with a robust set of security safeguards and countermeasures. These environments must be capable of protecting federal information systems, the information stored, processed and transmitted by these systems and the facilities in which the systems reside. These systems will be deployed on Local as well as Wide area networks. The PACS will have the capability to operate in harmony with a Centralized Physical Security Information Management System (C-PSIMS). The C-PSIMS will be a standardized concept vs. a given system. The ‘Centralized Physical Security Information Management (C-PSIMS) system should interoperate in real-time with various, multi-brand, multi-technology based PACS installed in an agency along with Logical Access Control System (LACS) to create a unique interoperable bridge between physical and logical security spaces. The C-PSIMS should provide a standard based approach to manage and monitor the data transfer, devices, applications and support for PACS and LACS integration. The C-PSIMS system should conform to accepted government/industry guidelines for systems security, interconnectivity and interoperability. Consideration will consider elements of the US Government's Backend Attribute Exchange Architecture and Interface specification. Accordingly, the federal government requires a standard mechanism for organizations to obtain PIV Cardholder information (Backend Attributes) directly from the authoritative source (Attribute Authority). The authoritative source is the PIV Card Issuing Organization (PIV Card Issuer), which is the organization that issued the PIV Card to the PIV Cardholder. Access to Backend Attributes is either in real-time when immediately needed (e.g., guard suspects PIV Card tampering), or in advance of need (e.g., provisioning access to a scheduled meeting, loading a handheld device prior to field use). The exchange of Backend Attributes between backend systems is known as "Backend Attribute Exchange" (BAE). BAE is a method of exchanging PIV Cardholder information in a secure and trusted environment between an Attribute Authority (AA) and relying party. There are two BAE models and corresponding interface specifications that can be implemented: 1. Single PIV Cardholder BAE Model – Security Assertion Markup Language (SAML) based exchange of
Backend Attributes for one PIV Cardholder per request/response pair. 2. Batch Processing BAE Model – Service Provisioning Markup Language (SPML) based exchange of
Backend Attributes for multiple PIV Cardholders per request/response pair. 2.1 Development
This committee will develop a specification that addresses the required semantics for Provisioning and exchanging data requests. This specification will prescribe typical activities required for managing PIV cardholder in C-PSIMS, PACS and IDMS. • Query/Status • Global Validity Check • Identify Credential Type • Common Card Holder Attributes 2.2 Standard
American National Standard (ANSI) 2.3 Definitions of Concepts and Special Terms
OSIPS – Open Systems Integration and Performance Standard OSIPS-IDM – Identity and Carrier Management Model IDMS – Identity Management System An Identity Management System is an automated system of hardware (servers) and software
(programs) that provides the workflow management (services) of identity functions, as
normatively described in Federal Information Processing Standard (FIPS) 201, Personal
Identification Verification Standard for Federal Employees and Contractors. An IDMS is
separately layered and/or compartmentalized within one system and/or a modular component of
an agency's centralized system/enterprise. The IDMS will be encapsulated in an environment
that is secure, auditable and protect the privacy of personal information. Stakeholder1 services
must be provided in a Service-Oriented Architecture (SOA). The IDMS establishes the
centralized Chain-of Trust that is then integrated into the components of a FIPS 201 enterprise.
CMS – Card Management System A Card Management System is an application that manages the issuance and administration
of multi-function enterprise access smart cards. The CMS manages cards, as well as data,
applets and digital credentials, supported by PKI certificates related to the cards throughout
their lifecycle.
LACS - Logical Access Control Systems Logical Access Control Systems authenticate and authorize an individual to access federally
controlled information systems. Under the HSPD-12 mandate, Departments and Agencies are
required to have their logical access control systems ready to read and process the new smart
card. Logical access control systems will require use of smart card readers.
PACS - Physical Access Control Systems Physical Access Control Systems authenticate and authorize an individual to access federally
controlled government facilities. Under the HSPD-12 mandate, Departments and Agencies are
required to have their physical access controls systems ready to read and process the new
smart card.
FASC-N – Federal Agency Smart Credential Number The Federal Agency Smart Credential Number (FASC-N) is a number required on all
Federal Personal Identity Verifications that consist of a "System Code Credential
Number" to establish a credential number space of 9,999,999,999 credentials. The
FASC-N is a part of the Cardholder User Identification (CHUID).
C-PSIMS - Centralized Physical Security Information Management (C-PSIM) A simple-standard based appliance/application that will manage and monitor the data transfer, devices, applications and support for PACS, SCADA, HVAC and LACS integration. 2.4 The following standards and specifications may be applicable.
OSIPS SOAP XML SPML SAML Global Platform Messaging FIPS 201 BacNet Access Control WSDL US government Backend Attributes Exchange (BAE) specifications US government Backend Authentication Working Group (BAWG) specifications US government Architecture Working Group (AWG) specifications 2.5 Recommended SIA Development Subcommittee
Data Models and Bindings Subcommittee or Security Applications Subcommittee 2.6 Anticipated Frequency and Duration of Meetings
Four face to face meetings and additional phone conferences as required. 2.7 Target Date for Initial Public Review
January 2010 (Initial Draft by April 2009) 2.8 Estimated Useful Life of Standard or Technical Report
3. Business Case for Developing the Proposed Standard or Technical Report
3.1 Description
Identity data is made up of many related pieces of information like organization, role and personal. This standard will identify the data that needs to be exchanged and rely on existing or emerging standards to define the data namespaces. Securely transmitting this data for privacy reasons will also be considered. How this data is used and stored will also be identified so that appropriate data exchanges for identity token production and identity document exchange can take place. How authorization and authentication takes place in consideration of the FIPS-201 standards will also be considered. Global Platform messages that are already in practice may be incorporated into the standards, if practical. The need for strong authentication coupled with personal identity verification called for new standards to be adopted governing the interoperable use of identity credentials to allow physical and logical access to Federal government locations and systems. The Personal Identity Verification (PIV) for Federal Employees and Contractors, Federal Information Processing Standard 201 (FIPS 201) was developed to establish standards for identity credentials. The FIPS 201 PIV process mandates that handling of the Identity has to be secure and private. However, the FIPS standards don't define the standard interoperability framework between PIV enrollment and systems that manage identity information from a multitude of organizations. Hence, there is a need to define a framework for exchanging PIV Cardholder enrollment data between systems that manage PIV identity. 3.2 Existing Practice and the Need for a Standard
No standard exists that incorporates all of the needs for identification and security. FIPS-201 standards and Global Platform Messaging along with ANSI smart card standards individually address some needs for identification and security, but do not address how systems exchange and synchronize data for identification and security. As of September 2008, The National Institute of Standards and Technology (NIST) released Draft Special Publication 800-116 titled "A Recommendation for the Use of PIV Credentials in Physical Access Control Systems". This report defined the functional requirements for PIV cardholder enrollment in PACS, however this report stops short of defining required semantics for Provisioning and exchanging data requests. Hence this standard definition from OSE & SIA is very timely for implementation of PIV roll-outs. 3.3 Implementation Impacts of the Proposed Standard
This section addresses the potential impacts of the proposed standard. To the extent possible, the proposer is requested to address the following implementation considerations: 3.3.1 Development Costs
Assuming the a group of 10 people can bring a document to public review in one years' time, several hundred man hours will have been expended to create this standard. 3.3.2 Impact on Existing or Potential Markets
The interoperability of security and identity systems should result increasing the market opportunity for these systems. This standard should have applicability to many market segments like commercial and infrastructure markets and not only government. 3.3.3 Costs and Methods for Conformity Assessment
Performance and Capability conformance will be built into the standard. Certification will be the responsibility of companies in this area of business. 3.3.4 Return on Investment
Conformity assessment for this standard should have similar costs as other programs of this type that are verified by testing companies in this business. Return on investment should be similar to most new product development with the caution that inaction may have detrimental consequences should this standard be widely adopted. 3.4 Legal Considerations
3.4.1 Patent Assertions
Calls will be made to identify assertions of patent rights in accordance with the relevant SIA and ANSI policies and procedures. 3.4.2 Dissemination of the Standard or Technical Report
Drafts of this document will be disseminated electronically. Dissemination of the final standard will be restricted as the document becomes the property of SIA. See statement in 3.4.1regarding IP. 4. Related Standards Activities
4.1 Existing Standards
4.2 Related Standards Activity
Global Platform messaging 5. Units of Measurement used in the Standard
Indicate units of measurement used in the Standard: • X_ Not Measurement Sensitive SIA Project Proposal:
Glossary for
Electronic Security Systems
Specifications, Standards and Documentation
Source of the Proposed Project
1.1 Title:
Glossary for Electronic Security Systems Specifications, Standards and Documentation Submitted
1.3 Proposer(s)
Larry Dischert, ADT ([email protected])
Ted Nesse, Sequel Technologies ([email protected])
Process Description for the Proposed Project
Project Type (Development or Revision)
Type of Document (Standard or Technical Report)
Definitions of Concepts and Special Terms
No special terms need to be defined in the context of this proposal, but the entire objective of the project is to define concepts and special terms used to describe and specify electronic security systems. 2.4 Expected
Approved Reference Models, Frameworks,
Architectures, etc.
This glossary standard will be used as a reference document for other industry standards for electronic security systems. Over time, it will serve to improve the consistency of language used to describe security systems in new and revised standards. In a few cases, terms accepted as "preferred" for the glossary will not be consistent with language used in existing standards, as there is disagreement in terminology in existing standards. This undesirable circumstance is actually the motivation for this new standards effort. Recognizing that other existing standards won't necessarily be revised to conform to the specifications of this new standard, it is likely that the standard will describe existing terms used to describe security system features or operation, in addition to establishing a preferred term for new work. Recommended SIA Development Subcommittee (Existing or New)
While this project will be administered by the SIA Standards a working group will be formed for this development that draws from well beyond the normal SIA standards participants. Participants will be sought from ASIS, CANASA, CSAA, NBFAA, NFPA, SIA, APCOA, FARA, and SIAC, among others. Anticipated Frequency and Duration of Meetings
Twice-annual meetings would be organized around ISC events, with one additional teleconference meeting held between each ISC. Given the broad range of interested stakeholders most activity will rely on collaborative computing, stakeholder contributions, etc. and less reliance on meetings. Target Date for Initial Public Review
Estimated Useful Life of Standard or Technical Report
This standard will be subject to ongoing revision and enhancement, and may be in service for decades. Business Case for Developing the Proposed Standard or
Technical Report
3.1 Description
The objective for this project would be to collaboratively develop, for release as an ANSI standard, a glossary for terms used to describe and specify electronic security systems. The scope of the glossary would be limited to residential and commercial security systems, and residential fire systems. It would cover definitions for terms used to describe user interactions, event reporting, installation procedures and installation materials. Commercial fire, access control, video, integrated systems and consumer electronics technology are specifically excluded from the scope of the immediate project, but may be included in future deliverables. Existing Practice and the Need for a Standard
There is currently no commonly accepted glossary for terms used to discuss and specify electronic security systems. Manufacturers, standards-developing organizations and dealers use overlapping, but inconsistent, sets of terms to describe these systems. Inconsistent terminology in standards and installation manuals leads to lost time and rework in product design, agency approval testing, acceptance processes by authorities having juristiction (AHJs) and product installation. Additionally, inconsistent terminology in product development and installation documentation flows into user documentation leading to needless confusion between end-users and their security providers. It would be reasonable to plan an update to the glossary every two years after release. As new reporting technology brings end-to-end digital reporting online, and new glossary conflicts are observed, it will be desirable to update the glossary reference standard. Refer to section 3.3.4 (Return on Investment) for an example of problems caused by inconsistent terminology. Implementation Impacts of the Proposed Standard
3.3.1 Development Costs
qty
qty
item
technical editing collaboration system setup and maint. meeting preparation and followup onsite meeting 1, 8 members, 2 staff onsite meeting 2, 8 members teleconference 1, 8 members teleconference 2, 8 members on-site meeting logistics travel for meeting attendance teleconference meeting logistics correspondence and process member communications total hours 160
Note 1: non-subscription solution anticipated Note 2: mailings, agenda, minutes Note 3: teleconference and sharing expenses 3.3.2 Impact
Existing
or Potential Markets
Since compliance with the standard is voluntary, no dramatic impact on security product markets is anticipated. Significant benefits would accrue when standards developers, approval agencies, authorities having jurisdiction, consultants, integrators, installers and end users have a common set of terminology to use. 3.3.3 Costs and Methods for Conformity Assessment

One way that the glossary will be used is as a reference during the development of other
standards. As these other standards are drafted and reviewed, this glossary standard will provide
the required foundation for the language of the other standards. Thus, conformity assessment is
performed as an inherent feature of the ANSI review process, with minimal additional
development cost.
The other major use of the glossary standard is by manufacturers, as they design products for
compliance with approval agency requirements and user expectations. Clearly, compliance with
an industry standard for product terminology will provide benefits for the manufacturer in terms of
faster product approvals, and better product acceptance. This will provide substantial motivation
for compliance with the glossary standard, without a formal assessment procedure and the
associated costs.
3.3.4 Return on Investment

ROI is difficult to estimate for a foundation effort like this one, but an example of a theoretical
savings may be useful. Terminology and concepts for "panic" alarm and "duress" alarm could be
easily confused during product development, and a designer may thereby miss key requirements
required for agency approval. Should a system be submitted for approval under CP-01 with a
panic button that does not incorporate dual action activation, because the designer confused
requirements for initiating duress and panic alarms, a substantial cost for redesign and delayed
market entry could be suffered. Availability of a concise glossary that draws from existing
standards and documents would clearly allow this type of expense to be avoided.
Legal Considerations
3.4.1 Patent Assertions

No intellectual property issues are expected to arise as a result of this standard development.
3.4.2 Dissemination of the Standard or Technical Report

Like other SIA standards, this standard will be disseminated electronically during development,
and then be available for purchase from SIA when finalized.
Related Standards Activities
Existing Standards
There are no existing standards directly related to this proposed activity, but see the section 4.2, below. Related Standards Activity
There are no standards under development which are specifically related to this glossary activity, but this standard seeks to provide a foundation for all industry standards developments by providing a common glossary. It is not expected that other standards will be immediately updated, if their terminology does not match that of the proposed standard. However, over time, authors of new and revised standards will be able to reference this glossary so that needless terminology conflicts are minimized. Units of Measurement used in the Standard
While the standard is not particularly dependent on measurements, SI conventions will be used as required. SIA Board of Directors Meeting, Las Vegas, NV Education Government Relations Research & Technology Standards
635 Slaters Lane Suite 110 Alexandria, VA 22314 (866) 817-8888 Actively promote, facilitate, and advance the interests of SIA's members in the Standards arena of the security industry and related industries by:  Developing common, open, interoperability protocols and performance standards;  Representing SIA to the Security Industry Standards Committee (SISC), to other Standards Developing Organizations (SDOs), and to standards related venues Education Government Relations Research & Technology Standards
• Create significant "Value" for our members and their
customers by providing market relevant standards;
• Establish, sustain and execute a "Roadmap" approved by the SIA • Aggressively and regularly publish SIA standards; • Achieve broad diversity of participants by actively promoting SIA Standards activities; • Actively engage end users to understand the application of SIA Standards and attract industry participants.
Education Government Relations Research & Technology Standards
Why Does SIA have a
Standards Program?
Because a standards program can deliver significant value to SIA members through the development and promotion of standards for physical security and related products and services. How can we describe these values?
Education Government Relations Research & Technology Standards
635 Slaters Lane Suite 110 Alexandria, VA 22314 (866) 817-8888 Standards Define Real Markets
What value is there to good market definition?
A good standard defines a market by
identifying customers committed to specific
product and service requirements.
Education Government Relations Research & Technology Standards
635 Slaters Lane Suite 110 Alexandria, VA 22314 (866) 817-8888 Standards Reduce Risk of Entry
Into New Markets
What is risk of entry and how does it
relate to standards?
• A good standard clearly defines the
requirements for entry into a market
and the customers adopting it.
• A good standard can enlist customers
committed to a new product or service
thereby creating a market.
Education Government Relations Research & Technology Standards
635 Slaters Lane Suite 110 Alexandria, VA 22314 (866) 817-8888 Standards Create Obstacles For
How can open, public standards create
obstacles to competition?
• Good standards define functionality, behavior,
and performance and the metrics to measure
compliance.
• Well defined metrics identify products and
services that don't meet the standard.
Education Government Relations Research & Technology Standards
635 Slaters Lane Suite 110 Alexandria, VA 22314 (866) 817-8888 Standards Ease Product
Adoption by New Customers
How does a good standard make
products more attractive?
Products that conform to good standards
are more likely to be adopted than those
that cannot be relied upon for the future.
Education Government Relations Research & Technology Standards
635 Slaters Lane Suite 110 Alexandria, VA 22314 (866) 817-8888 Standards Drive Product Value
How can standards make products better?
• A good standard is defined by requirements that meet the
constituency of the market segment that adopts it.
• Compliance with a good standard often requires extension of a
product. This tends to move the competitive focus from the
minimum capabilities of the standard to extending capabilities
and adding value.
• Expanding capabilities increases product value proposition and
may increase the size of the market.
Education Government Relations Research & Technology Standards
635 Slaters Lane Suite 110 Alexandria, VA 22314 (866) 817-8888 Standards Protect Your
How might a standard protect a market?
• A good standard defines customer (market
segment) requirements and provides a way to
measure product compliance.
• Competitors entering the market must offer at
least equal value less they be revealed.
Products may be targeted to specific markets and
specific levels of performance.
Education Government Relations Research & Technology Standards
635 Slaters Lane Suite 110 Alexandria, VA 22314 (866) 817-8888 Good Standards Are A
Contract Between A Market
And Capable Suppliers
But, How Do You Get Good
Education Government Relations Research & Technology Standards
635 Slaters Lane Suite 110 Alexandria, VA 22314 (866) 817-8888 • Identify and focus on standards that are
of interest to significant collections of
customers who will support the
standard.
• Participate in the process so you may
 Influence the direction of the standard Influence creation obstacles for competition Maintain influence over requirements evolution Achieve early compliance with the emerging Education Government Relations Research & Technology Standards
635 Slaters Lane Suite 110 Alexandria, VA 22314 (866) 817-8888 Standards Can Be Used To…
Standards Can
Standards Can Work
Lead, Organize, and
To Broaden Markets
Organize A
MARKET SIZE
Education Government Relations Research & Technology Standards
635 Slaters Lane Suite 110 Alexandria, VA 22314 (866) 817-8888 SIA's Standards Strategy
…Standards Customers Want!
• Create SIA Application Standards that
customers understand and want, and that
mandate components that comply with SIA
Component Standards
• Create SIA Component Standards that are the
foundation of SIA Application Standards
 Historical vs. Emerging Create SIA Foundational Standards that
empower SIA Component Standards and
facilitate their development
Education Government Relations Research & Technology Standards
635 Slaters Lane Suite 110 Alexandria, VA 22314 (866) 817-8888 What Do Customers Think?
Education Government Relations Research & Technology Standards
What Do Members Want?
On a scale of one to five, with one "Very Important" and five "Not Important
at All," please rate the importance of each of SIA's core services.
Not Important
No Opinion
Research
& Technology
SIA 2009 Member Satisfaction Survey Education Government Relations Research & Technology Standards
635 Slaters Lane Suite 110 Alexandria, VA 22314 (866) 817-8888 What Do We Do?
On a scale of one to five, with one "Very Active" and five "Not Active at All,"
please rate your level of activity with each of SIA's four core services.
Not Active at
Very Active
Research
& Technology
SIA 2009 Member Satisfaction Survey Education Government Relations Research & Technology Standards
635 Slaters Lane Suite 110 Alexandria, VA 22314 (866) 817-8888 How Do WE Do Better?
Education Government Relations Research & Technology Standards
635 Slaters Lane Suite 110 Alexandria, VA 22314 (866) 817-8888

Source: http://securityindustry.org/SiteAssets/Standards/SIA%20Standards%20Commitee/Agenda_2009-04-01.pdf