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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
