… it’s Sony.
Picture yourself as the head of a company. Now picture yourself facing a class-action lawsuit. A suit with the potential for 77 million plaintiffs.
Kristopher Johns of Birmingham, Ala., Wednesday filed a lawsuit against Sony in federal court in San Francisco, alleging negligent data security practices, privacy violations and breach of warranty.
The lawsuit, which seeks to represent all subscribers to Sony’s PlayStation Network and Qriocity service, also accuses Sony of not informing consumers quickly enough about the exposure of their personal account information and credit card data due to the breach.
In his complaint, Johns accused Sony of violating the Payment Card Industry Data Security Standard by failing to implement a proper firewall and to encrypt card holder data. Sony also violated the standard by retaining card holder data, the lawsuit charged.
Sony disclosed the breach more than six days after it had abruptly shut down PSN.
Arthur C. Clarke was right. Today’s science fiction is tomorrow’s science fact.
The researchers didn’t find a wide-open door so much as the security employed by a 1920s speakeasy: once they learned the secret knock, the unidentified test car’s controls let them in no questions asked. The team sent fake warning messages from 40 meters away, and in another experiment, got the test car to flash a warning that a tire had lost all pressure while beaming the signal from another car as both drove 68 mph.
Because each sensor uses a unique ID tag, it was also possible to track specific vehicles, in a way that would be far less noticeable than roadside cameras.
The age of the carhacker has arrived.
I was trying to upgrade an application, and due to the list of complexities involved in the upgrade process, I had decided that the best course of action was to back up all crtical data, uninstall the previous version, and then do a clean install of the new version.
Having done this before on the other production boxes we have, and this box being the same model, OS, and Citrix install as the other boxes, I made a horrible mistake… I assumed that it would be the same smooth process as had occurred on the other servers.
So I grab my word doc chock full o’ meticulous notes on how to upgrade this monster, and follow each step to the letter and after about 10 minutes or so, the uninstall goes smooth as silk. I go to do the re-install and I get this message upon clicking the first executable file:
Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.
Upon seeing this, I start to go through in my head the list of usual offenders.
- Do I have administrative rights? Check.
- Since this box runs Citrix, did I disable logons for other users and enable installation mode? Check.
- Anything set as read-only that shouldn’t be? Nope.
At this point, I was damn near befuddled, and when you get befuddled, you theories start getting more and more far fetched. Starting with “Is my account corrupt?” then after logging on using another admin account and getting the same result, you migrate to “Have the Chinese taken control of my server and they are just toying with me right now?” and culminating with “Am I really doing this or am I just another hairless pig fetus floating in a plexiglass bathtub somewhere deep inside inside the Matrix?”
It was at this point that I decided to call Saulo, one of our intrepid Windows admins where I work. Working with Saulo is great for several reasons… you can get him on weekends, he knows his shit, etc…. but his specialty in this case is that he can find solutions when all of your mere mortal options have been exhausted. After some trial and error and research, he found this little nugget of wisdom that I will now impart to you:
- Open Internet Explorer (I know. Seems totally unrelated, but this is Windows, so it’s not supposed to be intuitive. Just work with me here.)
- Go to Tools -> Internet Options.
- Select the Security tab
- Select Internet and then click the Custom Level button.
- In the Miscellaneous section, the Launching applications and unsafe files setting was set to Disable, which is the root cause of my problem. To fix this, set it to Prompt (recommended).
This screenshot will show the visual details of the steps shown above.
This is just a blurb that I wanted to publish for my sake (so that I could look it up later) and for anyone else who has to install Alterian Studio who will invariably run into the same problem.
The problem: You want to set up a security group so that certain fields in your database are invisible to certain users. You log onto the management console and set up your group only to find that when you log off of the AMC and start the application, the fields you thought were invisible are still visible. You clearly saw the group created and users assigned to it in the AMC when you were building the group. So what happened?
Here is what happened: When you were logged onto the Alterian Management Console, you were indeed building a security group and assigning users to it. However the issue lies with where you were building that group. You were building it in memory. The AMC does not write to disk until you actually log off of your session. The other piece to this puzzle is what does the writing.
If you remember, back in the heady days of AMS 2.2, there were 3 parts that made up the essence of Alterian: Molecule.exe (the interface), Atom.exe (the distributor), and Nucleus.exe (the engine). Now with AMS 2.5/Engine 4.1 comes some serious performance improvements, and one of the reasons for those improvements is ConnectionBroker.exe, the sort of ‘traffic cop’ for the multi-tenant environment. You’ll also remember that in AMS 2.2/Engine 3.1, you needed to use DCOMCNFG to tell the application what account it needs to run under so that proper rights are given for these executables to access folders, write to disk, use network shares, etc. With ConnectionBroker in the mix, you need to do the same thing, but for ConnectionBroker, this is not done in DCOMCNFG. ConnectionBroker runs as a service, so configuration happens in the Microsoft Management Console under Services. Another catch is that changes are not immediate. When you change a service, you have to stop and then re-start the service for the change to take effect. By default, ConnectionBroker.exe runs under SYSTEM (the Windows SYSTEM account, not Alterian’s administrative account) which often is not given rights to write data willy nilly all over your server. Switching to whatever generic Alterian account you use in DCOM usually solves this problem as that account is 1) not accessed by regular users and 2) is an admin level account (Alterian uses ‘nuclog’, but where I work, we make our own account).
Once ConnectionBroker.exe service is set to run under a different account than the default Windows SYSTEM account, you will see the Security Group issue disappear. Interestingly, this issue does not rear it’s ugly head when creating/editing users themselves.
My job here is done. CAPTAIN OBVIOUS! AWAAAAAAAAAAYYYYY!!!!!
(little kids waving) “G’bye!! G’bye Captain Obvious!”