Social Security Numbers in data

  • Our clients are lenders ( Banks and Credit Unions ). A few are using SSNs as the account numbers for loans they make and we store the data. I'm wondering which laws may apply since encryption is not used in the database. We're in California but parent companies are in Eastern US. This data typically comes to us by ftp from the client ( sometimes secure ftp, sometimes not).

    These databases are routinely copied out to development boxes where a large number of people have access. Names and addresses are in the same records. We were purchased last year so I'm not sure about the publicly traded aspect. Previously we were not a publicly traded company, but our new owners may be. Of course many of the lenders are large national companies who are certainly publicly traded.

  • This might help:

    California Office of Privacy Protection: Social Security Numbers

    There's a guide for organizations that includes the California laws which are applicable.

    K. Brian Kelley
    @kbriankelley

  • Indianrock (6/12/2008)


    Our clients are lenders ( Banks and Credit Unions ). A few are using SSNs as the account numbers for loans they make and we store the data. I'm wondering which laws may apply since encryption is not used in the database. We're in California but parent companies are in Eastern US. This data typically comes to us by ftp from the client ( sometimes secure ftp, sometimes not).

    These databases are routinely copied out to development boxes where a large number of people have access. Names and addresses are in the same records. We were purchased last year so I'm not sure about the publicly traded aspect. Previously we were not a publicly traded company, but our new owners may be. Of course many of the lenders are large national companies who are certainly publicly traded.

    First of all - I was under the impression they weren't allowed to use SSN's for that stuff (SSN is no supposed to be used for gov't purposes ONLY, and not to be used for other id purposes; it always was supposed to be that way). They never really were, but as I recall the government has been taking strides to crack down on this stuff.

    You have a lot of vulnerability points you need to handle:

    - Forget the dev server right now, I'd start by focusing on the transport mechanism. FTP is not secure as a transport, so transmitting data in the clear without either encryption the channel (secure FTP), or the file itself (file encryption) is a severe problem. You're talking about financial records; never mind the SSN actually being there or not - you've got pretty much everything else someone would need to hijack identities, steal money, etc...

    - Leaving these files on an FTP server even for a short period of time is in my mind a vulnerability you want to avoid. We had a somewhat similar scenario with health-care files, so we set up a service which would watch a specific folder and immediately move those files out, into a location behind our firewall not accessible by FTP. Even then - we would encrypt the files immediately ourselves, just to be sure they couldn't be breached.

    Once you've handled the intake mechanism, then perhaps worry about how you handle them on your internal systems. As of right now - the process you describe is just begging for a hacker/identity thief to find it. That's not the kind of news coverage you want to have (never mind the legal liability issues).

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • Matt Miller (6/12/2008)


    - Forget the dev server right now, I'd start by focusing on the transport mechanism. FTP is not secure as a transport, so transmitting data in the clear without either encryption the channel (secure FTP), or the file itself (file encryption) is a severe problem. You're talking about financial records; never mind the SSN actually being there or not - you've got pretty much everything else someone would need to hijack identities, steal money, etc...

    - Leaving these files on an FTP server even for a short period of time is in my mind a vulnerability you want to avoid. We had a somewhat similar scenario with health-care files, so we set up a service which would watch a specific folder and immediately move those files out, into a location behind our firewall not accessible by FTP. Even then - we would encrypt the files immediately ourselves, just to be sure they couldn't be breached.

    Once you've handled the intake mechanism, then perhaps worry about how you handle them on your internal systems. As of right now - the process you describe is just begging for a hacker/identity thief to find it. That's not the kind of news coverage you want to have (never mind the legal liability issues).

    This actually depends... A lot of situations like this the data is transmitted over a leased line or over a line with a permanent VPN. There's typically more than just files full of records traversing, hence the reason for this sort of approach. Therefore, the use of FTP may not be significantly riskier than a similar transaction within the data center. Still not the best way to do it, but probably acceptable to the business from a risk perspective.

    K. Brian Kelley
    @kbriankelley

  • Still I will say this should comes under GLBA act. And organization will assign some kind of legal employee and that server should be under monitor. So each and every action should be traced.

    Manoj

    MCP, MCTS (GDBA/EDA)

  • K. Brian Kelley (6/12/2008)


    Matt Miller (6/12/2008)


    - Forget the dev server right now, I'd start by focusing on the transport mechanism. FTP is not secure as a transport, so transmitting data in the clear without either encryption the channel (secure FTP), or the file itself (file encryption) is a severe problem. You're talking about financial records; never mind the SSN actually being there or not - you've got pretty much everything else someone would need to hijack identities, steal money, etc...

    - Leaving these files on an FTP server even for a short period of time is in my mind a vulnerability you want to avoid. We had a somewhat similar scenario with health-care files, so we set up a service which would watch a specific folder and immediately move those files out, into a location behind our firewall not accessible by FTP. Even then - we would encrypt the files immediately ourselves, just to be sure they couldn't be breached.

    Once you've handled the intake mechanism, then perhaps worry about how you handle them on your internal systems. As of right now - the process you describe is just begging for a hacker/identity thief to find it. That's not the kind of news coverage you want to have (never mind the legal liability issues).

    This actually depends... A lot of situations like this the data is transmitted over a leased line or over a line with a permanent VPN. There's typically more than just files full of records traversing, hence the reason for this sort of approach. Therefore, the use of FTP may not be significantly riskier than a similar transaction within the data center. Still not the best way to do it, but probably acceptable to the business from a risk perspective.

    fair enough - but I would consider that rolled that into the "encrypting the channel". So the transmit might be okay. Even so - I get really antsy about those things living on an FTP server, so I would still be setting up that FTP "crab-trap" style (file can go in, but it's immediately removed and put away from anything accessible via FTP.).

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • Thanks for all of the information. I've passed it on to management here. No response yet ( I didn't get a response when I brought this to their attention a year ago either 🙁 ) I've noticed a familiar pattern with small companies started by a family that grow over time. Ours started that way and now has 400+ employees. The tendency is to avoid and put off the growth in management techniques that are needed to stay out of legal trouble as you grow. ( auditing, security, change control, limiting access to shares and data,etc ). Another classic one here is not taking into account the opportunity costs -- a very poor approach to certain tasks is kept in place when investment in software, for example, might free up hundreds of hours of DBA/developer time. "Well we're paying them salary anyway so what's the difference if they spend ten times the hours they should on fixing the same mess for the umteenth time."

    The small company my wife works for only has 15 employees and I see similar things -- a husband and wife starts a company but over time doesn't develop the management skills to keep up with it and sometimes thinks they're immune from government scrutiny -- such as diverting extra company funds to paying the maid at home, etc etc.

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply