Re: Obfuscated stored procedures (was Re: Oracle and Postgresql)

On Sep 16, 2008, at 6:39 AM, Jonathan Bond-Caron wrote:
> After some research, I found this article that I believe will make a
> stronger use case:
> http://www.iosn.net/network/news/Managing%20the%20insider%20threat%20through
> %20code%20obfuscation

I can tell without even clicking the link that it would be a waste of
time to read.

The only way to manage internal threats are to have a good security
policy that limits what each person can do to what they need to do,
and having backups.

If I work as a developer or DBA and cannot immediately go looking at
code when there's a problem, it's very detrimental to productivity.
Gee, I wonder why companies that support these antics grow to insane
sizes of employees? Having access to a copy of the code should not be
a security threat in any way. If it is, then the underlying
infrastructure/security policy is broken. Not having visibility into
what unrelated code does leads to crappy, bloated code. For instance,
I was updating the SQL in a class method the other day. Technically,
I don't require any visibility into the calling code, and the above
page probably advocates that it would be hidden from me. But I noted
that the database results were coming back in an ordered fashion, and
being returned as an unordered hash. I did some grepping through the
rest of the codebase, and found that the callers then did their own
sort in perl to reproduce the lost database sorting. So I was able to
easily fix more than required and improve overall efficiency. With a
code obfuscation approach, this would be impossible and the current
code would be more bloated and slow.

My previous employer has some ~100 PostgreSQL servers serving up one
of the most popular websites in the world. The only thing standing
between me and complete destruction of all that data is a wifi
password (WEP even, because that's more convenient than requiring
folks to have WPA2 support) because convenience is the first priority
and any security architects are lazy or nonexistent (in the latter
case, the responsibility lands on sysadmins, which does not work out
well in most cases). In than environment, they give postgres user
trust access to anyone on the production network, and then make the
office a part of the production network via a permanent VPN link (it's
a VPN, so it must be secure, right?) to enable the developers to work
easier (like many places, they don't have a completely isolated dev
environment).

I've seen a lot of PostgreSQL environments in the last few years, and
every single one of them connects to the database as the "postgres"
user or another superuser, requires ability to execute DDL, and all
sorts of other gaping security issues, and I cannot think of the last
time I heard somebody else in a work setting speak of a GRANT that was
not a GRANT ALL, even when all that is needed is select access, for
example.

Companies need to fix their security architecture and keep production
isolated from development, not go down the obfuscation rathole. If
they do that and still have a threat that they think code obfuscation
would help manage, I'd love to see it.

Cheers,
--
Casey Allen Shobe
Database Architect, The Berkeley Electronic Press