The installation must be secure in the sense that persons, other than FEA personnel or their authorized representatives, would be unable to access, read, copy or destroy material, data, or specialized software handled or contained in the proposed system. (RFP section II-B-3-i.)

In addition to these "external" security requirements, the RFP specified certain "internal" (to the ADP system) security control requirements, i.e., protection of data on the system from users, who are authorized to use the system but who are not authorized to have access to some of the data on the system. In this regard, FEA clearly indicated in the RFP and has subsequently stated that all authorized users of the dedicated FEA ADP system are not authorized access to all data being processed on the system. This concept of differentiated levels of access to the data on the system among authorized users of the system is clearly recognized in the RFP requirements that there be three classes of file restrictions (public, selected private and private) (RFP section II-B-3.i.1); that there be two levels of file restrictions (read only, unrestricted) (RFP section II-B-3.i.2); and that file protection through password and account name/number be provided (RFP section II-D-10).

The RFP also states in pertinent part:

g. Protection. The system shall provide for protection of user programs, the operating system, and the areas in which their code resides, from read or write access by other users. This includes protection from writing and reading by unauthorized programs and any other interference caused by software or hardware-for example, hardware or software priority conflicts, errors, and any other capabilities that the contractor feels are necessary for the efficient and effective protection of the system. Instructions such as I/O, interrupt control, sensing, halts, setting protection boundaries and unused machine codes shall not be directly executable by the application users. [RFP section II-A-4.g.]

Main memory and/or storage protection shall be assured in areas where authorization and validation operations are being conducted ***. [Italic supplied.] (RFP section II-B-3.1.4.)

Section II-A-4.g makes it clear that these last quoted requirements are "internal" security requirements by specifying that the requirements are for protection from access "by other users" to the user programs, the operating system and the areas where users' codes reside, all of which at times reside in the computer main memory. The context of these requirements clearly indicates that the term "users" refers to persons authorized to use the computer system, and, therefore, relates to "internal" security.

In response to the RFP security requirements, OSI proposed in pertinent part:

OSI has recognized the need to prevent users from accessing other users' data or sensitive system data. As a result of this need, OSI has developed a means to limit each user's sphere of data accessibility to his/her own data sets [files] via account-number assignments. At OSI, users are assigned a four-character account number, a three-character initial set, a terminal identification code, and a three-character keyword.

*

Additionally, OS and the IBM 370/168 incorporate, via system architecture and system software, protection for user programs and system software residing in memory. User program execution is always under the control of system software and hardware, and the execution of any privileged operations (e.g., physical I/O, halts, and setting protect keys) are denied to user programs.

As a result of past experience, OSI proposes the implementation of password protection for highly sensitive information, plus file protection via account numbers to discourage misuse of another user's data and to ensure maximum security.

The protection of one multi-programmed task from the inadvertent storage of data into another task's region of [main] memory is provided through a series of "storage protect keys" and is a function of the IBM 370/168 hardware and OS software. Each task, including the operating system (OS, HASP, and TSO), is assigned a distinct storage protection key for each 2,048 bytes it occupies. The hardware intercepts any task which attempts to store data into another task's region and passes this information on to the operating system. At this point, the operating system abnormally terminates the task with a completion code which indicates to the user that his/her program attempted to store data outside its own boundaries. Depending on the JCL used to run the program, a dump of the user's region and the address of the instruction which attempted the illegal store operation will be provided to assist the user to resolve the problem * * *. [Italic supplied.]

The system software and hardware configuration proposed by OSI under the RFP was the IBM's OS/MVT operating system used on the IBM 370/168 CPU.

The hardware/operating system configuration proposed by OSI did not (and indeed could not) meet the mandatory RFP security requirements set out above, in that the OS/MVT operating system on the IBM 370/168 CPU cannot protect against read access to the main memory of the CPU. (OS/MVT clearly can protect against a user's write access, i.e., storing, altering, or erasing data in other users' regions in the main memory, including the operating system.) The RFP makes it clear that this requirement is material. The requirement for protection from read access is contained in the first sentence of the protection requirements for the ADP system.

This protection against read access is critical because the user programs (when being executed), the operating system (always), and the areas in which user's codes (when being validated) reside are in the main memory. Without this protection, a user of the ADP system can read any data anywhere in the main memory, including the operating system. (Even though he could not read the data directly from the files without a valid password.) A user also can read data from any other user's "region" in the main memory containing a program in execution. In addition, a thoughtful user would be able to identify other users' passwords and identifiers, since these identifiers have to be read into the main memory in order to test the validity of a user's log-on attempt. This would mean that a user utilizing another user's passwords can masquerade as the other user and obtain access to the other user's files (which are protected by the passwords).

232-098 - 77-9

FEA has asserted that the system's provisions for "password" protection against reading or writing in files, storage protection of the programs and data in the main memory, and the fact that privileged instructions are not available to all users sufficiently comply with the RFP requirements. We disagree. The clear language of these requirements indicates that protection of the main memory from read access is required. FEA has not claimed that the system has such ability. Read protection of the files (which are not in the main memory) does not comply with this requirement. Indeed, if a user finds out other users' passwords by perusing the main memory at the proper time and the proper place, the files protected by these passwords are no longer protected.

This "weakness" in the OS/MVT/IBM 370/168 CPU configuration is well recognized in the computer industry. Indeed, in the PRC Alternative B proposal, PRC, who also offered the OS/MVT operating system, specifically stated:

