MODIFICATION
70 -- Information Assurance/Security Services
- Notice Date
- 10/1/2004
- Notice Type
- Modification
- 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
- 11/1/2004
- Archive Date
- 11/16/2004
- Point of Contact
- Linda Goff, Contract Specialist, Phone 618-229-9486, Fax 618-229-9440, - Linda Goff, Contract Specialist, Phone 618-229-9486, Fax 618-229-9440,
- E-Mail Address
-
goffl@scott.disa.mil, goffl@scott.disa.mil
- 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 systems providing 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 WSDL UDDI WS-Interoperability XACML SAML XML-DSIG XKMS WS-Security X.509 Token Profile 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 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. In the future, this service group may also support credential technologies other than PKI. 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 to such attributes. The request-response mechanism is the standard SAML Protocol. Responses to attribute queries are in the form of SAML attribute assertions. 2.3.1 Principal Attribute Service 2.4 Trust Domain Federation Services This group of services is responsible for supporting the management of 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 This group of services provides mechanisms for establishing, expressing and controlling 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 the management of 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 Logging and Auditing 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 abuse of privilege, 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 / failure) -Certificate validation and status checking results (success / failure) -Policy decision results (permit / deny / indeterminate) -Invocation status (resource, action, success / failure) -Remote logging and auditing 3. Questions Vendor and Security Services information 3.1 Company Name? 3.2 Point of Contact? 3.3 Web Site URL? 3.4 Product Name(s)? 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 With which specifications listed above in the introduction do the products comply? With which version of each do your products comply? 3.8 Describe the scalability of each product. Responses to these questions will address some Government policy compliance 3.9 Have the products been National Information Assurance Partnership (NIAP) validated? If they have, to what level? 3.10 If the products include a crypto module, are they FIPS 140-2 complaint? 3.11 Are the products 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 the products including integration engineering discussed in your response to this RFI? 3.13 What is your company?s corporate support policy? 3.14 Has a US Government organization used or sponsored the products? If yes, provide POC. 3.15 What are scheduled capability enhancements for the products in 2004 and 2005? 3.16 How are the products licensed (e.g., by seat, by platform)? 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 may consider meeting individually with 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
- SN00687634-W 20041003/041001211540 (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 |