1 Raindrop

Dear Everyone, Its 2013 Please Stop Saying Cybersecurity

I am not sure how the cybersecurity meme started and it sure won't die, but it needs to. We need to stop saying cybersecurity because this gross generalization obscures the real issues that lay beneath.

Mark Twain observed that precise language is the difference between lightning and a lightning bug. When you hear someone say cybersecurity, you can guarantee the very next sentence will contain a wild, sweeping generalization that's likely neither perscriptive nor useful.

Here is why - context matters. Security is extremely context sensitive, what is appropriate for one type of system is not he same as another. 

On the one hand I agree with Pete Lindstrom, management always plays a role. As Roger Needham said, "Management is that for which there is no algorithm. Where there is an algorithm it's administration."

But now let's consider the systems that Ralph Langner works on - critical infrastructure. Sure there is always an element of management, but its not the same thing that's being protected.

It was only a couple years ago where we had different breach report providers arguing with each other over threats. At the time APT reports started coming out of Mandiant, other organizations demured that they did not see the same kind of threats in their data, they were seeing credit card and commerical fraud, while Mandiant was seeing IP disclosure. Each made leaps from what they were seeing to paint a bullseye on what the real threat was. Here is the thing -

1. they were both right from their perspective

2. how you defend in either case is very different. So what we learned from either data set was not really perscriptive to the other 

