Monday, October 25, 2010

Application Security Challenges

Assume that all your application security challenges are conquered. You've got smart people and you've trained them well. They catch all their exceptions, they bound their arrays, they else their if's and sanitize their inputs and outputs.

Congratulations. You've solved your biggest security problem.


How about your crufty old apps?
You’ve got de-provisioning down pat, right? No old apps laying around waiting to be exploited? Nobody would ever use the wayback machine to find out where your app used to be, would they?
An associate of mine did the forensics on one like that. Yes, you can upload a Unix rootkit to a blob in a SQL server, execute it directly from the database process and target a nearby Unix server. Heck – you can even load a proxy on the SQL server, poison the Unix servers ARP cache, and proxy all it’s traffic. No need to root it. Just  proxy it. Network segmentation anyone?
Any old libraries laying around?
Yech. I have no clue how someone who downloads [insert module here] from [insert web site here] and builds it into [insert app here] can possibly keep track of the vulnerabilities in [insert module here], update the right modules, track the dependencies, test  for newly introduced bugs and keep the whole mess up to date.
How about those firewall rules?
Speaking of de-provisioning – Firewalls rules, load balancer rules… Are they routinely pulled as apps are shut down? Have you ever put a new app on the IP addresses of an old application?
Shared Credentials anyone?
That’s that whole single sign-on, single domain thing. It’s cool, but there are times and places where credentials should not be shared. Heresy to the SSO crowd, but valid none the less.
You Management Infrastructure is secure?
Of course you don’t manage your servers from your desktop, you’ve realized long ago that if it can surf the Internet, it can’t be secured, so you’ve got  shiny new servers dedicated to managing your servers and apps. Now that you have them, how about making them a conduit that bridges the gap between insecure and secure?
Speaking of System Management

Do you system managers surf the Internet? Hang out at coffee shops? Do you trust their desktops?

Same goes for DBA’s by the way. A trojan’d DBA desktop would be a bad day. I’m just too lazy to draw another picture.

Don’t forget Storage management
Can’t figure out how to hack the really important [secure] systems? How about cloning a LUN and presenting it to the really unimportant [insecure] system? Your really cool storage vendor gives you really cool tools that make that really easy, right?
Or your Backup Infrastructure
We aren’t too far removed from the day when Legato tech support insisted that backing up data through a firewall was unsupported. Even if you tried, you soon figured out that by the time you opened up enough firewall holes to get backups to work, you’ve pretty much lost the ability to segment your network. And after you’ve poked the required Swiss cheese holes, the firewalls role over and die when you stream backups through them anyway. We can’t afford to a dedicated backup server for every app, so we build shared backup networks, right? What do backup networks do - connect every network together?
How about remote access?
Capture credentials on the sysadmin’s home computer, try them against the corporate SSH gateway? Don’t worry about it. nobody would ever think to try that. You’ve got two-factor, obviously.
Your Build/Deploy Process?
I think it’d be so cool to have my parasite malware get deployed to prod using the enterprise change management/deployment process. Heck – it’d even inherit source control and versioning from the host. Neat!
Take a look around.

When you are buried deep in your code, believing that your design is perfect, your code is checked, tested and declared perfect, and you think you've solved your security problems, stop & take a look at the security challenges surrounding your app.

No comments:

Post a Comment