[86] in Enterprise Print Delivery Team
A Secure Printing Statement from the Recent Past
daemon@ATHENA.MIT.EDU (David F. Lambert)
Tue Feb 22 18:52:48 2000
Message-Id: <10002222352.AA09739@MIT.EDU>
Date: Tue, 22 Feb 00 18:41:15 EST
From: "David F. Lambert" <LAMBERT@mitvma.mit.edu>
To: Enterprise Printing Delivery Project Team <printdel@MIT.EDU>
Gang,
Roger was romping around some old web pages and stumbled across the
following statement. It was produced by R-Ready which was a group
gathered to help insure that IS/IT would be prepared to handle the
expected additional workload from the various reengineering efforts.
I believe Susan was leading the group. Clearly Jeff and others
would have provided input into this statement. Since the technology
hasn't changed much and this statement was already written to address
standards/integration needs, I suspect we'd have a favorable response
from ITIT if we reminded them of this statement's existence. The
wording looks good to me. Your thoughts (especially Mike, Rocklyn
& Mary Ellen)?
-Dave
Secure Printing Position Paper
June 16, 1995
Recently, there have been a number of requests and/or assumptions
that the re-engineering infrastructure should provide "secure printing".
"Secure printing" can mean many things, but in this context, the
proposed requirement is to protect the confidentiality of a print file
as it travels over the network toward its final destination at the
printer. It is the Re-engineering Readiness Team's position that
this "secure printing" as defined above should NOT be expected to be
provided by the general I/T infrastructure at MIT.
In a world where print jobs originated from mainframes located in
a central data center and were printed on a high-volume, high-speed
printer located in the same central data center, the confidentiality of
print jobs as they travelled between the mainframe and the printer was
never an issue. However, in the new, distributed world, where printers
are located close to users and print jobs must travel across open
ethernets, this represents a new risk.
Unfortunately, given products commonly available on the market today,
it will not be possible for us to address this risk in the general case
and in a cost-efficient manner. To do this cheaply, the printers
themselves would have to receive and decrypt an encrypted stream.
Since printers currently available do not do this, we would have to
install a print server next to each printer, and then add staff members
to support the print servers which would be located all across the
Institute. Hence, the $3,000 cost of a printer which might support 20-30
people would have added to it roughly $4,000 for a print server,
$1,000/year in maintenance for the server, plus anywhere from 1/5 to 1/10
of an FTE to operate the print server and keep it functioning normally.
(The fact that each print server will not be located in a central machine
room, but out in the field next to the printer will significantly
increase the operational support costs.)
The value of securing print jobs from network eavesdroppers may not
justify the costs associated with doing so. Most print jobs from
administrative users are not likely to be very confidential. While many
such reports are ones that we would not want publicized, the cost to
the Institute if they were revealed would not be very high in many cases,
and would not equal the immense amount of money and human resources that
would be needed to protect against this risk.
It WOULD be possible to provide this service in a few specialized
cases:
* If the print job originates on the client's PC, Macintosh,
or Unix workstation, a printer may be directly connected to the client's
computer, avoiding the use of the snoopable Campus Network.
* If the print job originates on a server centrally located in the
data center, in the case of SAP for example, printing can be done on a
printer adjacent to the server in the same data center, again avoiding
the need to send data over a vulnerable part of the Campus Network.
In this case, the print job would need to be delivered to the user by
a human courier.
* In the case of SAP, if the client has a Windows machine with a
locally attached printer and is running the SAPLPD program, it will be
possible to securely print jobs from the SAP application server only if
and when SAP modifies their proprietary "t" protocol to provide for
data encryption between the server and the client machine.
* In the case of programs which run only on the local machine of
the client (for example: Excel, Word, Powerpoint, etc.), secure printing
may be achieved by using a printer attached directly to the client's
machine via a serial port or parallel port.
In summary, R-Ready believes that re-engineering teams should
examine their business requirements very closely before concluding that
"secure printing" is a requirement. In those cases where "secure
printing" is genuinely required, a special-case solution is currently
the only cost-effective option. Hopefully, in time the requisite
technology will become available in the marketplace to permit us to
revise this recommendation.