Why? Its not about the threats (and it ain't about the cyber), its about the assets! Just like security, "cyber" is only useful in a given context. And that context is assets - users, customers, identity, data, IP, transactions, cash flow, competitive advantage and you name it. 

Cybersecurity is meaningless because cyber does not describe any asset at all, it presupposes there's some security regime that "just works" for any connected digital anything. This would not matter at all except now its the go to concept for policy makers.

Cybersecurity must be replaced with something else to be useful. I suggest Asset Security. Four of the six largest companies in the US are - IBM, Apple, Google, and Microsoft (the other two are oil companies). Notice anything about the four? They are all tech companies!

In investing people will often say "well the tech sector this" or "the tech sector that", I really have to laugh every time I hear this. What in the world do those companies have in common really? Sure they all have computers (newsflash its 2013) but trace the cash flows: Apple is selling iThings and movies and music to consumers. IBM is selling mainframes to big companies. Google is selling your data to advertisers and  Microsoft is selling stuff to help companies work. Their customer bases have little in common, why lump them together?

I laugh when I hear "tech sector" but I cry when I hear "cybersecurity", what is appropriate hardening for Netflix, a healthcare organization, a bank, a consumer, and critical infrastructure has little in common. Even Cloud Security varies wildly from one Cloud integration to another. There is a reason why Ross Anderson's epic Security Engineering has chapters dedicated to domain specific concerns by industry. Tech is a meaningless term in 2013, instead trace the cash flows to the customers. Likewise cybersecurity is meaningless, trace the security under discussion to the asset its defending.

Mark Twain also observed that "a man who attempts to carry a cat home by its tail will learn a lesson he can learn no other way." trying to perscribe global cybersecurity regimes to cover all things cyber will also lead to lessons that can be learned no other way.

Connected digital things are all around, know your assets, be specific, context matters.

Mobile APIs for Healthcare

Next week I am participating in a webinar called Mobile Optimized Healthcare API Programs, from a technical perspective we'll be looking at some interesting integration between Intel's Security Gateway and Mashery. From a healthcare standpoint, the discussion looks at what new kinds of use cases are possible in this ecosystem.

For as much hype that financial services and other sectors get vis a vis security, the healthcare security problem set really is harder than the rest. At the same time, there are dramatic benefits from enabling mobile integration for healthcare, it benefits your number one asset: you. Whether its Fit Bit, Nike+, or just healthcare pros with iPads, mobile is uniquely suited to health and wellness related applications. But what is missing is APIs and integration to deliver on the use cases.

The webinar looks at the following concerns:

• Gateway security patterns to safely repackage legacy data and services as APIs - in short enable access not attackers.
• How to construct, share, and promote APIs to developers using API workshops and branded portals - make it easy for developers to do things right
• How to build a mobile-optimized back end that securely exposes enterprise assets via standard internet protocols (e.g. OAuth & JSON) - what comprises the mobile DMZ? How is it similar and different than a plain, old Web DMZ?

As much as I enjoy middleware, security and protocols, what is most interesting about healthcare is the new types of use cases that bring all the technology together. I guess that is as it should be. Still as a technologist its neat to see after all these years that Web services and Secuity Gateways play a leading role in the leading edge technology deployments today. 

Making a Mobile DMZ is subtly different than old school Web DMZs. Most of the principles remain the same but the implementation is different. In addition, there are new concerns to handle such as session management, token resolution and asynchronous protocols which function differently on mobile apps than web. In the webinar, we'll do a deep dive on these topics and what it might mean for your organization 

Same as it ever was

My latest Dark Reading column is up: 

"Same As It Ever Was

Trade shows, booth babes, and hype aside -- who are you, and what can you do? That is the question. Enter XACML and ABAC" article is here

My RSA Keynote - Information Security That Works Until You Attack It

No they did not ask me to do a keynote (isn't security blogger hall of fame better tho?), but here is what I would say and hey you are getting it before the conference even starts, and you don't even have to get on a plane to hear it.

Let's start with some historical perspective- all countries do it, especially emerging countries, including especially the US. China did not invent industrial espionage. 

After a decade spent warning people about credit card use, the infosec industry is now atwitter about intellecual property. For the most part that is good, the infosec industry is finally after all these years starting to get closer to protecting strategic assets.

Let's put some context around protecting IP. For the most part, IP by itself has limited utility. Don't believe me, go ahead and buy some black market pharma products. Go on now, I will wait, go check your spam folder for 10 cents on the dollar you can buy some versions of your favorite pharma product. No? You're not? There is a lesson here.

(Internet "Percocet" via Pakistan photo courtesy Marcus Ranum)

IP does not equal the ability to capitalize on what you know. For that you need market access not just IP. Linus Torvalds came to the US from Finland, Bjarne Stroustrop from Denmark, and Guido van Rossum from ther Netherlands. Did they come for the world's greatest healthcare? Not so much. To make their ideas into reality it just worked better to be closer a hub. That more than any piece of IP is the killer advantage, the strategic asset. Probably the main reason it works so well is that its an open system.  

Market places make the rules, the US as the largest marketplace is used to dictating terms of agreements with other economies but as China is now the second largest and growing faster than the US there are changes. How worrisome are industrial espionage actions? Worrisome, but its a well worn path to building a competitive economy, one the US trod itself when we stole everything that was not nailed down from the Brits. To me, the emergence of market economies in places like China, India, Indonesia, Vietnam, Mexico,  Cambodia, and Brazil is a huge net plus for the world as a whole second only to (and coincidentally related to) the growth of the Web. For billions of people to progress from starving to a global middle class lifestyle is an amazing thing to see. Does not mean as an incumbent that we should just take industrial espionage and all, but we should put the achievements in the context they deserve.

The math is pretty simple, $400B imports to US, $100B exports to China. They are a core part of the US economic engine and we are to theirs. No China, no iPhone. No iPhone, no China jobs. Military conflict is win-lose, but economic competition is often win-win. IP theft needs to be addressed, but its not the largest danger. Much of that activity arises from movement toward a market based economy. Sure its competitive, but they are playing the same game. However, actors outside the system have potential to disrupt things in a different way because they are not playing the same game. Consider 2008, when the Russians approached China about dumping shares of Fannie Mae and Freddie Mac, this would have effectively shut down the US marketplace. From a Russian viewpoint, it makes sense - they want the price of oil to be high beyond that they are not trading with the US so why not? Why did China demure then? Its a totally different equation from Beijing's point of view, why shut down your biggest customer? Especially when they already owe you over a trillion dollars?

Still as the Chinese official said to Hank Paulson in Beijing in 2008 - "your debt is a tremendous vulnerability" Don't tell that to the Pentagon, though! There are weapons systems to build and to do that you need a threat. In the face of both history and common sense, the DoD does not recognize any strategic vulnerability arising from the US piling up the largest amount of debt the world has ever seen, the fact that much of the debt is owned by China does not seem to register either. As Erskine Bowles puts it - the Defense Department's number one objective is to defend Taiwan from China and they are going to do that with weapons paid for by borrowing money from China. 

It looks like a sideshow and boondoggle to me. The world as a whole is richer and better off with more  and stronger marketplaces. Marketplaces and market place rules should be defended. From a longer term security perspective - our balance sheet must improve, our education system must improve or we won't have a marketplace to defend. Instead we obsess on the short term, there's a trend here.

We have spent 15 years saying that security is about risk management. What we are seeing with IP theft is the output of those risk management decisions. The business side decided to take on some risk by essentially connecting everything to everything else. The security side delivered what controls they could. In short, it did not work.

The trade secrets and IP are guarded by the digital equivalent of tissue paper and fig leaves (fig leaves are for audit purposes). This is not news, this was the plan all along. Take the short term gains of new functionality and deal with the back end consequences later. Well, here we are.

One of the main drivers of the 2008 financial crisis was actors highly incentivized to book short term profits, delegating the long term  effects of those decisions to "risk management." What we got was umbrellas that worked right up until the time it rained. Financial collapse. What we see in infosec with budgets laden with infrastructure security spending and "backstopped" by risk management is information security that works until you attack it.

So people are now concerned with IP theft, we are told how hard it is to protect. A good question: has anyone even tried? As an industry the lion's share of the budget goes into protecting networks and hosts. Excuse me, but I don't think your desktop machines and networks are the IP. The reasons security people defend there is 1) they come from an infrastructure background and 2) its easier. Problem is, neither of that protects the asset.

