Today at 10:52am, CarSign said:
1. Are you absolutely sure you need to store the data at
all?
Good question. But as is often the case when management is asked about
these things - they say yes :)
One way to combat that is to help make clear to them how big of a problem
it would be if your social security numbers database was compromised.
Think of the PR nightmare, liability, litigation, possibly even jail time
if there's something criminal about their improper handling of the data.
That said, if you really do need the data, and your web site/web app needs
to be able to decrypt it, then you're kinda hosed no matter what. If your
web server can decrypt it, then anyone compromising your web server will
be able to decrypt it. Even storing it someplace PCI compliant like
authorize.net won't protect you, because your web server would have to
have the login credentials to access your PCI compliant data store, so
anyone getting into your server could get into your data store too.
While there are steps you can take that make things better, there's no
silver bullet for making your data totally safe in the case of a
compromised server, especially if they have physical access to the server.
So if you can't protect against that, at least not completely, what _can_
you protect against?
1. Unauthorized remote web access. Make sure your app doesn't allow any
unauthorized users to view data they shouldn't be able to access.
2. Unauthorized remote access to your server. In short, keep your
server(s) secured properly against any remote attacks that might lead to a
compromise. No ports open that don't need to be open, all services
appropriately secured, etc.
3. Priviledge escalation from a local account. Make sure anyone with any
serious access (i.e. ssh/shell in particular, or direct access to your
databases) on your server really needs it, is using a good password, good
ssh key passphrases, etc. Make sure that you trust both their intentions
and their abilities. (I know people whose intentions I trust implicitly,
but I don't always trust their ability to maintain security or not to make
a big mistake on accident that could lead to disaster.)
I guess my biggest thing is just to be careful not to give yourself a
false sense of security... if the web server can decrypt or otherwise
access the confidential data without manual user input, then anyone with
(sufficient) access to your server will be able to do the same. By the
time you know you've been hacked, they'll have had enough time to grab all
the confidential data, and the cat is out of the bag.
Mac
--
Mac Newbold Code Greene, LLC
CTO/Chief Technical Officer 44 Exchange Place
Office: 801-582-0148 Salt Lake City, UT 84111
Cell: 801-694-6334 www.codegreene.com
_______________________________________________
UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net
