1 Raindrop

Upcoming Talks and Training

This month, I am teaching a course on Fundamentals of Secure Coding July 13-14 in Minnesota.

Hoff and I are leading a workshop at the Cloud Identity Summit on Security in the Cloud. The folks at Ping Identity put up a video with Hoff explaining the workshop. I am really looking forward to this, as Hoff says its a practical soup to nuts look at Cloud Security from infrastructure to metastructure (identity, policy, audit, BGP, DNS, SSL) to infostructure (apps and data).

Then I am speaking at Cloud Identity Summit on Cloud Identity: Yesterday, Today and Tomorrow.

Fear the Boom and the Bust - Keynes v Hayek rap

Fantastic work by econstories.tv, manages to 1) capture one of the main economic stories of the day 2) get to the heart of both sides of the argument 3) be highly entertaining. That is no easy task

BP - a lesson in monitoring

 Ned over at the Barking Seal uses the recent Macondo example to illustrate  what Richard Bejtlich calls Building Visibility In:

 Steven Newman, the CEO of Transocean, said during a recent senate hearing, “There is some delay in the replication of our data, so our operational data, our sequence of events ends at 3 o’clock in the afternoon on the 20th. And so the VMS system, along with the logs of the VMS system, would have gone down with the vessel.”  The blowout and massive explosion happened at 10, taking eleven lives and seven hours of VMS data to the bottom of the ocean. Representative Bruce Braley from Iowa followed up with “So you have no mirrored backup data device so that that information is recorded at some other location than on the rig itself?”.  Newman replied, “We do not have real-time off-rig monitoring of what’s going on on the vessel”.

In the class I teach for developers to build Audit Logging into their applications, we build on the good work that's been driven out of PCI DSS - namely the spec created demand for best of breed audit logging tools - a competitive marketplace. So now there are legions of tools in the space, at a relatively decent cost. People in security love to slag off PCI, but you know what - if you went back 8 years pre PCI, you would not find a market for audit logging tools, it would have been two guys in a basement in West Texas. Now there's a nice niche market, and real tools.

But as always, the tools only go so far and so its necessary to build the audit loggers into the code so that you can make the audit log manager useful. It would be nice if you had consistent event models, types and reporting as well. What we spend a lot of time on in training is - placement of the audit logger.

Location, Location, Location

Think about about a three tier architecture. Now think about an attack - let's SQL injection. What does SQL Injection look like at the presentation tier? Probably not much HTTP request, possibly with some funky characters, but its likely a "nothing to report" situation. (Yes I know I am glossing over the possibility of  the input validator catching it up stream, but bear with me) A little lower in the middle tier, mapping to business objects and applying business rules, it might trip a wire, but even there maybe not. Then at the data tier, formatting the query the logger may finally catch an exception or see something malformed and be able to 1) identify it as such and 2) report it. 

Then we do other exercises trying to audit log CSRF, XSS and other areas. In each case you will likely find that where in the code you choose to locate your audit logger is just as important as the events you are looking to gather.

Richard Bejtlich mentioned the topic of monitoring in a post, where he was posed a simple question (always the hardest kind) by a CISO Can you tell me when something bad happens to any of my 100 servers?"

Its worth reading Richard's whole post, but the part I want to include here is this part of his answer:

• Can we collect host and application logs?




• Do we have instrumentation in place to collect data for the servers in question?


• Are the logs standard? Nonstandard? Obscure? Binary?


• Are the logs complete? Useful?


• What volume of data do we need to analyze?


• What retention period do we have for this data?


• What laws, regulations, or other restrictions affect collecting and analyzing this data?

Its a good list, and I would add a few more - 

• Where in the stack is the instrumentation?
• What is the event model? What event types are visible?
• How are the events, requesters and providers correlated?
• What event payload types are used?
• How are transactions and sessions handled?
• How are the identity information and authorities handled?
• What service interfaces, databases are monitored?
• Can you correlate identity providers, relying parties that vouch for transactions?

One of the smartest clients I have asked me to put together the Audit Logging training class (rule 1 in consulting - listen to your clients, especially the smart ones). He had been down the PCI road, had tooling and a basic event model, but needed concrete ideas, examples, patterns and practices on how hands on developers could integrate the audit logging beast into their apps. I put the class together and was leery that even though it seemed important topic, that anyone else would care, but it turned out to be a popular class.

One thing I have learned from reading Richard Bejtlich and studying real world security (ever lose a credit card?) responses, is that access control can only get you so far. When the stuff hits the fan its all about monitoring and response. Its hard to get the mindset to build security into systems up front and harder still to get people to think about building visibility in, but that's the best shot at mapping auditable events to the customers, users, identities, apps and data that you care about. To those about to audit log, we salute you.

