Research

I really like that some organizations are getting more open about sharing information regarding their security successes and failures. Prezi comes clean about getting pwned as part of their bug bounty program. They described the bug, how they learned about it, and how they fixed it. We can all learn from this stuff.   Facebook talked about their red team exercise last year, and now they are talking about how they leverage threat intelligence. They describe their 3-tier architecture to process intel and respond to threats. Of course they have staff to track down issues as they are happening, which is what really makes the process effective. Great alerts with no response don’t really help. You can probably find a retailer to ask about that… I also facilitated a CISO roundtable where a defense sector attendee offered to share his indicators with the group via a private email list. So clearly this sharing thing is gaining some steam, and that is great. So why now? What has changed that makes sharing information more palatable? Many folks would say it’s the only way to deal with advanced adversaries. Which is true, but I don’t think that’s the primary motivation. It certainly got the ball rolling, and pushed folks to want to share. But it has typically been general counsels and other paper pushers preventing discussion of security issues and sharing threat information. My hypothesis is that these folks finally realized have very little to lose by sharing. Companies have to disclose breaches, so that’s public information. Malware samples and the associated indicators of attack provide little to no advantage to the folks holding them close to the vest. By the time anything gets shared the victim organization has already remediated the issue and placed workarounds in place. I think security folks (and their senior management) finally understand that. Or at least are starting to, because you still see folks who will only share on ‘private’ fora or within very controlled groups. Of course there are exceptions. If an organization can monetize the data, either by selling it or using it to hack someone else (yes, that happens from time to time), they aren’t sharing anything. But in general we will see much more sharing moving forward. Which is great. I guess it is true that everything we need to know we learned in kindergarten. Photo credit: “Sharing” originally uploaded by Toban Black Share:

Begun, the cloud war has. We have been talking about cloud computing for a few years now on this blog, but in terms of market maturity it is still early days. We are really entering the equivalent of the second inning of a much longer game, it will be over for a long time, and things are just now getting really interesting. In case you missed it, the AWS Summit began this week in San Francisco, with Amazon announcing several new services and advances. But the headline of the week was Google’s announced price cuts for their cloud services: Google Compute Engine is seeing a 32 percent reduction in prices across all regions, sizes and classes. App Engine prices are down 30 percent, and the company is also simplifying its price structure. The price of cloud storage is dropping a whopping 68 percent to just $0.026/month per gigabyte and $0.2/month per gigabyte/DRA. At that price, the new pricing is still lower than the original discount available for those who stored more than 4,500TB of data in Google’s cloud. Shortly thereafter Amazon countered with their own price reductions – something we figured they were prepared to do, but didn’t intend during the event. Amazon has been more focused on methodically delivering new AWS functionality, outpacing all rivals by a wide margin. More importantly Amazon has systematically removed impediments to enterprise adoption around security and compliance. But while we feel Amazon has a clear lead in the market, Google has been rapidly improving. Our own David Mortman pointed out several more interesting aspects of the Google announcement, lost in the pricing war noise: “The thing isn’t just the lower pricing. It’s the lower pricing with automatic “reserve instances” and the managed VM offering so you can integrate Google Compute Engine (GCE) and Google App Engine. Add in free git repositories for managing the GCE infrastructure and support for doing that via github – we’re seeing some very interesting features to challenge AWS. GOOG is still young at offering this as an external service but talk about giving notice… Competition is good! This all completely overshadowed Cisco’s plans to pour $1b into an OpenStack-based “Network of Clouds”. None of this is really security news, but doubling down on cloud investments and clearly targeting DevOps teams with new services, make it clear where vendors think this market is headed. But Google’s “Nut Shot” shows that the battle is really heating up. On to the Summary, where several of us had more than one favorite external post: Favorite Securosis Posts Adrian Lane: Incite 3/26/2014: One Night Stand. All I could think of when I read this was Rev. Horton Heat’s song “Eat Steak”. Mike Rothman: Firestarter: The End of Full Disclosure. Other Securosis Posts Mike’s Upcoming Webcasts. Friday Summary: March 21, 2014 – IAM Mosaic Edition. Favorite Outside Posts Gal Shpantzer: Why Google Flu is a failure: the hubris of big data. Adrian Lane: Canaries are Great! David Mortman: Primer on Showing Empathy in the Tech Industry. Gunnar: Making Sure Your Security Advice and Decisions are Relevant. “Information security professionals often complain that executives ignore their advice. There could be many reasons for this. One explanation might be that you are presenting your concerns or recommendations in the wrong business context. You’re more likely to be heard if you relate the risks to an economic moat relevant to your company.” Gunnar: Cyberattacks Give Lift to Insurance. The cybersecurity market is growing: “The Target data breach was the equivalent of 10 free Super Bowl ads”. Mike Rothman: You’ve Probably Been Pouring Guinness Beer The Wrong Way Your Whole Life. As a Guinness lover, this is critical information to share. Absolutely critical. Mike Rothman: Data suggests Android malware threat greatly overhyped. But that won’t stop most security vendors from continuing to throw indiscriminate Android FUD. Research Reports and Presentations Reducing Attack Surface with Application Control. Leveraging Threat Intelligence in Security Monitoring. The Future of Security: The Trends and Technologies Transforming Security. Security Analytics with Big Data. Security Management 2.5: Replacing Your SIEM Yet? Defending Data on iOS 7. Eliminate Surprises with Security Assurance and Testing. What CISOs Need to Know about Cloud Computing. Defending Against Application Denial of Service Attacks. Executive Guide to Pragmatic Network Security Management. Top News and Posts Apple and Google’s wage-fixing. Not security but interesting. Google Announces Massive Price Drops for Cloud. Cisco plans $1B investment in global cloud infrastructure. Microsoft Security Advisory: Microsoft Word Under Seige. Chicago’s Trustwave sued over Target data breach. Blog Comment of the Week This week’s best comment goes to Marco Tietz, in response to Friday Summary: IAM Mosaic Edition. Thanks Adrian, it looks like you captured the essence of the problem. IAM is very fragmented and getting everything to play together nicely is quite challenging. Heck, just sorting it out corp internal is challenging enough without even going to the Interwebs. This is clearly something we need to get better at, if we are serious about ‘The Cloud’. Share:

