Tuesday, August 7, 2012

The very four digits that Amazon considers unimportant...

"The very four digits that Amazon considers unimportant enough to display in the clear on the Web are precisely the same ones that Apple considers secure enough to perform identity verification..." Honan wrote.
Four digits, when combined with my home address and bank account number were all it took for me to gain on line access to a dormant checking account at my bank and enable fund transfers. If I were fond of the various auto-pay options, there would be a dozen or so companies that would have my checking account number, any pretty much anyone in the world can find out my home address (I own a house, so it's in various public records).

Segmenting ones on line life into non-overlapping buckets seems like the best way to break the daisy chain that led to the hack and data loss. I've followed that principle. I try to maintain separate, non-overlapping e-mail addresses and passwords for any on line account that either is connected to something that could cost me money if it were compromised, or is used for account verification for any of those accounts.

I have lots of e-mail accounts and addresses. It's a pain in the azz, and it's only a partial solution.

Read:  ARS, Wired

More thoughts here.

Friday, July 6, 2012

In MumbleWare versions 8.2 and below, the SA password must be set to propq

An e-mail from a vendor, somewhat anonymized:

From: ****
Sent: Wednesday, April 11, 2012 08:22 AM
To: ****
Subject: MumbleWare Case 123456789

Hello ****,
Thank you for contacting MumbleWare Product Support.  I am writing to you in reference to case number 123456789 regarding your request to change your SA password. In MumbleWare versions 8.2 and below, the SA password must be set to propq. If a different password is used, MumbleWare may not be able to communicate with the database and error messages will be generated. The attached KB article references the fact that the SA password must be set to propq in MumbleWare versions 8.2 and below. The second KB article lists the steps involved in moving from MumbleWare 8.2 to 8.3.   
It's only been a decade since we first asked  the obvious question "Can we change our SQL Server SA password without breaking your application".

I guess we finally can.

Saturday, May 12, 2012

A letter to our Apple Account Exec

A couple of days ago myself and a colleague of mine ran into our Apple account exec.  The conversation ended up in the security space, as is probably appropriate considering Apples recent performance in that area. Our account exec quickly followed up with a request for our contact information (good), a press-release style announcement on how much more secure Safari 5.1.7 was going to be (interesting), and a month old article on how to remove Flashback (amusing).

I figured he was missing the point of our conversation. Here's my reply:

Thursday, May 10, 2012 8:31 AM
***** -

The context of our conversation was really strategic, not tactical. The short term issue of a specific malware incident isn't important. (We knew about Flashback and how to remove it  shortly after it was discovered.)

What is an interesting discussion is Apple's strategic, corporate wide attitude towards enterprise desktop security and desktop management and the question of whether or not Apple, as a corporation, will step up to the plate with world class proactive and reactive management of the security of OS X when they are subjected to the same sort of focus from dedicated, highly capable attackers that MS has been subjected to the last decade or so.

The things on my radar:

 - Apple is consistently slow to patch compared to their peers. They were last to the plate with the latest Java fix. That's not a good sign.

 - Apple still asserts that they are 'more secure' than their peers, yet offers no specific technical backing for the assertions. That's not a good sign.

  - In past security performance, OS X has fared well compared to its peers. However it doesn't appear as though its performance is due to superiority in design or execution. OS X has fallen first and hardest at browser hacking contests over the last handful of years, an indication that there is no inherent superiority to OS X in either design or execution. Apples past performance is likely good because nobody bothered to attack them. That has/is/will change. Apples ability to manage itself when it is the target of the worlds best hackers is untested.

  - Apple fumbled badly when they did have a major incident (the delayed response and the number of patches that it took for them to clean up the last malware incident.) That's an indicator of immaturity in the general space of incident handling.

 - Apple insists on mixing routine bug fixes with security updates (today's patch, for example, is both security and bug fix). We prefer to be able to separate patches which are security only (we can rush them out) with patches that may affect the stability of existing applications (we can test them thoroughly). That's really a best practice across any system.

  - The short product support cycle of OS X. Apples peers provide security patches for operating systems that are quite old in comparison to Apple. An OS version that is not supported by the manufacturer with security updates for roughly 5 years after last customer ship is hard to manage in the enterprise space. Unless that changes, we'll have lots of unsupported, insecure OS X installs years from now, as support will have ended when the system is still in use.

  - I obviously don't have any inside knowledge of OS X browser or kernel, but the fact that I have to re-boot the kernel when updating the browser is an indicator that the browser is tightly coupled to the kernel (for good reason, no doubt) but  also is an indicator that any vulnerabilities in the browser have a fair chance of affecting the kernel. Recent browser-cracking competitions have shown that to be true, AFAIK.

 - A really dumb, brain dead mistake like the latest 'store passwords in the clear on when upgrading an encrypted file system' is an indicator of immature processes in Apples internal software development and deployment. If that happens more than once, not only will we have an indicator of immaturity, but we'll also have an indicator that Apple can't learn from its mistakes. (Adobe, for example, would be an example of a company that seems to make the same mistakes over & over again.)

Again - specific incidents are not really interesting unless I perceive them as indicators of larger, more persistent problems.
I have to close up my 11" Air home computer, buzz into work and light up my 11" Air work computer. ;-)


I don't know if Apple is ten years behind Microsoft on desktop security or not. I'm pretty sure though, that there is nothing about OS X (or any other desktop operating system) that is inherently superior such that we can afford to ignore the fundamentals desktop security. This exploit, for example, is platform neutral.

Apple has joined the big leagues. We'll soon find out out well they play.

I'm also pretty sure that even if we do rigorously follow security best practices, we'll still be doing our banking from botted desktops.

If it can surf the Internet, it cannot be secured.