Saturday, February 20, 2016

Apple's Dilemma

By now, most people know that Apple is refusing to comply with a court order to decrypt the contents of a cell phone. The Justice Department isn't too happy with that, and calls it a marketing strategy.

They are right.

However, to call it just a marketing strategy would be incredibly short-sighted. Before I can address that, let's look at what's are the heart of all this. Over the last couple of days, I spent more time explaining what cryptography is, and what purpose it serves, than I spend time explaining what the order is really about.

So, here it goes: cryptography is a technique to allow people to communicate securely in the presence of an opponent. There are a few key components:

1. Cryptography is about communications. In other words, cryptography protects messages. In today's world, most of those messages live on mobile devices, such as smartphones.

2. Cryptography is about security. In most cases, that idea of security is used synonymously with confidentiality. Cryptography can do more than that, but the other cryptographic services are not really in scope in this case.

3. Cryptography assumes an adversarial environment. Without an 'us-and-them', there is no need for cryptography.

Apple, Google, Facebook, WhatsApp are all in the business of messaging. Furthermore, they believe that the senders and recipients of messages expect a level of privacy concerning their exchanges. As a matter of fact, they see privacy as a key competitive advantage, and they believe that without privacy their services will fall out of demand.

Privacy requires message confidentiality. Confidentiality of messages requires cryptography.

In other words, removing, or purposefully weakening cryptography, puts these companies at a global competitive disadvantage.

Note the word 'global'. Apple doesn't just sell their goods in the U.S. While flawed, the U.S. system of checks and balances actually works pretty well; especially when compared with other countries. Consumers in repressive regimes don't just look for cryptography as a nice-to-have feature, it is something that can save their lives, or even the lives of their families, friends and neighbors.

Second, the court order requires Apple to invent and build a product that currently does not exist. It is similar to telling a builder to first build a house that isn't there yet, but leave out any doors and windows, so that a warrant can be executed when he is done. Apple is not the FBI's private on-demand software development shop. Asking a company, via court order, to invent, build and hand over something that does not yet exist is a scary idea.

Third, all iPhones are pretty much the same. Once the software has been developed to unlock the phone's secrets, it can be used to open all iPhones. Anywhere in the world. Always.

While the FBI stipulates that this court order only applies to one specific physical device, the damage to Apple's brand is done as soon as words comes out that the vulnerable version of their software exists. As much as companies try to keep things secret, they aren't very good at it. The mere existence of such software will cause it to eventually leak. When that happens, anyone (national states, criminals, or just about anyone else), will be able to use it.

Two real questions remain:

1. Is this court order indeed based on legal grounds? I am not a lawyer, and I cannot answer that question.

2. Is our deep fear of terrorism an acceptable reason to compel one of the countries strongest companies to weaken its own brand, invent and develop products that do not exist, and provide governments world-wide (not just in the U.S.) with unlimited access to any cell phone, at any time?

If so, the terrorists have achieved their goal: we have allowed fear to influence every aspect of our daily lives. The fact that Apple unlocks one more phone really doesn't matter then.

Update: Fixed a whole lot of typos.

Friday, December 11, 2015

Changing jobs

New job

Effective January 1st, I'll complete my transition to the Dark Side by vacating my position as Information Security Officer. Afterwards, I will join Adelphi University's full-time faculty. My primary focus will be on computer science in general, with an emphasis on cybersecurity.

In my new position, I'm going to be rekindling my research interests, and hopefully do something that is interesting and valuable to the community as a whole. With a change of responsibility comes a new focus, and hopefully, more materials to write about here.


Want to replace me?

If you are interested in becoming my successor as Adelphi University's Information Security Officer, please take a look at the job posting and apply. I'll be more than happy to answer any questions you may have.


Adelphi is a great place to work; salaries aren't bad (not great either ;), the campus has a close proximity to NYC, there are decent benefits, its campus is beautiful,  and you'll be in a fairly informal and non-hostile work atmosphere. Even better, you'll work in a professional well-run department and you will have FULL OWNERSHIP of the Infosec function.

Note to bad guys

Until my replacement has been appointed, I will not fully vacate my position. Logs are still going to be monitored, the phone will still be answered, email will be watched. Basically, nothing changes.

Wednesday, September 9, 2015

Incident Response 101

A few weeks ago, we had a minor emergency: a water supply line burst in a wall and decided to flood the floor of the IT department at a rather impressive rate. Being located in the basement, the water really had no where to go, and it started pooling rather quickly. Fortunately, the burst pipe was a fresh water supply line, rather than a waste disposal line.

A gut response of most people working in a service job is that they feel the need to actively help out in a situation where help is needed. In any form of emergency scenario, as is the case with computer security incident response, there are a few things to remember. I'll list them here again, in hope that they are useful to someone.

1) Slow down. Initial reports from others, as well as your own initial assessment, is most likely incorrect and incomplete. Count to ten, take a deep breath, and re-assess the situation.

2) Verify that there actually is an incident. If you get reports that something is going on, always verify them to the extent reasonably possible. In many cases, you'll find that reports are well-intended, but often wrong. However, always thank people for reporting and encourage them to keep doing it. You will never want to shut down folks; it is better to get 100 reports that were unfounded than miss the one that isn't.

3) Put someone in charge. Somebody needs to be put in charge of a scene. That person tells others what to do. Anyone who is not in charge should NOT initiate response actions on their own. This is the hardest one of all. Most technical folks are type A personalities who feel the need to be in control. Yielding that control to somebody else is hard, but doing so ensures that nobody is put in harms way, that no unnecessary effort is made, and that all necessary steps are taken. The National Incident Management System does a pretty good job at describing a structure to handle emergencies.

4) Secure the area. Whether you are dealing with a physical emergency or with a cyber emergency, securing the affected area is a necessary prerequisite for containment. Securing the area includes sending people who are not directly involved in response on their way, making sure that all persons are physically safe (and stay that way), and protecting property.

5) Contain the badness. Stop the situation from getting worse. In this example, it is as simple as shutting off the water supply. In other systems, it may be transferring live traffic to a secondary server, shutting down a system, or null-routing certain IP space.

6) Eradicate. Make the problem go away. In our flood scenario, we had a plumbing crew come in to replace a cap that had let go. In a server compromise, it may require a full system rebuild and data restoration from known-good medium, or a thorough malware removal exercise. Your mileage may vary.

7) Restore. Go back to a normal situation. In our case, the pipes were repaired, carpets dried out, sheetrock replaced and walls repainted. Always continue to watch for continued signs of trouble: as good as a job you may have done to eradicate the problem, it is easy enough to miss something small, or to accidentally not address the root cause.

8) Learn. One things are humming along nicely, go back and find out what you can do to make things better for the future. Looking back to place blame is unproductive.

Each of these steps has a distinct set of tactics associated with them. For example, when receiving a situation of a potentially dangerous situation, a tactic of keeping a distance to assess further risk and damage is probably wise. It is easy enough to slip in water. When containing a situation, messing around with electrical equipment in the middle of a flood doesn't make things better. In order to restore a backup from known-good, you a) need to have a backup, b) be able to read it, c) known when badness started and d) have archives that go back far enough.

Having an incident response strategy, and people trained in executing that strategy, is paramount.

Remember that, often, sending people out of harms way a good initial response. Removing unnecessary people from the equation without making them feel undervalued reduces chaos and complexity. It also ensures that 'need-to-know' is maintained. However, sending people out of harms way also requires established tactics: making sure that supervisors account for their reports, as well as for their areas guest and contractors is a good plan.

All of this comes down to preparation: plan for the worst, validate the plan through exercises, and train people in the tactics.