[ih] Security issues are not discussed in this memo [was: A revolution...]

[Bill Ricker]

On Mon, May 11, 2026 at 3:12 AM Barbara Denny via Internet-history <
internet-history at elists.isoc.org> wrote:

>  I know there was a lot of early work on security. I wasn't involved. ...
> [TCESEC] ...


If there is interest in the history of Rainbow /  Trusted Computer
Evaluation / research, largely funded by different branches of DoD than
DARPA, I can speak to that.

While I'm mostly here as the Literary Estate of Michael A. Padlipsky, he
and I met when we were both in one of the Computer Security departments of
MITRE.

Mike was our bridge between Internet Working Group *etc.* and MilNet/DoDIIS
network-security interests; the  "community" (intelligence: DIA/NSA/CIA;
one of the I in DoDIIS was Intelligence) were very interested in secure
networking of computers with very sensitive data, thus requiring full
network and computer security treatment, if we could make it all work.

Mike's Group-Leader Morrie Gasser had been on the mid-1970s "Project
Guardian" tiger-team that attacked MULTICS (that Mike had helped develop).
[ https://multicians.org/security.html ] After the identified defects were
repaired, a carefully configured MULTICS called "DOCKMASTER" was accepted
for use as the bastion host interfacing between UNCLASSIFIED-but-FOUO
branch of MILNET and open ARPANET/Internet at Ft George Meade, operated by
the NSA Computer Security Center, by then run by the same COL Roger SCHELL
who'd been at MIT during the Tiger Team.

Another Group-Leader was micromanaging the contract-management of
installing secure LANs at SAC OMAHA; those would initially be operating in
"SYSTEM HIGH" security mode but they desperately needed some sort of safe
interoperability.
Another Group-Leader did the prototype of what became (when commercialized
by others*) the Compartmented Mode Workstation.
Our original Group-Leader's early project was building a semi-automated
"guard" system that could allow a knowledgeable, authorized, delegated
individual to review and approve release messages from a higher classified
network to a lower by inspect, with validated buffer management etc to
provide assurance that it couldn't send a message straight through
un-approved.
Our group was trying to apply the principles of verifiable trusted
computing behind the SCOMP and hoped-for other A1/A2 tier verified OS to
retrofit kernelized & cryptologic security into a DBMS, and investigating
UI enhancements needed for usability of multilevel or compartmented mode
terminals & workstations, and updating Risk Assessments.

A different department were the ghost-authors of the Orange Book and
most(?all?) of the TCESEC Rainbow books, and raters of proposed systems
against the several Criteria.

The original authors of the "Bell & LaPadula Security Model", Dave Bell and
Len LaPadula, were members of these two departments (one each). Fun guys!
They both basically disclaimed responsibility for the wrongheadedness of
the imposition of their academic model as a national requirement,
especially when paired with the (semi-obvious) Dual Model for Integrity.†
The B&LSM was intended to begin the process of learning to reason between
models and program- & system-specifications, it was not intended as the
solution.
But at that point in time, the National Computer Security Center (@ NSA)
was caught in the fallacious syllogism
 "we must do something, this is something, therefore we must do this."

One thing we discovered was that while assurance of  "preserves a model"
that a design or implementation held to some security invariants (codified
in the model) was sufficient at a single layer of software, such assurances
were not transitive to higher layers of software using the services of the
first layer. A Database fetching its meta-data from disk via the OS (if it
deigns to use the OS for that, some didn't, some still don't!) needs a
stronger more granular property than OS guarantees on the file and block
level; it essentially needs the Filesystem to fully correct, not just
secure; and the UI system likewise, mustn't have an erroneous bit of code
in UI system misprint the marking for a single record, even if the
high-water-mark for the whole screen is assured correct. The
network-security people, including Mike, either had already seen this in
their realm or heard it from us and said oh yeah, I'm not sure which. We
also came to the conclusion that the then cold-war between the Church of
the Holy Crypto and the Church of the Holy Kernel was wrong-headed; neither
was sufficient, a synergy would be required to do serious multi-level
security over several layers of software stack.
 (Which latter is an instance of the "When all you have is a hammer, all
looks like nails" trap; e.g. Enciphering a database column that contains a
BOOLEAN attribute per record, TRUE and FALSE, with a common key is nearly
useless; the two states can be distinguished, and if any specific example
or statistics identify even one value, all will be known.  Data with less
entropy than the key does not get protected at the level of the key, the
key is protected by the entropy of the data, oopsie.)

* MITRE as a congressionally chartered DoD QNGO is forbidden to compete
with private industry, can't deliver product; that would be a conflict of
interest with the primary role as creator of Specifications, adjudicator of
RFP replies, Contract Monitor on behalf of the program office, and
corporate technical memory (along with Civil Service DoD employees in
project office; but their uniformed leadership rotates frequently as a
career feature).

†[This implies a system in which a process  can only read data with
security tags dominated by the process tags and can only write to
files/devices whos tags dominate the process, which is basically incapable
of doing anything except hoarding data; decisions must emanate through
other means than digital (Red Telephones). ]

We in the two computer security departments had been periodically badgering
MITRE internal IT that they should pick up their security practices on the
(few) hosts with external dialup modems; no response. One Monday we find
they've adopted a whole bunch of new initiatives over the weekend, with no
discussion or prior budget or anything, no explanation, a mystery. It was a
while later when Cliff Stoll did his "*Cuckoo's Egg*" book tour that we
found out that the East German hackers plaguing Stoll's LANL phone bill
variances were dialing into our IT departments host-attached modems
(MBUNIX), tunneling to our Virginia office's DARPA/Internet main host
(MITRE), and from there to LANL. All was clear!

Not to forget Peter Neumann (SRI).


Very much so.
RIP PGN.
Since his death was announced (yesterday?), I've seen several younger
modern commercial computer security practitioners on socials (where such
hang out) extolling how Peter's RISKS-L taught them to think about _risks_
(not just "bug hunting") in their formative years.  Once you start to think
in terms of risk vs vulnerability, it's impossible not to.

Since the better praxis for Risk Assessment above was my little project, I
was particularly fond of Peter's RISKS-L .
I am very glad whenever I hear discussion of an NTSB report ... or
something that will become subject of one ... described in terms of the
Swiss Cheese Model.
That and the fish-bone-model are very good at demonstrating that "root
cause analysis" is misnamed and/or misguided; any failure worthy of study
had passed multiple opportunities to block it, so there always are multiple
causes. To blame only the last chance to avert as "the" cause and remediate
only that one cause is to leave too many existing problems as traps for the
next time.

[I left MITRE to do other things, but while I never signed on to be the
security nerd again, I've always been a *defacto* security thinker, sadly
sometimes the only one somewhere. At one shop, our division Information
Security Officer was a former Financial Auditor turned Security Auditor
(assuring Clipboard Compliance). To help them pass their Certificate class,
I tutored them on Cryptography at lunch; a favorite topic, twist my arm!
Most IT folks hated/feared the mandated Security Auditors from outside,
understanding the pointlessness of mere Clipboard Compliance (but still
better than no compliance! and mandated by many regulators so ... ); I
considered them allies, as they needed a dozen ranked findings for their
report, and didn't really care which; but if they listed the defect that
most concerned *me*, I was likely to finally get the budget and hours to
get it remediated; so dropping some hints where NOT to look ... .
Complaints from Architecture (me) and our ISO didn't have that power.]

// Bill in Boston
For once (mostly) NOT speaking as the Literary Estate of Michael A Padlipsky