Visa, Mastercard, and Europay – together known as EMVCo – published a new specification for Payment Tokenisation this month. Tokenization is a proven security technology, which has been adopted by a couple hundred thousand merchants to reduce PCI audit costs and the security exposure of storing credit card information. That said, there is really no tokenization standard, for payments or otherwise. Even the PCI-DSS standard does not address tokenization, so companies have employed everything from hashed credit card (PAN) values (craptastic!) to very elaborate and highly secure random value tokenization systems. This new specification is being provided to both raise the bar on shlock home-grown token solutions, but more importantly to address fraud with existing and emerging payment systems. I don’t expect many of you to read 85 pages of token system design to determine what it really means, if there are significant deficiencies, or whether these are the best approaches to solving payment security and fraud issues, so I will summarize here. But I expect this specification to last, so if you build tokenization solutions for a living you had best get familiar with it. For the rest of you, here are some highlights of the proposed specification. As you would expect, the specification requires the token format to be similar to credit card numbers (13-19 digits) and pass LUHN. Unlike financial tokens used today, and at odds with the PCI specification I might add, the tokens can be used to initiate payments. Tokens are merchant or payment network specific, so they are only relevant within a specific domain. For most use cases the PAN remains private between issuer and customer. The token becomes a payment object shared between merchants, payment processors, the customer, and possibly others within the domain. There is an identity verification process to validate the requestor of a token each time a token is requested. The type of token generated is variable based upon risk analysis – higher risk factors mean a low-assurance token! When tokens are used as a payment objects, there are “Data Elements” – think of them as metadata describing the token – to buttress security. This includes a cryptographic nonce, payment network data, and token assurance level. Each of these points has ramifications across the entire tokenization eco-system, so your old tokenization platform is unlikely to meet these requirements. That said, they designed the specification to work within todays payment systems while addressing near-term emerging security needs. Don’t let the misspelled title fool you – this is a good specification! Unlike the PCI’s “Tokenization Guidance” paper from 2011 – rumored to have been drafted by VISA – this is a really well thought out document. It is clear whoever wrote this has been thinking about tokenization for payments for a long time, and done a good job of providing functions to support all the use cases the specification needs to address. There are facilities and features to address PAN privacy, mobile payments, repayments, EMV/smartcard, and even card-not-present web transactions. And it does not address one single audience to the detriment of others – the needs of all the significant stakeholders are addressed in some way. Still, NFC payments seems to be the principle driver, the process and data elements really only gel when considered from that perspective. I expect this standard to stick. Share: