Skip to main content

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.


Popular posts from this blog

Cargo Cult System Administration

Cargo Cult: …imitate the superficial exterior of a process or system without having any understanding of the underlying substance --Wikipedia During and after WWII, some native south pacific islanders erroneously associated the presence of war related technology with the delivery of highly desirable cargo. When the war ended and the cargo stopped showing up, they built crude facsimiles of runways, control towers, and airplanes in the belief that the presence of war technology caused the delivery of desirable cargo. From our point of view, it looks pretty amusing to see people build fake airplanes, runways and control towers  and wait for cargo to fall from the sky.
The question is, how amusing are we?We have cargo cult science[1], cargo cult management[2], cargo cult programming[3], how about cargo cult system management?Here’s some common system administration failures that might be ‘cargo cult’:
Failing to understand the difference between necessary and sufficient. A daily backup …

Ad-Hoc Versus Structured System Management

Structured system management is a concept that covers the fundamentals of building, securing, deploying, monitoring, logging, alerting, and documenting networks, servers and applications. Structured system management implies that you have those fundamentals in place, you execute them consistently, and you know all cases where you are inconsistent. The converse of structured system management is what I call ad hoc system management, where every system has it own plan, undocumented and inconsistent, and you don't know how inconsistent they are, because you've never looked.

In previous posts (here and here) I implied that structured system management was an integral part of improving system availability. Having inherited several platforms that had, at best, ad hoc system management, and having moved the platforms to something resembling structured system management, I've concluded that implementing basic structure around system management will be the best and fastest path to…

The Cloud – Provider Failure Modes

In The Cloud - Outsourcing Moved up the Stack[1] I compared the outsourcing that we do routinely (wide area networks) with the outsourcing of the higher layers of the application stack (processor, memory, storage). Conceptually they are similar:In both cases you’ve entrusted your bits to someone else, you’ve shared physical and logical resources with others, you’ve disassociated physical devices (circuits or servers) from logical devices (virtual circuits, virtual severs), and in exchange for what is hopefully better, faster, cheaper service, you give up visibility, manageability and control to a provider. There are differences though. In the case of networking, your cloud provider is only entrusted with your bits for the time it takes for those bits to cross the providers network, and the loss of a few bits is not catastrophic. For providers of higher layer services, the bits are entrusted to the provider for the life of the bits, and the loss of a few bits is a major problem. These …