OS/MVT satisfies all of the FEA requirements except read protection * * *. [Italic supplied.]

PRC went on to state that reading across user boundaries would be difficult, however, and require a detailed knowledge of the IBM system, since PRC states that a program seldom resides in the same location twice.

We have ascertained that while a program may not reside in the same place twice, it presents no real barrier to the individual who wishes to find other users' passwords and other identifying information. The individual can do this by writing a program to search the entire main memory for any and all instances of distinguishable data patterns that have the form of the passwords or other identifiers being sought (which are readily distinguishable from computer instructions, numeric data and other information found in a computer's main memory). He can then have the results of his search displayed to him. Further, we have ascertained that the region of the main memory used by the operating system to validate user access codes generally does not change over extended periods of time, and once identified can be the subject of an intensive localized search program. Finally, it is noted that such unauthorized reading of the main memory will not be detected by the operating system.

OSI's response to these RFP requirements, quoted above, makes no reference to the system's ability to prevent read access to the main memory, although OSI does state several times that it protects against unauthorized storage of data in another user's designated region in the main memory (i.e., write access protection).

We also note that it is not beyond the "state of the art" to comply with these requirements. For example, read protection can be pro

vided on the IBM 370/168 CPU with the IBM standard operating system, VS2, Release 2 (although the VS2, Release 2, may be less efficient than OS/MVT). Also, PRC's Alternative A proposal actually proposed (and could deliver) full read and write protection of data in the main memory on the Burroughs' B-6700 ADP system.

In view of the foregoing, we conclude that OSI failed to meet a material RFP security requirement. In view of FEA's clearly stated need for security and protection of sensitive information, we find FEA's relaxation of this mandatory requirement without informing all offerors to be neither prudent nor proper. See FPR § 1-3.805-1(d) (1964 ed.).

CONCLUSION

FEA should not have made the award to OSI without either amending the solicitation or otherwise notifying the other offerors that the read protection requirements would no longer be required. However, we believe that there are countervailing factors which mandate against disturbing the award to OSI.

PRC's Alternative B proposal admittedly contained exactly the same deficiency we found in OSI's proposal since it also offered the OS/MVT operating system. The third ranking PRC Alternative A proposal did meet the read protection requirements but it received a technical score of 88.2 (to be compared with the 96.3 and 92.1 scores received by the other two offers in the competitive range), due to other evaluated deficiencies. Also, FEA has informed our Office that it intends to change from the OS/MVT operating system to the VS2, release 2, operating system, which meets the RFP's read protection requirements, in October 1975.

The record provides no indication that FEA recognized OSI's failure to protect against read access to the main memory as a defect at any time during the negotiations. We can only speculate that FEA may have decided that it did not require the degree of "internal" security it specified in the RFP, or that this "deficiency" was trivial and OSI's proposal was so clearly superior to PRC's Alternative A proposal (which proposed the Burroughs' equipment) that it would have selected OSI in any case, or that it may not have even recognized that OSI's and PRC's Alternative B proposals did not comply with these security requirements. Also, we have no way of knowing how many points (if any) the SEB would have deducted from OSI's and PRC's (Alternative B) technical evaluation scores if the SEB had considered this deficiency, or what effect (if any) deductions made would have had on the award selection. Although we do recognize that, if FEA had enforced this requirement, OSI and PRC would have had to revise (perhaps substantially) their proposals to remedy this de

ficiency, we can only speculate as to whether any offeror would have revised its proposal upon notification that this requirement would be waived. In this regard, we note that no protestor or any other interested party raised this issue to our Office.

Even though the time to issue this decision was materially extended by FEA's delays in submitting its report on the protests, the fact remains that the contract has been in performance for over 6 months and the option has been exercised for Phase II, which will end on June 30, 1976, the same date that the authority for FEA terminates. See section 30 of Public Law 93-275, May 7, 1974, 88 Stat. 115, 15 U.S.C.761 note. Consequently, if it was recommended that this requirement be resolicited, the new contract period would cover less than a year since it would take several months to accomplish the resolicitation. This would make the cost for these ADP services much more expensive because of the shorter contract period over which contract costs could be amortized.

FEA estimates that over $12 million in excess costs (e.g., termination and resolicitation costs) would be incurred if this award were disturbed (we have not verified the accuracy of this estimate), and that FEA does not have the funding available in the 1976 fiscal year budget to cover such excess costs. FEA advises that termination of or unplanned modifications in this contract would have severe operational impacts throughout FEA, since the system would have to be redesigned, data collection procedures changed, FEA users retrained, and existing relationships with data sources, principally those in energy-related industries, revised. Finally, according to FEA, it would be impossible to fulfill its congressionally mandated responsibilities, such as the energy management and analysis programs, if this award were disturbed.

Therefore, we do not believe that it would serve the Government's best interests to recommend that the award to OSI be disturbed. See DPF Incorporated, B-180292, September 12, 1974; Bristol Electronics, Inc., 54 Comp. Gen. 521 (1974). However, it is essential that FEA strictly limit access to the ADP system to those persons whose participation is necessary. We plan to monitor the system's operation to insure compliance with this standard.

In view of the foregoing, the protests of PRC, OLS and RCC are denied. We are bringing the procurement deficiencies found in our review to the attention of the Administrator of FEA by letter of today.