I do not blame infosec for the current state of affairs, its been an underfunded and undermandated operation since its inception,  I do think infosec habitually misallocates the resources it has. So if you are really, after all these years, finally concerned with protecting information instead of firewall ports, then try protecting data, apps, and identity. That is your IP.

Android Jelly Bean adds a Secure Default for Content Providers

Security requires some thought in design, lots of developer attention in secure coding, but there are gaps that the platform can close that can make the designer and the developers lives easier, setting secure defaults. Default Android introduces a number of ways that companies can unwittingly open up vulnerabilities. Jelly Bean offers a number of security improvements, one of the more interesting is adding a new and important Secure Default which protects Content Providers, aka your data. The setting protects against data inadvertently leaked to other apps. Android's permission model is pretty expressive and lets you set fine grained access control policy. Unfortunately, this means that there are many options and so many enterprises that ship with default settings can expose their data to any other app running on the Android device.

Most developers assume that when they create a database for their Android application that its only able to be used by their app. Unfortunately, this assumption is not valid. The security policy defined in the Android Manifest is the place to check to make sure this is set properly. A developer who sees the following may assume their data is protected:

<provider android:name=”com.example.ReadOnlyDataContentProvider”

    android:authorities=”com.example” />

But for Android 4.1 or prior the Manifest has an insecure default for Content Providers in that if read and write permission are not set (turned off) then its assumed that your Content Provider is readable and writeable by other apps. (note - its unlikely but I can imagine why some app might want their data readable by other apps, why there is a default for other apps to write is something I have never understood). In any case, if you have deployed Android apps its pretty likely that you have the defaults set unless someone specifically turned off read and write acces, so you should check the Android security policy and test the app.

How to check
For yours apps, the best place to start is to review your Android Manifest.xml and check that the permissions are set to disallow access that you do not want, such as other apps reading and writing to your apps databases. On 4.1 or prior this has to be set otherwise the permission is granted.

How to test
There are a variety of ways to test for this, the Mercury test suite for Android gives you a way to see what is running:

               ..                    ..:.
              ..I..                  .I..
               ..I.    . . .... .  ..I=
                 .I...I?IIIIIIIII~..II
                 .?I?IIIIIIIIIIIIIIII..
              .,IIIIIIIIIIIIIIIIIIIIIII+.
           ...IIIIIIIIIIIIIIIIIIIIIIIIIII:.
           .IIIIIIIIIIIIIIIIIIIIIIIIIIIIIII..
         ..IIIIII,..,IIIIIIIIIIIII,..,IIIIII.
         .?IIIIIII..IIIIIIIIIIIIIII..IIIIIIII.
         ,IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII.
        .IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII.
        .IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII:
        .IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

        The heavy metal that poisoned the droid
     
mercury> connect 127.0.0.1

*mercury> provider

*mercury#provider> info -p null

Package name: com.example.myapp
Authority: com.example.myapp.mydataprovider
Required Permission - Read: null
Required Permission - Write: null
Grant Uri Permissions: false
Multiprocess allowed: false

Package name: com.android.alarmclock
Authority: com.android.alarmclock
Required Permission - Read: null
Required Permission - Write: null
Grant Uri Permissions: false
Multiprocess allowed: false

Package name: com.android.mms
Authority: com.android.mms.SuggestionsProvider
Required Permission - Read: android.permission.READ_SMS
Required Permission - Write: null
Path Permission - Read: /search_suggest_query needs android.permission.GLOBAL_SEARCH
Path Permission - Read: /search_suggest_shortcut needs android.permission.GLOBAL_SEARCH
Grant Uri Permissions: false
Multiprocess allowed: false

(truncated)

Probably most Android apps have null permissions set and do not realize that it is the case or the impact of that omission (that other apps can read and write their data). In the case above the example app is set to allow other applications read and write its data. This happens many times with Android apps that contain sensitive data and the companies do not realize the exposure. This is just a snapshot but the Android permission sets are very much like a Purdy shotgun, great for skilled hunters, but also great for committing suicide.

**
Three days of iOS and Android AppSec geekery with Gunnar Peterson and Ken van Wyk - Training dates NYC April 29-May 1

