Rick Hillegas wrote:
Daniel John Debrunner wrote:
I think some of this goes back to no good definition of what
"secure-by-default" means. Without a good definition it's hard to make
a decision as to if a behaviour is achieving the desired goal.
If someone wants to offer a definition, I'm eager to consider it. Here
are some related terms:
MaximallySecure: You might get close to this term by turning on every
security feature which Derby supports: Java Security, authentication,
authorization, encryption. Then again, maybe your policy file could be
tightened up. Maybe your authentication scheme could be improved. Maybe
you are running Derby in an environment which is unsecure for reasons
which Derby doesn't understand. MaximallySecure could be a fleeting
state of mind.
MinimallySecure: You might get close to this term by turning off every
security feature which Derby supports. Then again, by loading in some
dangerous user-defined procedures, you could make the situation
arbitrarily worse. Is MinimallySecure just a state of mind too?
SecureEnough: This could fall anywhere on the continuum between
MaximallySecure and MinimallySecure. SecureEnough slides around
depending on the application.
TooSecure: Slides around somewhere else on the continuum. Java Security
and encryption impose runtime costs, which some customers may not tolerate.
Unsecure: Slides around between MinimallySecure and SecureEnough.
secure-by-default: Right now, to me this looks like a factory-shipped
approximation of SecureEnough. The customer may appreciate this as
TooSecure or Unsecure.
We started down this path by deciding that MinimallySecure wasn't
SecureEnough. Later on, we decided not to require SQL authorization. So
MaximallySecure >=
TooSecure >
secure-by-default >
Unsecure >=
MinimallySecure
I don't know how to characterize the security we're proposing for the
10.3 server:
ON: Java Security, authentication
OFF: authorization, disk encryption, wire encryption
MAYBE: username/password encryption
I'm not sure I can state what our model is.
I was thinking of a definition that was more along the lines of what
actions are being prevented than some abstract definitions of secure.
So here's my take:
Secure-by-default prevents security attacks from a remote machine.
Assumptions are:
operating system is secure
java virtual machine is secure
network is secure (ie. intranet)
Concern is only security attacks that are a direct result of the fact a
Derby network server and databases are running on the server machine.
Restrictions applicable to all remote code:
- must not be able to access any non-database information about the
machine. (e.g. /etc/password)
- must not be able to execute arbitrary code on the server machine
Restrictions applicable to remote code not associated a with an
authenticated user:
- must not be able to access any database information
- must not be able to cause denial-of-service attacks for databases
and the server (i.e. bring the server or a database down)
Restrictions applicable to remote code associated a with an
authenticated user:
- database activity must be limited to the permissions granted to the
user (e.g. only shutdown a database if allowed, install a jar file etc.)
Some explicit non-goals:
- denial of service attacks due to server cpu consumption by remote
code is not addressed (e.g. frequent pings of the server, login attempts
etc.)
- denial of server by authenticated users due to significant disk or
cpu usage is not addressed.
How's that as a starting point?
Dan.
