Loren Data's SAM Daily™

FBO DAILY ISSUE OF JULY 25, 2010 FBO #3165
SOLICITATION NOTICE

A -- CROSS DOMAIN INNOVATIVE TECHNOLOGIES

Notice Date

7/23/2010
 

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-10-09-RIKA
 

Point of Contact

Lynn G. White, Phone: (315) 330-4996
 

E-Mail Address

Lynn.White@rl.af.mil
(Lynn.White@rl.af.mil)
 

Small Business Set-Aside

N/A
 

Description

CFDA Number: 12.800 I. FUNDING OPPORTUNITY DESCRIPTION: The Cross Domain Innovation & Science (CDIS) group of the Air Force Research Laboratory's Information Directorate is interested in new innovative technologies and capabilities that promote the state of the art for secure, accreditable capabilities to enhance the sharing of information between multiple independent security domains. General Focus Areas Applicable to all FYs: - Multiple Independent Levels of Security/Multiple Level Security 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), Linux Works LynxOS, or Wind River's offerings. Examples of MLS operating systems include Trusted 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 and management: Most modern systems are typically configured independently, leading to difficulty in reconfiguring a network of multiple 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. On the management side, the Government must be able to represent policies for access to system resources electronically, allowing for a simple policy change to affect the configuration of systems and networks in a highly assured manner. - 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. Solutions that allow for adaptable workflows will greatly improve system flexibility and reactivity to changes when needed. - 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, which if successful would reduce the bandwidth & processing requirements for cross domain solutions. - Data Trust: Being able to assure that the content (‘data') matches the labels and metadata associated with it. This is a dual task. The system must assure an appropriate linkage between specific data and metadata by automated inspection wherever possible and human inspection where automation is infeasible. It must also allow for highly-trusted validation mechanisms to reduce the computational overhead, while still fulfilling the certification and accreditation requirements. - Improved/Reliable Human Review (RHR): 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 full machine comprehension to statistical techniques that aid the reviewer. Example tools needed to improve the RHR process include: identifying, revealing and/or cleansing of hidden content; data security labeling verification; data owner/data steward identity verification; pedigree representation; cognitive text analysis and 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 react to enterprise events including load balancing, fail over and matching of appropriate device based on information to be shared. As such, a Common Operational Picture (COP) or dashboard environment is required to measure environmental factors of all machines within the enterprise so that an appropriate reaction can be made to quickly adapt to the changes needed. Note that there are non-trivial operational and need-to-know issues involved. - Service management: Given the growing interest in and support of Service Oriented Architecture (SOA) in the various domains, improving the management of such resources becomes increasingly urgent. Adding in the desire of many customers to form ‘mashable' (data 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. Thus, determining the risks to one or more cross-domain solutions as provided by such ‘mashable' interfaces' capabilities becomes an urgent concern. This can also be known as ‘service orchestration'. - Label Integrity & Classification: Being able to appropriately and securely label information is an early precursor to flattening the networks. As such, the integrity of the labels - especially classification & releasability labels at a bare minimum - 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. Further, finding automated or automatable methods to validate and attest that it has not occurred increase the level of difficulty. - 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 becomes 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? How and when do accounts getting locked in one domain affect account(s) in other domains? - Storage of sensitive data with multiple owners: Given the focus of centralization of capabilities currently ongoing within the various communities (Defense Enterprise Computing Centers (DECCs), 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 separation schemes, such as with classification. However, there are many non-hierarchical separation schemes in use across the various domains - releasability, caveats and code words can all be examples of non-hierarchical classification schemes. What are the equivalents of Bell-LaPadula's concepts in such non-hierarchical 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 the common, open standards typically used are 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 on the front lines performing administrative tasks, or fighting?) - Cross domain enterprise management: This area investigates quality of service (QOS) in different security domain being handled at the transfer device improving enterprise information sharing. This area identifies ways to achieve greater mission assurance by enabling Cross Domain content review mechanisms to be efficiently adapted to changes in information assurance and mission policies. To achieve this, a Cross-Domain content review architecture supporting expandable set of service-based data filters and a data flow orchestration mechanism responsive to policy changes must be defined, leveraged and/or developed. - Secure Information Sharing - In order to prevent malicious insider and outsider threats to the many different security domains, within a Cross Domain System (CDS), Technology that improves/enhances cyber capabilities via assured isolation & mitigation of high concern threats, covert channels, and other defensive cyber capabilities within cross domain environments must be developed. In doing so, balance among the three legs of the CIA Triad; Confidentiality, Integrity, and Availability must be maintained. - Next Generation Data Services: As SOAs move towards secure Cloud Computing within a Global Information Grid environment, the research, analysis, and assembly of appropriate secured services is required to ensure that data within this environment is trustworthy, reliable, readily available to the appropriate parties, protected from unauthorized parties, timely, and accurate. This area seeks to identify, select, implement and test various services against the metrics identified above and develop a prototype solution that fuses these capabilities into an accreditable prototype solution. - Advance Trusted Computing Technologies: Advance the state of the art in trusted computing technologies though active research of commercial companies and technologies to determine what trusted computing technologies are on the market today. Once identified, this area will assist in defining a Technology Roadmap and Trusted Computing Strategy based on those findings and investigate the identified trusted computing architectures, looking at ways to modify and improve architectures for operational use. After analysis is complete, the development and population of a test-bed of trusted computing technologies for testing security, functionality, and performance of modified systems can be created and a strategic marketing and outreach execution which impacts commercial development of Trusted Computing products and services of selected candidates provided that is based on the test results. Focus Areas for FY11: Reputation Based Access Control: - Given a large corpus of pedigree metadata currently being investigated as a means of improving data sharing, it should be possible and practical to determine (via data mining & graph analysis techniques) acknowledged authoritative sources for data. This would allow systems to determine 'considered good' sources as a ground-truth indication for future data release. In addition, a formal model of behavior should be used, based on event structures for specifying properties of past behavior; and providing efficient dynamic algorithms for checking whether a particular behavior satisfies a particular property. This would increase users' confidence in information integrity and appropriateness through the measurement of quality of information (QOI). Automated Security Annotation & Safeguarding: - Expanding the ability of cognitive-based assistants to improve cross domain information sharing to fulfill the "human-in-the-loop gap" is a significant challenge that needs to be resolved for well understood data types. This would include working with accreditors to build a body of evidence regarding the trustworthiness of cognitive automated annotation and safeguarding procedures. The end goal is to create accreditable systems with known and accepted probabilities of success for the labeling and sharing of information between different security domains. Focus Areas for FY12: Cognitive support for discourse level analysis: - Using innovative techniques to enhance the sharing of documents between multiple security domains, there is an additional need to expand the capability beyond single documents and create machine comprehension of multiple documents. This is useful in ‘chatroom' and many other multiple-person interaction collaboration formats. As a bonus these techniques may be able to detect phishing/social engineering efforts. Automation of RHR: - RHR remains a continual bottleneck for the efficient sharing of information between multiple security domains. In order to improve sharing, the need exists to automate, as much as feasible, tools to cognitively analyze the documents and messages being transferred in order to make an effective decision. This capability must prove to be highly reliable and accurate with a proven ability to substantially reduce the number of false positive and false negative responses. The solution must take into account the Information Assurances aspects of the capability so that the tools can be extended into an accreditable automated RHR capability. Focus Areas for FY13: Brokering authoritative trust within multiple security domains: - Investigate and develop innovative mechanisms for the development of multi-domain authentication and authorization services. Currently, there are many single domain mechanisms for single domains that cannot be used for multi-domain brokering due to information assurance issues with trust. There is a need to determine how best to leverage those single-domain solutions to allow for trust between different security domains. This trust obviously cannot be cryptographically secured, and due to concerns of operational security should obscure to a large degree the domain that the information that the trust is being based upon is being drawn from. 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, National Institute of Standards & Technology (NIST)'s Special Publication 800-53v3, and other appropriate guidance.) 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 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. II. AWARD INFORMATION: Total funding for this BAA is approximately $24 M. The anticipated funding to be obligated under this BAA is broken out by fiscal year as follows: FY 11 - $8M; FY 12 - $8M; FY 13 - $8M. Individual awards will not normally exceed 36 months with dollar amounts normally ranging between $250K to $1M 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, Lynn G. White, Contracting Officer, telephone (315) 330-4996 or e-mail Lynn.White@rl.af.mil for information if they contemplate responding. The e-mail must reference the title and BAA 10-09-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 10-09-RIKA with their submission. All responses to this announcement must be addressed to the technical POC, as discussed in paragraph six 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 11 should be submitted by 13 Aug 2010; FY 12 by 1 Mar 11 and FY 13 by 1 Mar 12. White papers will be accepted until 2pm Eastern time on 30 September 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. 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. All Proposers should review the NATIONAL INDUSTRIAL SECURITY PROGRAM OPERATING MANUAL, (NISPOM), dated February 28, 2006 as it provides baseline standards for the protection of classified information and prescribes the requirements concerning Contractor Developed Information under paragraph 4-105. Defense Security Service (DSS) Site for the NISPOM is: https://www.dss.mil/portal/ShowBinary/BEA%20Repository/new_dss_internet//isp/fac_clear/download_nispom.html. 6. 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/RIEBB CDIS BAA: BAA-10-09-RIKA 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 degree of innovation for the approach and the use of innovative modern architectures in development and/or enhancement of the proposed technology; the use of analysis, metrics & testing and adherence to Information Assurance and Cross-Domain Certification & Accreditation requirements, (2) Related Experience - The extent to which the offeror demonstrates relevant technology and domain knowledge, (3) Openness, Maturity & Assurance of Solution - The extent to which existing capabilities and standards are leveraged and the relative maturity of the proposed technology in terms of Confidentiality, Integrity, Availability, 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: The Government may use the services of MITRE in an advisory role for the technical evaluation of proposals. The exclusive responsibility for evaluation and selection/non-selection of proposals remains with the Government. Representatives of the foregoing firm participating in the evaluation process will be precluded from submitting a white paper/proposal under this BAA, and will sign a non-disclosure agreement in order to highlight the sensitivity of the evaluation process and to protect any proprietary information within the proposals. Any objection to the use of any or all of the personnel identified above must be in writing to the Contracting Officer and shall include a detailed statement of the basis for the objection. 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 submission. 2. ADMINISTRATIVE AND NATIONAL POLICY REQUIREMENTS: Depending on the work to be performed, the offeror may require a secret or top secret facility clearance and safeguarding capability; therefore, personnel identified for assignment to a classified effort must be cleared for access to secret or 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 Telephone: (315) 330-2898 Email: michael.mayhew@rl.af.mil Questions of a contractual/business nature shall be directed to the cognizant contracting officer, as specified below: Lynn White Telephone (315) 330-4996 Email: Lynn.White@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 (Apr 2010) 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) 904-4407 All responsible organizations may submit a white paper which shall be considered.
 

Web Link

FBO.gov Permalink
(https://www.fbo.gov/spg/USAF/AFMC/AFRLRRS/BAA-10-09-RIKA/listing.html)
 

Record

SN02216079-W 20100725/100723235254-93b2066227c1148210cd468b9d392e18 (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 |