Google and Baidu

 Last January, Google announced it had a new approach to China and eventually moved its servers to a Hong Kong address. The main destination for the search consumers that Google left behind has been Baidu. In fact Baidu is now aiming for 79% market share (I guess they don't understand the 80/20 rule yet in China)

Search Engine	Q1 2010	Q4 2009
Baidu	64%	58.4%
Google	30.9%	35.6%
Sogou	0.7%	1%
Soso	0.4%	0.7%
Others	4%	4.3%

This growth translated into a great quarter for Baidu

Revenue climbed 60% to $189.6 million. Earnings soared 165% to $2.02 a share. Analysts figured that the company would earn just $1.50 a share on $180.1 million in revenue.

Better yet, the company is targeting $268.1 million to $274 million in revenue for the current quarter -- 67% to 70% ahead of last year's showing. Now that's accelerating sales growth! Analysts figured that revenue would only grow at a 49% clip, to $240.1 million, for the next quarter.

Definitely seems like the Chinese search space is a good place to do business.

 

Now, five months is not that long a time in the stock market, but I thought it would be worth checking the shares of Google and Baidu since Google's announcement of their new approach to China. So compared BIDU (up about 80%) and GOOG (down around 20% (hey maybe they do get the 80/20 rule in China!)). Since they trade on different markets I included both the S&P 500 index for US and the Hang Seng Index for China. They are both down slightly for the year (then again we knew that), but GOOG is actually underperforming both indices as well. 

 
Not sure how much of this is attributable to Google's China policies, but it is interesting. Granted Baidu has more room to grow with a $23B market cap compared to Google's battleship-like $150B market cap, but still click the above chart - those are starkly different (albeit short term) results for two competing companies.

What to do

I am not sure you can call Google's stock cheap by most metrics, but the current P/E is only 21 (Salesforce.com is 144(!), Rackspace is 62, Amazon is 51) and the forward P/E is under 15. That is not super pricy for a company with $6B in free cash flow and I think we'd agree that outside of China a pretty good moat. In addition to China, one other reason Google is cheap relative to its sector is that they have a history of mistreating shareholders. They have used dark arts like repricing options and other shenanigans. But still when you line them up next to Salesforce, Rackspace, Amazon, and others, they look to be selling at a good price. 

Did I miss anything? Any other comparative companies that should be included? How much of the underperforming the index is due to China? WIll that be a long term drag on earnings? Do they have any other rabbits that they can pull out of their hat?

Messaging with Payments

iang posts on the right permutation of message and payments

i. we want more transactions,

ii. payments business derives from trade …

iii. trade is really messages, with a payment tacked on,

iv. we have a payment system, built on great messaging principles,

v. we just need to switch the emphasis of our system architecture a little, to:

messaging-with-payments, not payments-over-messaging.

I've seen this many times, its a result of paying too much attention to functional requirements (what dos it have to do to complete business goal) and not enough to non-functional architectural requirements (how does the system as a whole work). You will arrive at different solutions if you work in this order.

Google's Oil Spill

Google's Macondo Street View team cannot seem to get the right combination of top kill or cap to fit on its MAC spillage. Your MAC is not like a house number (which everyone knows and are used for many purposes), MAC address is scoped to one use. There's no harm in collecting MACs, the hell you say, there's a number of evil emergent cocktails that can come out of this. Its not so much the MAC itself, its the association of the MAC and the gelocation and time - combining something unique like MAC with geolocation.

This looked like a rogue team (or as Google put it last week a "rogue software engineer") until this shocking announcement that Google is patenting (emphasis added) - "The invention pertains to location approximation of devices, e.g., wireless access points and client devices in a wireless network."

It seems pretty obvious that any number of permutations of problems  will result by combining private client data and geolocation. Maybe Google books should scan a copy of J.C. Cannon's book "Privacy: What Developers and IT Professionals Should Know" and Stefan Brands Primer on User Identification.  In both works you see the risks of promiscuously mixing identification cocktails and the unexpected leakages that result. In addition, what does benefit to the user who is being spied upon does all this spying create?

Increasingly, we are faced with questions like - do I want to turn my whole life over to Apple and their shiny happy Disneyland experience and be utterly locked in down to the hardware/data level; or Google who will spy on me with the NSA and then sell me ads? These choices are like being asked which Menendez brother do I prefer.

Arian Evans on Scanning Web Services

Arian Evans posted some thoughts of the difficulties of scanning Web services

Let's be blunt here gentlemen: scanners are between 85% ineffective to utterly useless for testing web services.

Scanner Success Scenario: The only scenario where scanners work reasonably well is when a RESTful web service is bound to an identical UI, as some modern frameworks automatically provide (say, Drupal or Ruby on Rails). This way you can trace data, output, and behavioral changes via monitoring the UI. However - this does not ensure that the controls (like AuthC/Z) test are the same between the API and the UI.

He enumerates the major problems with Web services - they are used for many things, "standards" are all over the map, authN/authZ and more. In terms of actionable items:

I recommend people perform the following on web services:

+ Threat modeling, especially on B2B or WS to WS, to make sure you understand your attack surface

+ Human source-code review, to review your controls implementation particularly AuthC/Z

+ Run-time analysis to see how the running engine handles input thrown into it

+ A customized source-code scanner might be useful here for repeated testing over time

Threat modeling is an important part of any software security program and this is particularly true in Web services. Arian alluded to why this is so - Web apps have a pretty straightforward deployment model - Web server and Web browser. In Web services there's nothing but permutations, really the only reason you write a Web service in the first place is because the normal webapp model does not work for what you are trying to do. This has the benefit of solving some neat problems, but it has the side effect of being highly customized in design, architecture and deployment. 

People write Web services for the "everything else" kind of cases whether its technology integration (Java, .Net, Ruby), B2B, connecting to mobile, connecting to legacy, message queues, and so on. Then there is the richness of data types in XML/XSD, the different types of message exchange patterns - Request/Response, pubsub, different transport protocols, byzantine security protocols, and finally the small matter of what problem its trying to solve. There are so many ways to implement Web services it makes the Balkans look consistent and uniform. So this makes Threat Modeling essential to understand the data flows and message exchanges before you can make sense of what the security levels can and should be, what the scan targets are and what an acceptable outcome looks like. 

Before you can do that you need to understand what the service is being used for. Chances are its something non-standard, because otherwise it would not be a web service in the first place.

Web and Wireless in the World

One anti-pattern I have noticed working on mobile projects is that going in people often assume that you have a web app and web services and to make them mobile ready you simply add a mobile interface. But what ends up happening is that the overall architecture changes, layers are added to manage references, optimize content, and other tasks. But this is just the server side of the equation.

The most recent work by Timo Arnall elegantly shows the other side.

Wireless in the world 2 from timo on Vimeo.

Are there security and privacy implications here? Ya sure, ya betcha.

There's more linkage of web resources to physical world exploration by Timo Arnall here:

The web in the world

View more documents from Timo Arnall.

“Everything we think of as a computer today is really just a device that connects to the big computer that we are all collectively building” -Tim O'Reilly

As I described in my keynote at last year's mnemonic RISK Conference, Web security models and the Clouds they enable need to extend beyond subjects (user/browser) and objects (web URI) to include mobility and networked participants' context. And it must be done dynamically at runtime. There is no static mapping or representation, instead there's references, scope and decision points, which is about the best argument I can think of for Claims/Assertion based access control

Looking for a Web-time Consigliere to Avoid Creeping Security and Privacy Vulnerabilities

 There's an old saying that at any given time the current politicians are never so bad that if you live long you won't want to see them come back and replace the current crew. Likewise, in the 90s Microsoft was pretty universally viewed as about the biggest problem in security. Now we have web companies like Facebook and businesses that run web front ends like banks that are hosing consumers in ways Microsoft never did. (Note - just heard a great radio commercial for GoToMyPC - "Use GoToMyPC its just as safe as internet banking" couldn't have said it better myself! I guess it beats "GotoMyPC Considered Harmful" anyway).  

The latest abuse has been dealt to consumers via Google, Kim Cameron has a series of must read posts, that describe Google's willful violation of both the third (Law of justifiable parties) and fourth (Law of directed identity) Laws of Identity. In Misuse of network identifiers was done on purpose, Kim identifies some of the core issues:

Yet Google consciously decided to abscond with, tabulate and monetize the identities of our personal, business and home devices.  The identifiers are persistent and last for the lifetime of the devices.  Their collection, cataloging and use is, in my view, more dangerous than the payload data that was collected. Why? The payload data, though deeply personal, is transient and represents a single instant.  The identifiers are persistent, and the Street View WiFi plan was to use them for years.  

Let’s be clear:  Identity has as much to do with devices, software, services and organizations as with individuals.  And equally important, identity is about the relationships between these things.  In fact identity can only be adequately expressed through the relationships (some call it context).

When Google says, “MAC addresses are a simple hardware ID assigned by the manufacturer” and “We cannot identify an individual” using those “simple hardware IDs”,  it sounds like the devices found in your home and briefcase and pocket have nothing to do with you as a flesh and blood person.  Give me a break!  It reminds me of an old skit by “Beyond the Fringe” where a police inspector points out that “Once you have identified the criminal’s face, the criminal’s body is likely to be close by…”  Our identities and the identities of our devices are related, and understanding this relationship is essential to getting identity and privacy right.

One great thing about blogging is you find out when you haven’t been clear enough.  I hope I’m making progress in expressing the real issues here:  the collection of device identifiers was purposeful, and this represents precisely the kind of ”systemic privacy design flaw” to which Ben refers.  

It bothers me that this disturbing systemic privacy design flaw - for which there has been no apology - is being obscured through the widely publicized apology for a completely separate and apparently accidental sin.  

In contemporary networks, the hardware ID of the device is NOT intended to be a “universal identifier”.  It is intended to be a “unidirectional identifier” (see The Fourth Law) employed purely to map between a physical machine and a transient, local logical address.  Many people who read this blog understand why networking works this way.  In Street View WiFi, Google was consciously misusing this unidirectional identifier as a universal identifier, and misappropriating it by insinuating itself, as eavesdropper, into our network conversations.

Because of connectivity, poor engineering and just lots and lots of dollars, data and digits, I think we're at the beginning of any number of companies that are in a position to deal more harm to consumers' security and privacy than what people were worried that Microsoft would effect in the 90s. 

What's more worrying is that Microsoft for all its historical baggage operated under a microscope. Everyone was watching for them, waiting for them to pull some Dr. Evil move. They were called to account.

But go back 5 or 10 years, Facebook is treated as a place to store photos and hang out with friends. Google is a search engine and hey(!) they now have maps! You hang up a slogan like "Don't be Evil" or whatever and you get a free pass. Only later do people figure  what the problems are, the vulnerabilities creep in and by the time you realize they are there its too late - all your data, friends, MACs whatever are uploaded. With Microsoft in the 90s consumers were on guard, ready to deal with issues (even if they had minimal control), but in the Web we back into security and privacy problems, not realizing it.

I think you can look at what is happening and see that things have changed a lot on the Web, what got you here to this point is not what you need to get there going forward. We're sowing the seeds for an identity oil spill.

Remember when Michael Corleone dismissed Tom Hagen -"You're not a wartime consigliere, Tom. Things may get rough with the move we're trying." Expertise in one area don't necessarily carry over and can sometimes make things worse. Maybe its time to say to the various web platforms out there that are overstepping in harmful ways - "hey you were a great social networking site, search engine, whatever but you're not really a web-time consigliere. Things can get rough out there - and your promiscuous collection of context and data can come back to bite us."

Update 6/4: Google says they screwed up and will turn over intercepted data. They blamed a "rogue software engineer" for the issue.

Limits to Everything

One current conversation in infosec is that the US military and intelligence organizations can help the private sector deal with their current infosec woes. There may be some areas where those organizations are more advanced than the private sector, but as always in security there is the question of context. How applicable is the military and intel domain expertise to the private sector? Here is a good example from Edward Luce of that from another ongoing saga BP's oil spill:

Mr Obama is already under pressure to “just do something” – even if it sometimes seems it is merely to give the impression of doing something. At the weekend, Colin Powell, the former secretary of state and supporter of Mr Obama, even suggested applying what sounded like the wartime “Powell doctrine” of defeating your enemy with overwhelming force.

Without specifying what precisely he had in mind, Gen Powell urged Mr Obama to launch a “comprehensive total attack” on the spill with “decisive force”. But as Mike Mullen, the chairman of the joint chiefs of staff, hinted on Monday, militarising the response would raise expectations beyond the capacity of the US military to meet them. Incarcerate all BP personnel, perhaps? Nuke the well?

Sure the Navy has much more experience in undersea operations than oil majors, but how much will carry over? As the Chinese say "talk doesn't cook rice", the only experience that's going to matter now is ability to operate at 5,000 feet *and* capping the well. Of course, its not a binary thing there's plenty of places to imagine public/private joint efforts. The current attempts are using robots which is an area that's a great example. A company like iRobot does about 2/3 of its works for DoD and 1/3 making Roombas and Scoobas that consumers love. Of course, I like Luce's conclusion

There is another avenue available. While straining every sinew to contain this disaster, Mr Obama could seize the chance to overhaul America’s energy debate.

In the same way, why limit our thinking on infosec to existing capabilities of public and private sector? Why not treat the infosec issues we are seeing as an opportunity to build a better system? Why be constrained by a design well past its sell by date?