RSA: What to Watch For

Before landing at SFO, vaccinate yourself against hype, what should you watch for? Not threat du jour, not capabilities, watch for integration.

Buyer Education for Avoiding Mobile Dim Sum Surprise Projects

Recently I did a talk at OWASP Twin Cities on building a mobile app security toolchain. The talk went pretty well, lots of good questions. One takeaway, there are many people in many different kinds of companies struggling with how to do Mobile App Sec. The room was sold out, and so it looks like the OWASP Chapter is organizing a repeat talk some time this month, so if you missed it and want to come, stay tuned.

The basics of the talk are around what does an end to end process look like for Mobile AppSec, what tools are involved, and what dragons are lurking along the way? For the three day training that Ken and I do the second and third days are focused on hands on iOS and Android security issues. The first day is focused on a number of issues like how to fix your back end for mobile, what identity protocols might be used, what new use cases and risks does mobile present, and threat modeling for mobile.

One thing that I have seen is that many mobile projects are outsourced, both development and vulnerability assessment work. Of course, companies outsource lots of things these days, but I would say its more pronounced with Mobile. In part this may be due to a small skillset of mobile talent. And maybe also companies figuring out if mobile is a fad that will go away or if they really need to build out a team. To me, the answers for most companies are - mobile is not going away, build your team, seed it with the right mix of folks and train them.

There's another variable at play here. Outsourcing is fine as far as it goes, but its only as good as your ability to select and target the right consulting firms, teams, and work direction. For mobile vulnerability assessment in particular it can be a real hodge podge, some tools and services left over from the webapp security days (do you still need them? yes, but you need others too), many things that apply on one platform but not on another, and a brand new set of use cases for mobile. In all, its a bit like going to dim sum, things whizz by and you point at something you sort of recognize, only after eating do you know if the choice was any good (ok, but who doesn't like pork belly buns though?).

The full three day class is for hands on developers and security people, we talked about making it only for them, but decided to leave the one day option because there are many design, architecture and other issues that extend to other parts of the organization. Whether directing an internal team or brining in a consulting team, education is important to make more informed decisions. One thing we work to build in the training on day one is to make sure people are educated buyers. The mobile app security process and results should not be a surprise. Don't just point at a menu of services, instead learn to identify what tools and services are most vital to your project, and focus on those.

**
Three days of iOS and Android AppSec geekery with Gunnar Peterson and Ken van Wyk - Training dates NYC April 29-May 1

Is SCIM the Shim You've Been Looking For?

Over on Dark Reading, my latest column looks at the incentives driving SCIM. Beyond the technical problems it solves, aligning incentives will be key to determine whether Cloud vendors line up behind it for provisioning is what will drive its success.

Can't We Just

My lateast Dark Reading column is on the three worst words in the English Language- Can't we just...go back through every suboptimal design decision and the prefix to the prevaling argument was probably "can't we just"

New York, New York the City where Newspapers are Targeted?

Richard Bejtlich tweeted yesterday that what was rare about the NYT hack was not that it happened but that they dicslosed so much. On a related point, I think this is pretty rare - in the course of reporting the NYT story, the WSJ disclosed almost as an aside that it had been notified of a breach:

In the most recent incident, the Journal was notified by the FBI of a potential breach in the middle of last year, when the FBI came across data that apparently had come from the computer network in the Journal's Beijing bureau, people familiar with the incident said.

The Journal hired consultants to investigate the matter and uncovered a major breach in which hacking groups—it wasn't clear whether they were working together—entered the company's networks, in part through computers in the Beijing office, people familiar with the situation said. The hackers then infiltrated the paper's global computer system, the people said.

Among the targets were a handful of journalists in the Beijing bureau, including Jeremy Page, who wrote articles about the murder of British businessman Neil Heywood in a scandal that helped bring down Chinese politician Bo Xilai, people familiar with the matter said. Beijing Bureau Chief Andrew Browne also was a target, they said.

The Journal began an investigation to track the cyberspies. The probe watched where the hackers went within the Journal's computer networks, what information they were interested in and how deeply they had penetrated.

A number of computers were totally controlled by outside hackers, who had broad access across the Journal's computer networks, people familiar with the matter said.

The investigation couldn't determine the full extent of the information that was spied on by the hackers, they said. The company's computer specialists erased several hard drives in Beijing last year.

Since the WSJ has been the lead on breaking and covering the Bo Xilai story (the biggest story in China since Tiananmen) this does not seem too surprising. Also, today Brian Krebs tweeted that WaPo has been dealing with similar issues. In addition to the news (which is not all that surprising that these are targets) the semi disclosure of a breach and the way it was done (in the context of another story) seemed unique to me.