October 31, 2015 at 11:33 am
Comments posted to this topic are about the item SQL Injection - The Revenge
October 31, 2015 at 3:28 pm
Heh... ok... without naming names.
I consulted for one company to help them with their performance problems. In the process, I ran across a table with SSN in plain text. Doing a little more investigation, I found out that there were 48 tables in the database with SSN in plain text because they were using it as a Primary Key for the customers.
I suggested to the "Compliance Officer" that they encrypt the SSNs (as well as other PII but at least the SSNs). She said "Well! Even the Social Security Administration doesn't require THAT! Besides, we have great system security!" I told her that she's 100% correct (although they do recommend doing so) and with that in mind, she shouldn't mind showing her good faith by putting her own PII and SSN into the system. We know how that went. 🙂
This is the same company that gave me Domain Admin privs on the very first day with no background check. I AM trustworthy and I would never abuse such a privilege but that shows how "great" their security is. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
October 31, 2015 at 5:41 pm
For me as well, no names.
How about one company about keeping data files containing PII on the network for over 20 years? They also had a home-grown HR system that kept track of everyone's data (SSNs, PII and some PHI) required to insure them. This is the same company where all developers have sysadmin. Then again, since the applications run with sysadmin privs, why not the developers?
I've also seen an Oracle system with unencrypted SSNs about employees and all their dependents that made it accessible via an "intranet" that was accessible on the internet. Oracle DAD security being what it was, it wasn't seen as a security risk. And no, it was not an SSL site.
November 1, 2015 at 3:59 am
Out of interest when I register on a new site (and can be bothered, but in particular where security is important to me) I do a Lost Password Request. It always bothers me when I get an email with my password in plain text, rather than a "Click this one-type-code-URL to set up a new password, you have one hour to do this etc. etc."
November 2, 2015 at 1:19 am
The problem is always convincing the decision makers to make the correct choice:-
The decision maker will always be tilting towards the first and thinking "what is the chances of item 2 blowing up while I have responsibility for it"?
As to what I have seen? Fairly common stuff
November 2, 2015 at 5:44 am
Jeff Moden (10/31/2015)
...This is the same company that gave me Domain Admin privs on the very first day with no background check. I AM trustworthy and I would never abuse such a privilege but that shows how "great" their security is. 😉
We all know that "we" are trustworthy but "they" don't...and there is always one bad apple.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 2, 2015 at 5:46 am
Kristen-173977 (11/1/2015)
Out of interest when I register on a new site (and can be bothered, but in particular where security is important to me) I do a Lost Password Request. It always bothers me when I get an email with my password in plain text, rather than a "Click this one-type-code-URL to set up a new password, you have one hour to do this etc. etc."
Agreed. They should not be able to get the password as it should be a salted asymmetrically encrypted variant. Possibly just a hash.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 2, 2015 at 5:49 am
What I have seen MANY times is a website who do not limit access to the logged on user's data e.g. having the user ID in the URL then, following a manual change to the ID on the URL and a refresh, allowing the return of someone else's data.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 2, 2015 at 5:51 am
In the case of TalkTalk clearly no penetration testing occurred.
This is a failure of development team management on top of the failure of the developers (web/backend/SQL).
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 2, 2015 at 7:37 am
Naming absolutely no names, have you ever run into resistance in implementing what you know to be vital security features?
Yes. all the time always and forever (30 years being forever). Because implementing anything costs money and there is no "Skin in the Game" for the people in charge of that money.
Until there is a system that holds a business and not the "Computer People" accountable for these white collar crimes you will continue to hear about these issues and never hear about how they won't happen again.
Also you won't stop if from being an actual Business Model:
There was a company that collected and sold the personal information of all it's customers.
To include the banking or billing information. Their justification was that the EULA mentioned that any data collected on the web site belonged to the company.
There was another that did not pay their offshore dev team. They did not have to because all they wanted was access to 4 million users records that included billing information.
IMHO - We gave up information security for cheap outsourcing long ago. Until there is a way to make the decision makers accountable for the issues caused by their poor choices this will happen. As long as it looks fiscally responsible to be Security deficient we won't have any Information Security. If you think we have any of that now then you must not work in the same universe I do.
November 2, 2015 at 7:49 am
Jeff Moden (10/31/2015)
Heh... ok... without naming names.I suggested to the "Compliance Officer" that they encrypt the SSNs (as well as other PII but at least the SSNs). She said "Well! Even the Social Security Administration doesn't require THAT! Besides, we have great system security!" I told her that she's 100% correct (although they do recommend doing so)
It also says right on the Back of every SSN Card that it is a Federal Offense to use it for identification purposes or collect it for any reason other than SSN. Unfortunately this has never been enforced so it is collected and used by everyone for identification. In other countries my SSN card (and Passport) was demanded for ID instead of the State Issued Drivers License. The argument was the need two forms of Federal Id and State issued Id is regional.
Can you point me to the Compliance regulation that demands SSN be encrypted?
November 18, 2015 at 11:03 am
Naming absolutely no names, have you ever run into resistance in implementing what you know to be vital security features?
Unfortunately, more or less every single day/week at work... it's a hard life being a data gatekeeper.
November 18, 2015 at 11:49 am
PHYData DBA (11/2/2015)
Can you point me to the Compliance regulation that demands SSN be encrypted?
I've not had to cough up the links in a very long time and the ones I have no longer work. Most of it had to do with the credit card regulations and PII in general plus the grilling I've been through in the last several audits at my FTE company (and we don't even use SSNs/TaxIDs). Guess it's time to find the new links.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 18, 2015 at 11:50 am
Terje Hermanseter (11/18/2015)
Naming absolutely no names, have you ever run into resistance in implementing what you know to be vital security features?
Unfortunately, more or less every single day/week at work... it's a hard life being a data gatekeeper.
+ 1000 to that. You said a mouthful.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 18, 2015 at 1:08 pm
Jeff Moden (11/18/2015)
PHYData DBA (11/2/2015)
Can you point me to the Compliance regulation that demands SSN be encrypted?I've not had to cough up the links in a very long time and the ones I have no longer work.
The ones I have, the ones on the SSN web site, and in the PDF docs that were last updated in 2008 are all dark links.
Not surprised yours are either.
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply