One good method of auditing is to use the Internet.
Why wouldn't that auditor have direct, physical access to an authorized network inside the same building? Is the risk of sending sensitive data over the very public Internet worth having the convenience to do the job off-site?
However, you find some good pages with safe looking names that aren't apparently in a filter yet.
How is that going to happen when the auditor is on a workstation with no access to outside networks and no means to copy the data to a portable device? That's even easier to arrange than encryption and firewalls.
You could write a script (or scripts) to output pseudo-randomized data in a clean, parseable format. Create a database using the same schema as your production database and populate it with the output from your script(s). Simple and boring, but it's easy and it works. Even if you want to generate a massive database it's simply a matter of running the script over and over again with incremental data. Or, just create very simple scripts to generate a basic dataset and do the rest with queries.
To me, the extra work is worth it. I'd rather eliminate the risk than minimize it.
Plus, I just happen to believe that controlled datasets make for better testing. It's really no more difficult to write a script that generates random, re-occuring errors than it is to write one that doesn't, so you can pretty much attack your code/database/whatever from any angle you can think of. And for those you can't think of, just loosen the parameters and generate more random tests. You are only limited by the thought and time you want to put into it. With real data, scrambled or not, you are simply stuck with whatever happens to be in the tables at the time you grabbed it. Also, real data would already have been normalized and, in my opinion, not well suited for testing.
My guess is they had the data locally in Excel spreadsheets, fiddling with things.
Dummy data. In all my years as a software engineer I have never worked with real or production data. There is never a reason for it, so just dummy something up and use that. Then situations like this are simply impossible.
Many people have secure information on their hard drives too.
Not in the Department of Revenue. At least, they shouldn't. That they obviously do should be a huge cause for concern and a process audit or three.
Trojans don't replicate. While its payload might, the trojan itself is just a delivery mechanism.
From the article:
The "trojan" program attached to the file may have sent taxpayer information back to the source when the computer was turned on again.
That suggests to me that only the workstation was compromised, as does this:
McLaughlin said the department determined on May 15 that the computer was being improperly used and on May 23 that some data may have been captured and sent out.
What was real data doing on a workstation with Internet access in the first place? One would think (hope?) that such data would be under heavy lock and key and only accessible by the software written to manage it or, when absolutely necessary, a trusted administrator with lotsa logging.
It is absolutely amazing to me that this event was even possible.
Slashdot Mirror
Why wouldn't that auditor have direct, physical access to an authorized network inside the same building? Is the risk of sending sensitive data over the very public Internet worth having the convenience to do the job off-site?
How is that going to happen when the auditor is on a workstation with no access to outside networks and no means to copy the data to a portable device? That's even easier to arrange than encryption and firewalls.
You could write a script (or scripts) to output pseudo-randomized data in a clean, parseable format. Create a database using the same schema as your production database and populate it with the output from your script(s). Simple and boring, but it's easy and it works. Even if you want to generate a massive database it's simply a matter of running the script over and over again with incremental data. Or, just create very simple scripts to generate a basic dataset and do the rest with queries.
To me, the extra work is worth it. I'd rather eliminate the risk than minimize it.
Plus, I just happen to believe that controlled datasets make for better testing. It's really no more difficult to write a script that generates random, re-occuring errors than it is to write one that doesn't, so you can pretty much attack your code/database/whatever from any angle you can think of. And for those you can't think of, just loosen the parameters and generate more random tests. You are only limited by the thought and time you want to put into it. With real data, scrambled or not, you are simply stuck with whatever happens to be in the tables at the time you grabbed it. Also, real data would already have been normalized and, in my opinion, not well suited for testing.
Actually, it's just the opposite. For one, the thief will get through all of the records eventually. If they don't, a buyer will.
Also, the bigger the leak, the more complicated it becomes to account for every potentially compromised individual and notfiy them.
Forgive me if I offend, but I had a good chuckle at that.
Dummy data. In all my years as a software engineer I have never worked with real or production data. There is never a reason for it, so just dummy something up and use that. Then situations like this are simply impossible.
Not in the Department of Revenue. At least, they shouldn't. That they obviously do should be a huge cause for concern and a process audit or three.
From the article:
That suggests to me that only the workstation was compromised, as does this:
What was real data doing on a workstation with Internet access in the first place? One would think (hope?) that such data would be under heavy lock and key and only accessible by the software written to manage it or, when absolutely necessary, a trusted administrator with lotsa logging.
It is absolutely amazing to me that this event was even possible.
You just got yourself a fan with that post. :D
I couldn't help it. I had just finished up reading a flame war about Coulter over at Crooks and Liars. :D
Who let the Freeper in here?
Here :)
(like soda, which is pumped full of carbon dioxide)
You call it carbon dioxide. I call it life.
You haven't paid for it, therefore you're not bound by the EULA restrictions.
Well that clears that up.
possessing child pornography, threatening the governor or torturing an animal
I'm pretty sure one of those is legal. I just can't remember which.
There goes the amd64 stable keyword...
Sure. Right after they sign their kids up to go to Iraq.
Only at Slashdot do you get modded down for congratulating someone on a good post. Stupid, stupid people.
lol so true!
Excellent post! I really like your points. :)
The mother of all necessity.
Some of us still are!
$500 for something lower tech than a Speak-n-Spell...
Very well said!
lol, fuck you guys. see, this is why i never log into this POS site anymore.
later losers!
And thanks for all the fig leaves.
I love you guys. Except for the one that modded me down. I hope he burns in hell. =)