Schneier on Security

glenn everhart • March 11, 2017 9:17 AM

At first blush, the idea that government might regulate software practices to
force security sounds appealing, in that private efforts get little traction.

However it is apparent too that government is neither infallible, nor even
of constant good will. Regulations would be devised by people who are
often completely ignorant of what they are supposed to be guarding, and
enforced in ways often more directed to “gaining scalps” by prosecutors
rather than mitigating social risks or losses. Expecting regulation to fix
software vulnerability is like expecting your garbage man to treat ruptured
appendix cases. He might have some idea at some level the effect he wants
to achieve, but most of the time has no experience in how to achieve this
effect without killing the patient. (We’ll leave aside the thought that he
might also legislate tht nobody but a garbage man may perform this operation.)

Let us drop back a bit though and consider the way malware operates. At a
high level, it runs by doing things that are not authorized by whoever is
running the computer, and generally which are not known to the computer owner.
This gets us into trouble because computer functions are authorized by asking
“is this person allowed to perform this operation?”, where the ‘person” is
generally assumed to be the machine owner and the operation on the computer
is usually constrained only very coarsely (due to the cost of administering
very fine grained permissions).
This thought suggests that a practice that said “when you publish software
you must indicate what it will do” might be helpful. Commercial vendors might
claim they don’t want customers knowing what they do, but disclosure even at
high level of which areas of a computer were touched could be useful in
allowing a knowledgeable user to decide whether to run a piece of code. Malware
would be tripped up immediately. Open source software would be less affected
since its source code is a fully detailed description of its function, but higher
level description of what is being done should be encouraged there too.
Anything implementing an interpreter might of course spoil such description.
If there exists a command telling a program ‘open file X for read” or “write
file Y”, it could read or write anything not externally blocked, even though
it might almost never be given such a command. High level disclosure will
quickly get you into the weeds and lead to useless and probably boilerplate
documents that help nobody.

Let us think about what offering a public service means on the internet
though. It has long been standard practice that anyone might attempt an
ftp connection with some site, use username “anonymous”, and if that is
accepted, anyone might be given file access to some storage, without any
accusation of wrongdoing. Using username “guest” or ‘user’ would also
generally be viewed as benign. Accepting connections on port 80 or 443 for
http or https functions also is an indication that the site accepting these
has authorized such and offers them to anyone. In general, we can find what
services are offered on the Internet by attempting to connect to services
and finding them open to us.
An ambiguity occurs as soon as user credentials are asked, and while common
names like “anonymous” or “guest” sometimes indicate harmless intent, some
sites want a mail address and don’t really care what mail address is given
for a username.
It is thus reasonable to think of a public service on the internet as
some service which can be obtained with “little’ effort by connecting to
a server.
So then, is access to by using, say, “admin” and password
access to a public service? I am inclined to think it is,
though the operator of that machine might not have intended to offer it
as such.
The next question is “should there be liability for actions your machine
takes as part of a public service you run”?
Now, if you buy a router and it offers some services you don’t know
about, due to not being told prominently enough by the vendor about them,
the one running the service arguably is the vendor. If on the other hand
you set up a service yourself and don’t control what is done, you are the
one running it. Folks might remember when ftp sites were ubiquitous and
some got in trouble for allowing everyone r/w access and the sites
became drop sites for stolen software or documents. The implementors
did not intend their sites to be places to quickly replicate files that
should have not gotten out, but this kind of abuse meant that just setting
up an ftp site and letting everyone write to it with little or no
supervision was a problem. Likewise some service that can be misused
to, say, send out millions of mails might be set up with innocent
intent, and might run a long time without trouble, but might become
a problem due to its users.

If one sets liability rules for services offered to the public which cause
trouble, there are lots of ways these could cause troubles, but if the
rules are instituted with exemptions for those who are innocent (the
not-too-technically-savvy individual who runs some machine that gets connected
to a network and whose machine behaves in ways he is not informed of,
as a prime example) these kinds of considerations would at least
enable some rational direction to deciding what might be done to whom.
There needs to be some clear showing of responsibility, and also clear
statements about fraction of blame, which occurs in cases of civil damages
but not AFAIK in criminal proceedings.

I don’t think government has any special wisdom about liability or to set
up regulations that can be relied on. However, whatever limitations may
have prevented liability issues from being addressed might be lifted and
perhaps case law might come up with some results that could help with
automata which become dangerous partly due to emergent effects. Thinking
of the functions as “public services” as above may help in that evolution.