|
July 27,
2009 |
|
|
Target
(Strategic) |
Emerging |
|
OSI
Layer 1 – Physical |
|
|
Network |
|
|
Category 6 UTP 50/125 micron multimode fiber, 10/125
micron single mode fiber Structured cabling systems, based on
TIA/EIA 568, 569, 606, 607 standards and applicable electrical codes Intra-building
Wireless: IEEE 802.11 WLAN Logical star or mesh topology,
Logical meshed topology |
Infrastructureless,
Jini technology-mobile “ad-hoc” service-based networking Ultra-wideband
(UWB) transmission |
|
Security |
|
|
Keys, locks, badges, cameras, access
logs, controlled access systems, IP-based access control systems |
Biometrics |
|
Platform |
|
|
SCSI, iSCSI Single application smart cards Multi-function smart cards |
Trusted Platform |
|
OSI
Layer 2 – Data Link |
|
|
Network |
|
|
Open, standards-based, multi-service
networks 100 Mbps/1 Gbps/10 Gbps IEEE 802.3
Ethernet Wireless: IEEE 802.11 WLAN, IEEE
802.16 WMAN, IEEE 802.15 WPAN Resilient Packet Ring (RPR), SONET |
Emerging packet- and cell-based
wireless and satellite protocols 40 Gbps IEEE 802.3 Ethernet |
|
Switched
LAN technology IEEE
802.1p/Q QoS, Diffserv, RSVP, VLAN, IEEE 802.3af PoE |
|
|
Security |
|
|
Media Access Control (MAC) Access
Control Lists (ACLs) VPN, RADIUS Intrusion prevention, vulnerability
scanning Wireless: IEEE 802.11i, WAP, PEAP w/ IEEE 802.1x |
|
|
OSI
Layer 3 - Network |
|
|
Network |
|
|
IPv4, IPv6, Routing Technologies: BGP, OSPF,
IS-IS, MPLS, IGMP, PIM, MBGP DHCP Converged networks with QoS,
prioritization, and traffic flow control for all services, switched,
multi-segment design Multi-layer switching Layer 3, wire-speed, network-level
switching and prioritization |
|
|
Security |
|
|
Integrated firewalls - Packet
filtering, ICMP Boundary/perimeter Routers, end-point security, static NAT,
IPSec End point security – individual
firewalls |
|
|
OSI
Layer 4 - Transport |
|
|
Network |
|
|
TCP, UDP Wireless: WDP, Wireless Profiled TCP RTP, RTCP Converged networks with QoS,
prioritization, and traffic flow control for all services Layer 4, wire-speed, transport-level
switching and prioritization |
Wireless: 4G |
|
Security |
|
|
Integrated firewalls - stateful
inspection, dynamic NAT SSL, SSH, TLS Wireless: WTLS SSL VPN[i] |
|
|
OSI
Layer 5 – Session |
|
|
Network |
|
|
DNS |
Wire-speed, intelligent,
session-level switching and prioritization |
|
OSI
Layers 6 – Presentation, 7 – Application |
|
|
Network |
|
|
SNMP, RMON H.323, SIP with SDP, SAP, RTSP |
Wire-speed, intelligent,
content-level switching and prioritization |
|
Security[ii] |
|
|
Integrated
firewalls - Application-proxy gateway, Proxy Servers, Dedicated Proxy Servers FTP,
S/MIME for mail servers Encryption Technologies: PKI, OpenPGP, AES, 3DES, DSS Smart
cards, Kerberos Role-based
administration, permissions, and rights Digital signature, Public Key
Certificates, PKI Virus/malicious
code protection software Firewalled
DNS, with services placed on DMZ Standards-based
platform sign-on with role-based administration Industry-standard
and vendor-neutral APIs for identification Strong password policy FIPS 140-3 LDAP |
AVDL Multi-function
smart cards Mobile
agents Single sign-on across platforms[v], session Identity
federation across web-based applications, sessions |
|
Token-based
identification |
Human Authentication API[vi] Web
Services: WS-Security including: Security Profile, Policy (QoS), Privacy,
Secure Conversation, Trust, Authorization, Policy Assertions, Security
Policy, Federation, Attachments |
|
Platform[vii] |
|
|
Platforms having open
industry-standard operating systems (OS), with imbedded security, and
open-standard interfaces and drivers DMI[viii] |
Platforms having open
industry-standard OS, with imbedded security, multifactor authentication,
intelligent I/O, and open-standard interfaces/drivers CIM[ix] |
|
Platforms having industry de facto
standard OS, with imbedded security, and open-standard interfaces/drivers.
For example: o Mainframes with TCP/IP, SIP, Open
APIs o Servers with TCP/IP, SIP, Open APIs o IP telephony with TCP/IP, SIP, H.323,
ISDN PRI, open APIs, standard MOS codecs o Hybrid IP telephony (TDM/IP) systems
with TCP/IP, SIP, H.323[x],
ISDN PRI, open APIs, standard MOS codecs o Network Attached Storage o Direct Attached Storage o Storage Area Networking with
multi-use access channels o End user (client) devices (PCs,
Network Computers, PDAs, etc.) with wired/wireless connectivity, TCP/IP and
multi-function applications |
|
|
Platforms having niche proprietary
OS, with imbedded security, and open-standard interfaces and drivers
(requires exceptional business requirements) SNMP management of platforms |
|
|
Platforms deployed on target
networks, with class of service (CoS) and quality of service (QoS) |
|
|
Software |
|
|
n-tier
distributed software applications emphasizing client (State employee,
community of interest, public customer) productivity and performance
enhancements and enablers (decision-making at the appropriate level) through
self-service, self-administration, etc., utilizing browser-based (HTTP,
HTTPS) client access deployed on Target Platform Architecture server,
storage, and client devices Traditional,
monolithic State software applications with web-enabled, browser-based (HTTP,
HTTPS) client access |
Software
applications hosted via ASPs |
|
Three-tier
distributed software applications with access to n-tier architecture services |
|
|
C++,
Java™, Visual Basic®, etc. |
|
|
Java™
and servlet software, COM™, DCOM™ CORBA,
ORB, ISO/IEC 11179 Open
API Middleware:
TPM, RPC, RMI, JMS, MOM EJB™
server-side deployment, COM+ HTTP,
HTTPS Web
Services: open, industry-std., XML, DSML, SOAP[xi],
SAML, JSP, ASP, JNDI, J2EE™,.NET, BizTalk[xii] HTML,
XHTML Wireless:
WAP, WAE, WSP, WTP, WML, XHTMLMP,
CSSMP, VoiceXML, wireless profiled HTTP |
Object-oriented
software IIOP[xiii] ESB[xiv] Web
Services: open, industry-std., WSDL, UDDI initiatives, BPEL, WS-Coordination,
WS-Transaction, XQuery, XMLA, WSUI. WSRP, RDF, EbXML secure exchange of information,
UML™, XSL, CSS3, XSLT J2ME™ for
resource-constrained mobile networking |
|
GUI
presentation layer access to software as a precursor to browser-based (HTTP,
HTTPS) access Browser-based
(HTTP, HTTPS) access to software Software
applications that are manageable with SNMP-based management tools LDAP
directory services Software
application security[xv] |
Portal-based
universal browser access to all services SOA[xvi] Enterprise
LDAP directory services, WBEM, DEN, CIM |
|
RDBMS Open
database connectivity: SQL, ODBC, OLE DB, NDMP, NFS, CIFS, JDBC Database
middleware that uses open database connectivity Email
services: SMTP, S/MIME, IMAP4, POP3 Productivity
software with open APIs |
OODBMS,
ORDBMS Productivity
software conforming to IETF standards such as iCalendar, CAP, IPP, etc. |
*
NOTE:
Target Technologies are based on IT industry standards
and trends for acceptable use in government and private organizations. Target deployments shall be based on the most
currently available version, release, model, etc. Target technologies identified in Blue Font are previous emerging technologies not yet
published in statewide IT standards. Emerging Technologies are developing products
that are being reviewed by the IT industry that may not be completely beta
tested or prevalent in the industry and/or market place; or the state may not
be prepared to deploy as target at this time.
TARGET TABLE END NOTES:
[i] The most important
distinction is what each SSL VPN gateway presents to clients: how it
communicates with clients, what applications it enables, and how it secures
those applications. Almost all suppliers (with one exception) support
reverse-proxy mode for authenticating VPN sessions through Web browsers, but
some vendors don't extend reverse-proxy support to older browsers or operating
systems - which could cause compatibility problems for certain SSL VPN
applications, such as those targeting e-commerce.
[ii] Draft FIPS 140-3 is the proposed revision of FIPS 140-2. The draft specifies five security levels instead of the four found in FIPS 140-2; has a separate section for software security; requires mitigation of non-invasive attacks when validating at higher security levels; introduces the concept of public security parameters; allows the deference of certain self-tests until specific conditions are met; and strengthens the requirements on user authentication and integrity testing.
FIPS PUB 140-2 was signed on May 25,
2001. NVLAP accredited Cryptographic Modules Testing (CMT) laboratories perform
validation testing of cryptographic modules. Cryptographic modules are tested
against requirements found in FIPS PUB 140-2, Security Requirements for
Cryptographic Modules. NIST and CSE have completed the FIPS 140-2
Derived Test Requirements document. CMT laboratories may begin testing
cryptographic modules against the FIPS 140-2 DTR and submit validation reports
to NIST/CSE. The FIPS 140-2 DTR will remain draft for a period of time to allow
the CMT labs to use the document and provide comments to NIST/CSE. The FIPS
140-2 DTR will be updated as appropriate.
[iii] The Open
Group’s Distributed Computing Environment (DCE) maintains the LDAP standard.
For a guide to additional information on LDAP and related standards work, see http://www.opengroup.org/directory/, the Directory
Interoperability Forum.
[iv]
a. Single directory integration: merge the existing
directories as a part of a single enterprise directory. This approach would
involve taking each existing directory service, and integrating it as a part of
another directory service. The result of this is that all the directory
services simply behave as a single directory, and from the user standpoint the
directories are merged into one.
b. Deploy directory synchronization: allow multiple
directories to exist, with information synchronized between them. This approach
would use techniques to share data between directory services. The result of
this is that multiple directory services share common data. The user perception
of this is that each of the directories contains the same information -
typically in this situation a user will only connect to one of the synchronized
directories.
c. Loose directory interconnection: Provide a common user
interface to multiple directories. This approach would recognize that there are
multiple directories with different information contained in them, and it would
provide the user with convenient mechanisms to access all services
independently (e.g. using WWW). World Wide Web is the ideal framework for
providing 'loose' interconnections. To enable integration of directory servers
into the Web, just connect a WWW interface onto a directory service. Use of
this technique with multiple directories gives a straightforward 'loose'
interconnection.
[v] Rather than requiring developers to implement
security into each application or node, this is a centralized concept to
application security enforcement and management. Typically a two-step
architecture that consists of a security server augmented by multiple "web agents" that
connect the central security server to a variety of app server platforms,
including Microsoft's IIS, Open Source
Apache and Tomcat, and J2EE app servers BEA WebLogic and JBoss, Oracle's 9iAS,
IBM’s WebServer, etc. Idea is to deploy service-oriented architecture into
heterogeneous environments that scales appropriately for the volume
requirements.
[vi] BIOAPI 2.0 has been defined and products are
starting to be built to this standard. BioAPI 2.0 is the foundation of much
ongoing standardization activity within SC37, and other standards (including
biometric profile standards) are being layered upon BioAPI 2.0 and require its
use. Examples are, the Biometric Interworking Protocol (BIP) standard (ISO/IEC
24708) extends BioAPI 2.0 to enable an application running on a machine to use
a BSP running on a different machine as though it were running locally; and the
BioGUI amendment to BioAPI 2.0 provides an enhanced GUI callback functionality
and enables an application to closely control the low-level flow of a complex
enrollment operation driven by the subject (or by an enrollment supervisor, or
by both).
[vii] Red Hat maintenance and support for Red Hat linux
7.1, 7.2, 7.3 and 8.0 will end as of 31st December 2003, and for Red Hat 9 as
of 30th April 2004. "Red Hat does not plan to release another product in
the Red Hat Linux line," Red Hat today announced that Red Hat Enterprise
Linux 5, expected in 2006, will include "fully integrated server
virtualization capability." That capability is expected to be achieved
working with the Xen open source virtualization community. The Xen project got
the backing
of IBM in January 2005 and has been included as part of Novell's SUSE Linux
since version 9.3 was released
in March, 2005.
Future
versions of the commercial Solaris operating system - Solaris 11, Solaris 12,
Solaris 13, and so on - will be based on the code that the OpenSolaris
community creates. Sun will take OpenSolaris and qualify and certify it on
specific pieces of gear and for specific sets of software - this will be Sun's
value add, and what it charges money for in some form or another (very likely
through tech support services).
[viii] DMI generates a standard
framework for managing and tracking components in a desktop pc, notebook or
server. DMI was the first desktop management standard. Due to the rapid
advancement of DMTF technologies, such as CIM, the DMTF has defined an "End of Life" process for its Desktop
Management Interface (DMI), which will take place through March 31, 2005.
[ix] CIM provides a common definition of
management information for systems, networks, applications and services, and
allows for vendor extensions. CIM’s common definitions enable vendors to
exchange semantically rich management information between systems throughout
the network. CIM is composed of a Specification and a Schema. The Schema
provides the actual model descriptions, while the Specification defines the
details for integration with other management models. The
latest version of the Schema, CIM 2.9.0, introduces the new diagnostic components
needed for the DMTF’s Common Diagnostic Model (CDM), version 2. With the
inclusion of CDM 2.0’s enhanced multi-vendor diagnostic capabilities, CIM 2.9.0
will play a key role in improving system reliability, availability and
serviceability for end users.
[x] A current status of the H.323 standards is
maintained at http://www.packetizer.com/voip/h323/doc_status.html
Substantial work is underway to modernize this standard such that it is more
competitive with the SIP std.
[xi] Web Services use a communication
protocol named SOAP to pass data between the client and the server. Simple
object access protocol (or SOAP) is a remote procedure call protocol via the
Internet. A Web Service message is an HTTP M-POST request, in which the body of
the request is an XML document. The procedure executes on the server, which
then replies with message content formatted in XML. The WSDL (or Web Services
Description Language) describes the format and content of the message, and
publishes exactly what is needed to communicate to any given web service
method. Web Services eliminate the interoperability issues of existing
solutions, such as CORBA and DCOM, by leveraging open internet standards. Also,
since Web Services use HTTP through port 80, it gets around firewall security
in ways that DCOM and CORBA cannot.
[xii] A workflow engine is the component
in automated workflow services that knows all the procedures, steps in a
procedure, and rules for each step. The workflow engine determines whether the
process is ready to move to the next step. In general, workflow management
focuses on processes rather than documents. A number of vendors make workflow
automation products that allow an organization to create a workflow model and
components such as online forms and then to use this product to manage and
enforce the consistent handling of work. Examples include: Microsoft BizTalk 2004,
Handysoft BizFlow, NMS Imaging E-Flow, Open Text LiveLink, Oracle Workflow
Sitescape, and Oracle Workflow/9i+
[xiii] Networks that employ TCP/IP can
take advantage of IIOP compliant distributed objects. New
object-oriented business applications should be portable object adapter (POA)
compliant. POAs are written using IDL. POA standards replace Basic Object
Adapter (BOA) standards, which produced language specific adapters.
[xiv]
An ESB is a Webservices-capable integration
infrastructure that supports communication and mediates application
interactions. To be an ESB, an integration subsystem must:
1)
implement program-to-program communication (always supporting Simple Object
Access protocol/Hypertext Transfer Protocol [SOAP/HTTP], and almost always
supporting SOAP on message-oriented middleware [MOM] and plain MOM);
2)
support other Web services standards (including Extensible Markup Language
[XML] and Web Services Description Language [WSDL]);
3) be
capable of service discovery, binding and virtualization (transparently
substituting alternative service providers) and intelligent message routing;
4) have
an extensible, intermediary-based architecture so that additional features can
be plugged in; and
5) have
an awareness of message schemas through the use of metadata.
[xv]
Message Authentication
Block Cipher-based MAC Algorithm (CMAC)
Overview:
The CMAC algorithm is specified in Special
Publication 800-38B dated May 2005, Recommendation for Block Cipher Modes
of Operation: The CMAC Mode for Authentication. CMAC can be considered a mode
of operation of the block cipher because it is based on an approved symmetric
key block cipher, such as the Advanced Encryption Standard (AES) algorithm
currently specified in Federal Information Processing Standard (FIPS) Pub. 197.
CMAC is also an approved mode of the Triple Data Encryption Algorithm (TDEA).
Testing
Requirements:
CMT labs can test for conformance to the CMAC algorithm in Special Publication
800-38B. The testing requirements for this algorithm can be found in the
document titled The CMAC
Validation System (CMACVS). Additional testing note: The underlying
NIST-Approved symmetric key algorithm must be validated as part of the CMAC
validation. Currently, NIST approves both the AES and TDES algorithms for use
with CMAC.
Validation
List:
NIST maintains the current CMAC Validations. CMAC Validations are included on
the validation list of its approved symmetric key block cipher -- therefore it
is included on either the AES Validation List or
the TDES
Validation List.
Test
Vectors:
CMAC Test Vectors - These files provide an electronic version of the test
vectors that can be used to informally verify the correctness of a CMAC
algorithm implementation using the CMACVS. However, use of these vectors does
not take the place of validation obtained through the Cryptographic Algorithm
Validation Program (CAVP).
Counter with Cipher Block Chaining-Message
Authentication Code (CCM)
Overview:
The Counter with Cipher Block Chaining-Message Authentication Code (CCM) is
specified in Special
Publication 800-38C dated May, 2004, Counter with Cipher Block
Chaining-Message Authentication Code (CCM). CCM is based on an approved
symmetric key block cipher algorithm whose block size is 128 bits, such as the
Advanced Encryption Standard (AES) algorithm currently specified in Federal
Information Processing Standard (FIPS) Pub. 197 [2]; thus, CCM cannot be used
with the Triple Data Encryption Algorithm [3], whose block size is 64 bits.
Currently the only NIST-Approved 128 bit symmetric key algorithm is AES.
Testing
Requirements:
CMT labs can test for conformance to the CCM algorithm in Special Publication
800-38C. The testing requirements for this algorithm can be found in the
document titled The
Counter with Cipher Block Chaining-Message Authentication Code (CCM) Validation
System (CCMVS). Additional testing note: The underlying NIST-Approved 128
bit symmetric key algorithm must be validated as part of the CCM validation.
Currently, the only 128 bit symmetric key algorithm approved by NIST is AES.
Validation
List:
NIST maintains the current CCM Validations. CCM Validations are included on the
validation list of its approved symmetric key block cipher whose block size is
128 bits-- therefore it is included on the AES Validation List. NIST
maintains the original CCM
Validation List. for historical purposes. The information contained on the
CCM Validation List has been duplicated in the AES Validation List.
Test
Vectors:
CCM Test Vectors - These files provide an electronic version of the test
vectors that can be used to informally verify the correctness of a CCM
algorithm implementation using the CCMVS. However, use of these vectors does
not take the place of validation obtained through the Cryptographic Algorithm
Validation Program (CAVP).
Keyed-Hash Message Authentication Code (HMAC)
Overview:
The Keyed-Hash Message Authentication Code (HMAC) is specified in FIPS 198
dated March 6, 2002, Keyed-Hash Message Authentication Code (HMAC). This
algorithm utilizes the Secure Hash Algorithms as an underlying primitive.
Testing
Requirements:
CMT labs can test for conformance to the HMAC algorithm in FIPS 198. The
testing requirements for these algorithms can be found in the document titled The Keyed-Hash Message
Authentication Code (HMAC) Validation System (HMACVS). Additional testing
note: All underlying SHA algorithm(s) supported by the HMAC implementation must
be validated as part of the HMAC validation.
Validation
List:
NIST maintains the current HMAC Validation List.
Test
Vectors:
HMAC Test Vectors - These files provide an electronic version of the test vectors
that can be used to informally verify the correctness of an HMAC algorithm
implementation using the HMACVS. However, use of these vectors does not take
the place of validation obtained through the Cryptographic Algorithm Validation
Program (CAVP).
Data
(Message) Authentication Code (MAC)
and Key Management Using ANSI X9.17
The
automated conformance tests for FIPS 113 and 171 are no longer operational. Currently,
if a FIPS 140-1 or FIPS 140-2 cryptographic module implements either of these
two standards, the CMT
testing laboratories perform some testing that these FIPS requirements are
implemented correctly in the cryptographic module.
Message
Authentication Code (MAC), FIPS 113
The MAC
Validation System (MVS) tested for compliance with FIPS 113, Computer Data
Authentication. A list of validated products is maintained by the Security Technology
Group.
Key
Management Using ANSI X9.17, FIPS 171
The Key Management
Validation System (KMVS) tested for compliance with FIPS 171, Key Management Using ANSI
X9.17. A list of validated products is
maintained by the Security Technology Group.
[xvi] SOA is a set of components which
can be invoked, and whose interface descriptions can be published and
discovered. See: Web Services Glossary (http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#component)