SOLICITATION NOTICE
A -- Cross-Domain Innovation & Science
- Notice Date
- 5/12/2008
- Notice Type
- Presolicitation
- NAICS
- 541712
— Research and Development in the Physical, Engineering, and Life Sciences (except Biotechnology)
- Contracting Office
- Department of the Air Force, Air Force Materiel Command, AFRL - Rome Research Site, AFRL/Information Directorate, 26 Electronic Parkway, Rome, New York, 13441-4514
- ZIP Code
- 13441-4514
- Solicitation Number
- BAA-08-06-RIKA
- Point of Contact
- Lori L. Smith,, Phone: (315) 330-1955
- E-Mail Address
-
Lori.Smith@rl.af.mil
- Small Business Set-Aside
- N/A
- Description
- NAICS CODE: 541712 FEDERAL AGENCY NAME: Department of the Air Force, Air Force Materiel Command, Air Force Research Laboratory (AFRL) - Rome Research Site (RRS), AFRL/Information Directorate (RI), 26 Electronic Parkway, Rome, NY, 13441-4514 TITLE: Cross-Domain Innovation & Science ANNOUNCEMENT TYPE: Initial announcement FUNDING OPPORTUNITY NUMBER: BAA 08-06-RIKA CFDA Number: 12.800 DATES: It is recommended that white papers be received by the following dates to maximize the possibility of award: FY 09 should be submitted by 15 June 2008; FY 10 by 1 March 2009; FY 11 by 1 March 2010; FY 12 by 1 March 2011 and; FY 13 by 1 March 2012. White papers will be accepted until 2:00 p.m. Eastern time on 1 March 2013, but it is less likely that funding will be available in each respective fiscal year after the dates cited. FORMAL PROPOSALS ARE NOT BEING REQUESTED AT THIS TIME. See Section IV of this announcement for further details. I. FUNDINGOPPORTUNITY DESCRIPTION: The Cross Domain Innovation & Science (CDIS) group of the Air Force Research Laboratory’s Information Directorate is interested in secure, accreditable services to assist in sharing information between two or more independent security domains. Key Terms: Secure: The solutions must be highly resistant to inappropriate use, either deliberate or accidental. Accreditable: The solutions must be able to pass appropriate accreditation procedures, such as DOD Information Assurance Certification and Accreditation Process (DIACAP), Director of Central Intelligence Directive (DCID) 6/3, and/or the emerging National Institute of Standards & Technology (NIST) 8500 standards in its final form. (Systems will not need to be immediately accredited, but must make all reasonable efforts to retain the ability to be accredited via best practices and good security design, such as Defense Information Systems Agency’s (DISA’s) Security Technical Implementation Guide (STIG) series) Need to Know: Not every user will necessarily be allowed access to every potential resource. Solutions must have appropriate measures to allow enforcement of access policies. Sharing: Information handled through these solutions must be able to be easily shared with appropriate personnel and/or systems. This typically requires adherence to published data, security, infrastructure and interoperability standards such as those available from World Wide Web Consortium (W3C) and/or Organization for the Advancement of Structured Information Standards (OASIS) among others. In general, solutions should be capable of interacting appropriately via Service Oriented Architecture (SOA)/web service means. Independent Security Domains: By default, each level of classification is required to run on physically separated infrastructures. Cross-domain solutions are the bridges between these infrastructures, and hence require an exceedingly detailed security analysis and risk identification. Specific Focus Areas for FY 2009: Security Labeling Assurance & Pedigree: Defining the standards, interrelationships, processing and security requirements for assuring appropriate labeling of information with metadata. The goal is to allow the Operating System (OS), applications, storage, and transport mechanisms to enforce appropriate access policies to information. HAP & MILS Architecture Adaptation to W/S & Mobile Platforms: Researching the High Assurance Platform (HAP) and other multi-level operating systems architectures such as Multiple Independent Levels of Security (MILS) and Multi-Level Security (MLS). Investigate their performance with multi-level environments (such as Multi-Level Repositories (MLR), among others) in the interest of determining how they adapt to workstations, mobile platforms and other platforms. Addressing issues such as cost and benefit comparison, scalability, bandwidth requirements, the ability to integrate policy models, and system performance. Cognitively-Assisted Cross-Domain Information Sharing: Applying cognitively assisted information technologies to assist in automated and reliable human review of data, automated labeling of data, and/or assisting human labeling efforts. Using knowledge based technologies, natural language processing, case-based learning and the like, providing assistance in classification labeling of documents and parts of documents. The goal of this technology is to assist users developing documents, users reviewing documents and data being automatically produced by mission applications in labeling textual data based on current information sharing policies. Another goal of this effort is developing machine reasoning to attach appropriate metadata labeling to support the transmission of data to other security domains. This technology should easily integrate into SOA for ease of use and accessibility for enterprise and cross domain information sharing. Secure cross domain discovery of web services: Securing Universal Description, Discovery and Integration (UDDI) or functionally similar capabilities for cross domain application, including implementation of need-to-know verification checks and related capabilities. General Focus Areas Applicable to all FYs: MILS/MLS technologies: MILS & MLS technologies are operating systems or equivalents which allow for trustworthy handling of data at different classifications. These are often core functionalities utilized in cross domain solutions. Examples of MILS systems include Green Hills “Integrity” Real-Time Operating System (RTOS) (as part of the current HAP effort) or Wind River’s offerings. Examples of MLS operating systems include Trusted Solaris 8, Solaris 10 with Trusted Extensions, or Security Enhanced Linux (SE-Linux). Object level auditing: Modern auditing is typically performed on specific events, such as accessing a new process, potential modification point, etc. This tends to lead to massive amounts of audit data, some with little or no security relevance. An alternate approach is to have data objects be capable of recognizing appropriately auditable events – creation, deletion, copying, etc – and report their occurrence to some centralized service(s). Such an effort would face an extreme amount of validation requirements to be accreditable. Policy-based configuration: Most systems typically are independently configured, leading to difficulty in reconfiguring a network of systems to handle an overarching change. Additionally, most are directly configured, rather than being dynamically reactive to policy changes. Having systems being both centrally configured and reactive to policy changes could greatly reduce the administrative overhead of such systems. Workflow Enforcement: Most systems are good at maintaining a workflow within their capabilities. However, few systems are easily adaptable to enforce new workflows across multiple systems, maintaining non-repudiation and auditability across each step. This general focus area seeks to rectify this gap. Redaction: The ability to modify an information flow (either in limited formats, or optimally, in any format) to remove information inappropriate to its destination. The ultimate goal would be a system capable of automatically preventing inadvertent or malicious release of inappropriate information while not restricting the appropriate sharing of information. Further challenges include determining the point at which redaction removes the value of transmitting any resulting information, potentially reducing bandwidth/processing requirements for cross domain solutions. Label/Metadata Validation: Being able to assure that the content (‘data’) matches the labels and metadata associated with it. This is a dual task – not only assuring by (preferably automated) inspection that there is an appropriate linkage between specific data and metadata, but allowing for highly-trusted validation mechanisms to reduce the computational overhead, while still fulfilling the certification and accreditation requirements. Improved/Reliable Human Review: Increasing the speed and efficiency of the human review process required on transfer of most information from a higher classification domain to a lower classification domain. Methods are expected to be highly variable, from machine comprehension to statistical techniques to hidden content mining and including many others. Enterprise Common Operational Picture (COP) – An awareness of challenges, risks and problems to an enterprise is critical to being able to respond appropriately to reach resolution. As such, we are looking into how to generate a COP of the entire enterprise, regardless of classification. Note that there are some non-trivial operational and need-to-know issues involved. Policy management: Being able to represent policies for access to system resources electronically, allowing for a simple policy change to affect the configuration of systems and networks. See also Policy-based configuration, above. Service management: Given the growing interest in and support of SOA in the various domains, improving the management of such resources becomes increasingly urgent. Adding in the desire of many customers to form ‘mashable’ (read, rapidly adaptable by users) interfaces to critical data sources via SOA, this management requirement becomes even more critical. Additional concerns come into play when these single-domain SOA-based enterprises begin incorporating cross domain solutions. Interoperable systems: Wherever possible, solutions provided to this BAA should follow open standards. Examples of these include the standards offered by the W3C, OASIS, Department of Defense (DoD), Intelligence Community (IC) and others. Label Integrity & Classification: Being able to appropriately label information is an early precursor to flattening the networks. As such, the integrity of the labels – especially classification labels – is critical in the long run. Various methods are being researched for this, from authoritative information servers to various cryptographic binding methods, and including other approaches. Data Aggregation & Attestation: A classic concern with automated data handling is the data aggregation issue, also referred to as the ‘sources and methods’ problem. That is, a document made up of multiple pieces of information may end up with a final classification higher than any of its constituent parts. Finding methods to assure this does not happen within automated, adaptable services is a major challenge, and finding methods to attest that it has not occurred increase the level of difficulty. Data pedigree: Knowing information is important, but knowing where that information is derived from is at least as important in evaluating it. As such, there are many different ways to maintain the history (or ‘pedigree’) of information. Issues arise when one attempts to send this pedigree cross domain – either due to resources being unavailable (cryptographic key stores, for instance) or due to policies preventing such transfers. Trustworthy labeling tools & services: Given the importance of appropriate labeling of data in a flattened networking environment, the tools to add labeling to data become very important targets of malicious users. Finding ways to assure that the labeling is correct and not maliciously applied or reapplied become critical. Identity management. Maintaining track of who has access to what resources is a non-trivial, but mostly understood challenge within a single domain. When this capability is extended into a cross domain environment, many critical issues immediately arise and make what seems reasonably solvable in a single domain quite thorny. Examples include need-to-know issues, such as: Do low-side users need to know about high-side users? When and why and how do you allow only appropriate information flows? Storage of sensitive data with multiple owners: Given the focus of centralization of capabilities currently ongoing within the various communities (Defense Enterprise Computing Centers (DECC)s, Regional Service Centers (RSCs), etc), the issue of sensitive information owned by multiple disparate organizations being collocated on a single device becomes a potential showstopper. Finding ways to protect the need to know of the information at a level acceptable to all the various data owners in question becomes a very difficult problem, especially when you add in the modern need-to-share requirements. Secure non-hierarchical data sharing. The Bell-LaPadula concepts (‘Write up, read down’) work extremely well for hierarchical data classification schemes. However, we have many non-hierarchical data classification schemes in use across the various domains – releasability, caveats and code words are all examples of non-hierarchical classification schemes. What are the equivalents of Bell-LaPadula’s concepts in such information spaces? Appropriate discovery and subscription to data flows in other domains. A common theme across academic approaches to web services and SOA is discovery – sharing information about how to get information. This is a great advantage to the transfer of information, but is completely insecure. To allow for discovery of services in trusted networks, there must be some level of need-to-know enforcement built into the standard academic discovery approaches. Disadvantaged (‘tactical’) user support. The Tactical user is unable to handle the information load expected within the enterprise, as they are typically limited to the computer hardware they can carry or have mounted to a vehicle. Yet these users are still in need of many of the enterprises’ data feeds, and are the ultimate reason for those enterprises’ existence. How do we link these users back into the enterprises, given the challenges on weight, power, bandwidth, and effective time? (Would you rather have a soldier performing administrative tasks, or fighting?) NOTE: White papers are not being solicited for FY 2010/2011 at this time. The research descriptions that follow are for informational purposes only. Additional information for these FYs and beyond will be provided under modifications to this BAA. 2010: Information Security Metadata Formulation: Researching & implementing a method to link data and metadata within and across domains in a trustworthy manner. This includes gathering security policies for relevant domains into a standardized, appropriately accessible framework, potentially allowing for single-point configuration of multiple security domains. Dynamic, Adaptive Security Policy Expression, Machine Reasoning & Learning: Developing a standardized multi-domain security policy system to automate the transfer of appropriate data and metadata as required. This centralized policy system should be easily and dynamically adaptable to new environments in a secure and trustworthy manner. 2011: Trusted Information Sharing Across Domains: Developing an accreditable, automatable, multi-domain security policy, including provisions for adaptation to changes in policy, data, and requirements. The goal of this effort is demonstrating information sharing across multiple security domains with changing configurations. II. AWARD INFORMATION: Total funding for this BAA is approximately $20M. The anticipated funding to be obligated under this BAA is broken out by fiscal year as follows: FY 09 - $4M; FY 10 - $4M; FY 11 - $4M; FY 12 - $4M; and FY13 - $4M. Individual awards will not normally exceed 36 months with dollar amounts normally ranging between $50K to $500K per year. There is also the potential to make awards up to any dollar value. Awards of efforts as a result of this announcement will be in the form of contracts, grants, or cooperative agreements depending upon the nature of the work proposed. III. ELIGIBILITY INFORMATION: 1. ELIGIBLE APPLICANTS: All potential applicants are eligible. Foreign or foreign-owned offerors are advised that their participation is subject to foreign disclosure review procedures. Foreign or foreign-owned offerors should immediately contact the contracting office focal point, Lori L. Smith, Contracting Officer, telephone (315) 330-1955 or e-mail Lori.Smith@rl.af.mil for information if they contemplate responding. The e-mail must reference the title and BAA 08-06-RIKA. 2. COST SHARING OR MATCHING: Cost sharing is not a requirement. IV. APPLICATION AND SUBMISSION INFORMATION: 1. APPLICATION PACKAGE: THIS ANNOUNCEMENT CONSTITUTES THE ONLY SOLICITATION. WE ARE SOLICITING WHITE PAPERS ONLY. DO NOT SUBMIT A FORMAL PROPOSAL AT THIS TIME. Those white papers found to be consistent with the intent of this BAA may be invited to submit a technical and cost proposal, see Section VI of this announcement for further details. For additional information, a copy of the AFRL/Rome Research Sites "Broad Agency Announcement (BAA): A Guide for Industry," April 2007, may be accessed at: http://www.fbo.gov/spg/USAF/AFMC/AFRLRRS/Reference%2DNumber%2DBAAGUIDE/listing.html 2. CONTENT AND FORM OF SUBMISSION: Offerors are required to submit 3 copies of a 3 to 5 page white paper summarizing their proposed approach/solution. The purpose of the white paper is to preclude unwarranted effort on the part of an offeror whose proposed work is not of interest to the Government. The white paper will be formatted as follows: Section A: Title, Period of Performance, Estimated Cost, Name/Address of Company, Technical and Contracting Points of Contact (phone, fax and email)(this section is NOT included in the page count); Section B: Task Objective; and Section C: Technical Summary and Proposed Deliverables. Multiple white papers within the purview of this announcement may be submitted by each offeror. If the offeror wishes to restrict its white papers/proposals, they must be marked with the restrictive language stated in FAR 15.609(a) and (b). All white papers/proposals shall be double spaced with a font no smaller than 12 pitch. In addition, respondents are requested to provide their Commercial and Government Entity (CAGE) number, their Dun & Bradstreet (D&B) Data Universal Numbering System (DUNS) number, a fax number, an e-mail address, and reference BAA 08-06-RIKA with their submission. All responses to this announcement must be addressed to the technical POC, as discussed in paragraph five of this section. 3. SUBMISSION DATES AND TIMES: It is recommended that white papers be received by the following dates to maximize the possibility of award: FY 09 should be submitted by 15 June 2008; FY 10 by 1 March 2009; FY 11 by 1 March 2010; FY 12 by 1 March 2011 and; FY 13 by 1 March 2012. White papers will be accepted until 2:00 p.m. Eastern time on 1 March 2013, but it is less likely that funding will be available in each respective fiscal year after the dates cited. 4. FUNDING RESTRICTIONS: The cost of preparing white papers/proposals in response to this announcement is not considered an allowable direct charge to any resulting contract or any other contract, but may be an allowable expense to the normal bid and proposal indirect cost specified in FAR 31.205-18. Incurring pre-award costs for ASSISTANCE INSTRUMENTS ONLY, are regulated by the DoD Grant and Agreements Regulations (DODGARS). 5. OTHER SUBMISSION REQUIREMENTS: DO NOT send white papers to the Contracting Officer. All responses to this announcement must be addressed to ATTN: Michael J. Mayhew AFRL/RIEB 525 Brooks Road Rome, NY 13441-4505 Electronic submission to Michael.Mayhew@rl.af.mil will also be accepted. V. APPLICATION REVIEW INFORMATION: 1. CRITERIA: The following criteria, which are listed in descending order of importance, will be used to determine whether white papers and proposals submitted are consistent with the intent of this BAA and of interest to the Government: (1) Overall Scientific and Technical Merit -- Including the approach for the development and/or enhancement of the proposed technology and its evaluation, (2) Related Experience - The extent to which the offeror demonstrates relevant technology and domain knowledge, (3) Openness/Maturity of Solution - The extent to which existing capabilities and standards are leveraged and the relative maturity of the proposed technology in terms of reliability and robustness, and (4) Reasonableness and realism of proposed costs and fees (if any). No further evaluation criteria will be used in selecting white papers/proposals. Individual white paper/proposal evaluations will be evaluated against the evaluation criteria without regard to other white papers and proposals submitted under this BAA. White papers and proposals submitted will be evaluated as they are received. 2. REVIEW AND SELECTION PROCESS: Only Government employees will evaluate the white papers/proposals for selection. The Air Force Research Laboratory's Information Directorate has contracted for various business and staff support services, some of which require contractors to obtain administrative access to proprietary information submitted by other contractors. Administrative access is defined as "handling or having physical control over information for the sole purpose of accomplishing the administrative functions specified in the administrative support contract, which do not require the review, reading, or comprehension of the content of the information on the part of non-technical professionals assigned to accomplish the specified administrative tasks." These contractors have signed general non-disclosure agreements and organizational conflict of interest statements. The required administrative access will be granted to non-technical professionals. Examples of the administrative tasks performed include: a. Assembling and organizing information for R&D case files; b. Accessing library files for use by government personnel; and c. Handling and administration of proposals, contracts, contract funding and queries. Any objection to administrative access must be in writing to the Contracting Officer and shall include a detailed statement of the basis for the objection. VI. AWARD ADMINISTRATION INFORMATION: 1. AWARD NOTICES: Those white papers found to be consistent with the intent of this BAA may be invited to submit a technical and cost proposal. Notification by email or letter will be sent by the technical POC. Such invitation does not assure that the submitting organization will be awarded a contract. Those white papers not selected to submit a proposal will be notified in the same manner. Prospective offerors are advised that only Contracting Officers are legally authorized to commit the Government. All offerors submitting white papers will be contacted by the technical POC, referenced in Section VII of this announcement. Offerors can email the technical POC for status of their white paper/proposal no earlier than 45 days after proposal submission. 2. ADMINISTRATIVE AND NATIONAL POLICY REQUIREMENTS: The capability to work in a classified facility with classified data may be required. White Papers / Proposals should identify any cleared personnel and access to classified facilities for completing tasks outlined above. Depending on the work to be performed, the offeror may require a Top Secret facility clearance and safeguarding capability; therefore, personnel identified for assignment to a classified effort must be cleared for access to Top Secret information at the time of award. In addition, the offeror may be required to have, or have access to, a certified and Government-approved facility to support work under this BAA. Data subject to export control constraints may be involved and only firms holding certification under the US/Canada Joint Certification Program (JCP) (www.dlis.dla.mil/jcp) are allowed access to such data. 3. REPORTING: Once a proposal has been selected for award, offerors will be required to submit their reporting requirement through one of our web-based, reporting systems known as JIFFY or TFIMS. Prior to award, the offeror will be notified which reporting system they are to use, and will be given complete instructions regarding its use. VII. AGENCY CONTACTS: Questions of a technical nature shall be directed to the cognizant technical point of contact, as specified below: Michael J. Mayhew (315) 330-2898 Michael.Mayhew@rl.af.mil Questions of a contractual/business nature shall be directed to the cognizant contracting officer, as specified below: Lori Smith Telephone (315) 330-1955 Email: Lori.Smith@rl.af.mil The email must reference the solicitation (BAA) number and title of the acquisition. In accordance with AFFARS 5301.91, an Ombudsman has been appointed to hear and facilitate the resolution of concerns from offerors, potential offerors, and others for this acquisition announcement. Before consulting with an ombudsman, interested parties must first address their concerns, issues, disagreements, and/or recommendations to the contracting officer for resolution. AFFARS Clause 5352.201-9101 Ombudsman (Aug 2005) will be incorporated into all contracts awarded under this BAA. The AFRL Ombudsman is as follows: Susan Hunter Building 15, Room 225 1864 Fourth Street Wright-Patterson AFB OH 45433-7130 FAX: (937) 225-5036; Comm: (937) 255-7754 All responsible organizations may submit a white paper which shall be considered.
- Web Link
-
FedBizOpps Complete View
(https://www.fbo.gov/?s=opportunity&mode=form&id=c74dab946454fd14554a2fee95b78bf6&tab=core&_cview=1)
- Record
- SN01571355-W 20080514/080512220249-c74dab946454fd14554a2fee95b78bf6 (fbodaily.com)
- Source
-
FedBizOpps Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |