SOLICITATION NOTICE
70 -- Information Assurance/Security Services
- Notice Date
- 9/14/2004
- Notice Type
- Solicitation Notice
- NAICS
- 541519
— Other Computer Related Services
- Contracting Office
- Defense Information Systems Agency, Procurement and Logistics, DITCO-Scott, P.O. Box 25857, Scott AFB, IL, 62225-5406
- ZIP Code
- 62225-5406
- Solicitation Number
- Reference-Number-RFISECURITYSERV1
- Response Due
- 10/15/2004
- Archive Date
- 10/30/2004
- Description
- 1. Introduction: Net-Centric Enterprise Services (NCES) provides the foundation for network-centric operations by creating a set of nine core services for joint and service systems to use. NCES is part of the larger Global Information Grid (GIG) Enterprise Services (ES). The GIG ES supports the entire Department of Defense?s Information Technology (IT) requirements, including the Business and Warfighting domains, as well as interfaces with the national Intelligence Community (IC) domain. As the enterprise services component of the Global Information Grid, NCES is the infrastructure on which Department of Defense (DoD) computer applications (e.g., C2, Combat Support, and Medical) rely. This new environment must (1) support posting data to common storage spaces as early as possible; (2) alert edge users to changes in relevant DoD information or time-critical events affecting their survival or threatening their mission; (3) provide users, down to the last tactical mile, with the capability to pull whatever they want, whenever they want, from wherever they are and limited only by the commander?s information management policy; (4) ensure information assurance (IA)/security; and (5) support interoperability among allies, coalition, and multinational partners. NCES relies upon the GIG transport services and tactical communications systems for the exchange between the Core Enterprise Services (CESs) and the Community of Interest (CoI) capabilities. Transport is not an inherent component of NCES; however, the CESs are dependent upon adequate bandwidth and availability of the GIG infrastructure to support the domains and CoIs. The specifications listed below are used to support this architecture: SOAP Version 1.1 WSDL Version 1.1 UDDI Version 2.0 WS-Interoperability Basic Profile 1.0a XACML Version 1.1 SAML Version 1.1 XML-DSIG W3C Recommendation 2002-02-12 XKMS Not yet supported WS-Security 1.0 ? SOAP Message Security 1.0 ? X.509 Token Profile Draft 04 ? SAML Token Profile 2. Security Core Enterprise Services (CESs) The Security CESs, consist of a number of functional service groups, each of which may include one or more service interfaces that perform specific tasks. 2.1 Policy Services This service group provides policy-based authorization and access control for Web Services and system resources. 2.1.1 Policy Decision Service 2.1.2 Policy Retrieval Service 2.1.3 Policy Administration Service 2.1.4 Policy Subscription Service 2.2 Credential Management Services This group of services provides access to the underlying DoD PKI infrastructure. The group is envisioned to offer a subset of XKMS functionality, starting with the X-KISS spec and potentially moving into X-KRSS as well. 2.2.1 Certificate Validation Service 2.2.2 Certificate Registration Service 2.2.3 Certificate Retrieval Service 2.3 Attribute Services In order to support policy-based decisions, various attributes are needed. This includes those of the principals, the system resources, and the application environment. This service group provides standard access mechanisms for such attributes, and defines how attribute queries are returned as SAML attribute assertions. The request-response mechanism is also based on the standard SAML Protocol. 2.3.1 Principal Attribute Service 2.4 Trust Domain Federation Services The Trust Domain Federation Services is responsible for managing a trust domain?s trust relationships with other domains. Its interfaces may include registering and deregistering other domains as trusted parties, and inquiring about established trust relationships. 2.5 Security Context Services These services provide mechanisms for sharing security contexts across multiple Web Services. Such contexts are necessary in a dynamic SOA environment where indirect or brokered trust relationships abound. For example, when service A invokes service B on an end-user?s behalf, a common security context can help establish a boundary for this unit of work so that, for instance, service A cannot forward the request to an unintended service C even if A possesses a valid user assertion. In an enterprise service environment, security contexts are important in addressing service orchestrations and workflows. They may also help improve efficiency especially in interactive scenarios. For example, results of certain authentication and authorization steps may be performed only once for a series of consumer-provider interactions within a common security context. Currently there are standards proposals under development such as WS-Trust, WS-SecureConversation, and WS-Coordination that address this topic. Future service specifications will consider conformance to them once they become approved. 2.6 Auditing and Logging Services Enterprise auditing is also an important requirement for the security architecture. Two pieces of functionality need to be provided: recording the service level activities (logging), and identifying anomalies (such as access violations or attacks) from those records. The logs include: --Outbound message information (message ID, sending timestamp, host, target service, etc.) --Inbound message information (message ID, receiving timestamp, etc.) --Message signature verification (success / faults) --Certificate validation and status checking results (success / faults) --Policy decision results (permit / deny / indeterminate) --Invocation status (resource, action, success / faults) --Remote logging and auditing 3. Questions Vendor and Information Assurance/Security Services information 3.1 Company Name? 3.2 Point of Contact? 3.3 Web Site? 3.4 Product Name? 3.5 Product Description? Responses to the following questions should address Security Services capabilities. 3.6 Which service(s) does the product support? Be specific for example ? Product supports Policy Services (2.1), Policy Decision Service (2.1.1) and Policy Administration Service (2.1.3). 3.7 Does the product(s) comply with the Architecture Specifications? If Yes list specifications. 3.8 Describe the scalability of each product(s)? Responses to these questions will address some Government policy compliance 3.9 Has the product(s) been National Information Assurance Partnership (NIAP) validated? If yes to what level? 3.10 If Crypto Module, is it FIPS 140-2 complaint? 3.11 FIPS 186-2 compliant? Responses to the following questions will address product maturity that can be useful in the lifecycle benefit and cost analysis. 3.12 What are the costs or rates for all product/s including integration engineering discussed in your response to this RFI? 3.13 What is your companies corporate support policy? 3.14 Has a US Government organization used or sponsor this product? If yes, provide POC. 3.15 What are scheduled capability enhancements for this product in 2004 and 2005? 3.16 What is the schema and cost for licensing? 4. DISCLAIMER THE GOVERNMENT DOES NOT INTEND TO AWARD A CONTRACT ON THE BASIS OF THIS RFI OR TO OTHERWISE PAY FOR INFORMATION RECEIVED IN RESPONSE TO THIS RFI. However, this RFI will be the basis for collecting information on products available, and as a result of information received, the government may enter into Product Loan Agreements for trial and testing of products identified. This RFI is issued for information and planning purposes only and does not constitute a solicitation. All information received in response to this RFI that is marked Proprietary will be handled accordingly. The Government shall not be liable for or suffer any consequential damages for any proprietary information not properly identified. Proprietary information will be safeguarded in accordance with the applicable Government regulations. Responses to the RFI will not be returned. Whatever information is provided in response to this RFI will be used to assess tradeoffs and alternatives available for determining how to proceed in the acquisition process for the Security Service products. In accordance with FAR 15.201(e), responses to this RFI are not offers and cannot be accepted by the Government to form a binding contract. 5. HOW TO RESPOND TO THIS RFI Prior to submitting RFI responses, Offerors shall register with DITCO via its Contracting Opportunities web site at https://www.ditco.disa.mil/dcop. During the registration process, choose the option for ?The solicitation requires vendor registration for eligibility?. You will be prompted to enter the RFI reference number. Upon completion of registration, Offerors will receive a user-id and password for use when uploading RFI responses. This process allows DITCO to precisely track when responses are uploaded (or attempted to be uploaded). DITCO personnel will verify registration information, which takes about a day. Once the Offeror?s information is verified, you will be able to upload your RFI responses. Vendors should register a minimum of one week prior to uploading an RFI response to ensure the upload is accomplished by the closing date and time. Vendors should also attempt to upload their response as early as possible to ensure no problems arise at the last minute. If a vendor would like to test the upload process, they may do so by typing in this url: https://www.scott.disa.mil/dcop. Under the heading Submit Proposals for:, look for Upload Proposal Test. If you have any problems, please contact Kevin Mehlan at (618)229-9334, email address: mehlank@scott.disa.mil, or the DITCO customer service center at (618) 229-9333. The Government may request additional information or discuss information received in responses to this RFI with individual responders. DISA shall consider meeting individually with interested respondents. Such meetings shall be constrained to one hour for presentation and discussion.
- Place of Performance
- Address: Falls Church/VA
- Zip Code: 22041
- Zip Code: 22041
- Record
- SN00672591-W 20040916/040914211612 (fbodaily.com)
- Source
-
FedBizOpps.gov Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |