Securosis

Research

The end of MDM (as we know it). Or not.

You know a technology is close to the top of the hype cycle when talking heads start calling for its demise. Zeus Kerravala goes medieval on MDM in this NetworkWorld column: I believe we’re starting to see the beginning of the end of the red hot MDM market. More and more network vendors are rolling out solutions for BYOD that make the traditional solutions somewhat of a commodity. Now Zeus is talking about a new product from F5 that basically wraps apps before delivery to a mobile device, to ostensibly provide proper protection, authorization, etc. Hmmm. Sounds a lot like VDI to me. Or remote control. Or the zillion other technologies that are supposed to take devices out of the equation and manage applications and desktops and everything else remotely. Let’s just say we have seen this movie before and device-centric management approaches continue to be alive and well. And I don’t have any doubt that MDM will be here for the foreseeable future to manage the configurations and hygiene of mobile devices. Will MDM be bundled into a broader endpoint and/or IT management suite? Absolutely. Everything is a feature (in time). Though some folks think this is very big market, as evidenced by AirWatch raising $200 MILLION. Not that investors are always right, but that sounds like a market on the upswing. To say it’s the beginning of the end is, well, wrong. It’s the beginning of the beginning. Photo credit: “it’s dead Jim” originally uploaded by Eddie Codel Share:

Share:
Read Post

Attribution Meh. Indicators YEAH!

In addition to all the cycles we spent in our weekly research meeting trying to come up with cool t-shirt ideas featuring APT1, we also spent a bunch of time talking about the real impact of the Mandiant report, and how hacking for the Chinese is just different than what the US (and most other governments) do. I’m pretty sure Rich will do a much more detailed post on this, following up on his great House of Cybercards ideas. But suffice it to say you probably wouldn’t get much of a hearing if you asked the US military apparatus to help figure out what price a Chinese competitor was planning to bid on a big power plant in South America. But the Chinese have no issue with hacking into all sorts of places to assist their commercial entities, many of which are still at least partially owned by the government. But that’s another discussion for another day – one with a lot of beer. I want to follow up on this week’s Incite snippet, Attribution. Meh. Indicators. WIN! on what I see as the real value of Mandiant’s report. It’s not like most of us in the industry didn’t know that the Chinese military was behind a lot of the so-called APT activity. Now we have a building to go visit. Whoopee! I was far more interested to see the malware indicators they found published, if only to see how some smart folks will use that information to help the industry. First send some kudos over to the folks at Tenable, who quickly posted checks you can load directly into Nessus to look for the malware. Part of the reason to do malware analysis in the first place is to be able to search for those indicators within your environment, using tools you already have. This audit file determines possible infections by several of the malware items identified in the Mandiant Intelligence Center Report – APT1: Exposing One of China’s Cyber Espionage Units. It includes checks for 34 of the malware variants identified in Appendix C The Malware Arsenal. The audit file utilizes a combination of registry checks and file system checks to find hosts that might likely be at risk or infected. Wesley McGrew’s students at Mississippi State also got a little gift, in terms of a bunch of new samples to analyze, as described by TechWorld. It’s great to see students able to learn on real world ammo. “Oh, it’s fantastic,” said McGrew, who will defend his doctoral thesis on the security of SCADA (supervisory control and data acquisition) systems next month. “The importance of having malware that has an impact on the economic advantage of one company over another or the security of a nation is priceless. This is exactly what they should be learning to look at.” Not to get all New School now, but access to the malware and associated indicators used in many of these advanced attacks can be instructive for tons of reasons. We can only hope this is the first of many instances where the industry works together to improve the practice of security, as opposed to competing against each other for purely economic gain. Yeah, not sure what I was thinking with that last statement. Share:

Share:
Read Post

Why China’s Hacking is Different

One of the responses that keeps coming up as everyone discusses Mandiant’s report on APT1 is, “yeah, but China isn’t the only threat, and even the U.S. engages in offensive hacking”. That is completely true, but there is a key difference. China is one of the only nations which uses government resources to steal intellectual property and provides it to domestic business for competitive economic advantage. Of the countries that do this (France and Israel come to mind, according to rumor), China is the only one operating at such a massive scale and scope. Most countries engage in cyberattacks for traditional espionage or, on occasion, in offensive actions like Stuxnet designed to support or obviate a kinetic (boom) response. (“Cyber Missiles” as Gal Shpantzer called it in our research meeting today). China is using the power of the government, at scale, to steal from private businesses in other countries and provide the spoils to its own businesses. This is an important difference, and the reason the response to Chinese hacking is so complex. We can’t treat it like traditional criminal activity because there isn’t anyone to arrest. We can’t treat it as normal government espionage because private businesses are both the targets and the beneficiaries. We can’t treat it like war or offensive operations like Stuxnet, since we sort of can’t go to war with China right now. We can’t stick it back to them and do the same thanks to a combination of our laws and the different natures of our economies. We can’t write it off like we do certain other countries which also steal our IP, because the scale is so massive and the consequences (losses) have grown to measurable levels. In other words, China is different, so the potential responses are more complex. The threat is also greater than many of the other cybersecurity (and I use that term advisedly) problems we face – again due to the scope and losses. There are ulterior motives all over the place right now, and little is as it seems on the surface. There are vested financial interests, both at agency budget levels and within private corporations, manipulating the public dialogue. But that doesn’t mean the threat isn’t real, or that doesn’t need a response. We just should avoid being naive about it. (As a side note, in the same meeting today Gunnar Peterson reminded us that China isn’t doing anything that the US didn’t do back when we were a developing nation. I believe his exact words were, “the US stole everything from Britain that wasn’t nailed down”. We are seeing a natural political progression, but that doesn’t mean we should take it up the ….). Share:

Share:
Read Post

Friday Summary: February 22, 2013—Snow edition

I spent half an hour yesterday morning shoveling snow from the walkways around my house. Most of you reading this will think “so what”, as you see snow on an all-too-regular basis. For me, living in Phoenix, snow is something that happens once every 30 years or so. So for the first time in my life I got a snow day – and it was fun. Only 2 inches, but still, a totally alien experience here on the surface of the sun. Better still, the dogs loved it:   Speaking of snow, have you seen these fat bikes? No? Coincidentally Wired did an article this week called Pondering the Point of Snow Bikes While Riding With Wolves. Extra-wide mountain bikes with 4-5” tires, designed for a bike version of the Iditarod. These are the ATVs of bikes and they go over just about everything. I want one! I don’t want one because it snowed here for the first time since, I dunno, disco? I want one for the desert. For one simple reason: there is a lot of sand in the desert. And sand is a lot like snow to a bike. As an example, a few weeks ago I was barreling along on my mountain bike when I dropped into a wash – a dry river for those of you who live where there is rainfall – filled with sand. I went from 15mph to 0mph in about 7’. Needless to say, I was thrown. Several expletives went flying too. Then I bounced. More expletives and a sandy rash. Mountain bikes work great on mountain trails, but they don’t do sand or snow. But there are miles and miles of sandy washes all over the desert. They are natural roadways for all the critters in the area, and provide an easy path through some pretty rough terrain, provided you don’t sink up to your axles. But these big ugly bikes go places bikes have not gone before. And great names to boot – Surly ‘Pugsely’, riding on 5” “Big Fat Larry” tires. Hogback. TRANS-Fat. Neck-Romancer. Beargrease. I was walking by a bike shop last week and they asked if I’d like to try a Salsa Mukluk, so I said ‘Yeah!’ Offering me a bike is a bit like giving an espresso and Corvette keys to a fourteen-year-old. What did I do? Rode it straight into a ravine! The surprise was it went right through – smooth sailing. It just floated over rock and sand. I’m hooked, but that seems like a boatload of money to spend on a bicycle. Then again, since I started working from home, I only put 30 miles on my car per month but 65 a week on the bike. And the mountain bike is way more fun than driving for groceries, so game on! Whenever my wife gives my wallet back, that is. And before I forget, and in case you missed Rich’s tweet from earlier today, Gal Shpantzer (@shpantzer) is now an official Securosis Contributing Analyst! See you all at RSAC next week! On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s Pragmatic Database Security Presentation. Adrian’s DR Post: Restarting Database Security. Rich at Macworld on removing Java from your Mac. Rich talks security geopolitics with Ryan Naraine at Security Week. Jamie at CSO Online on China and cyberware. Favorite Securosis Posts Mike Rothman: The 2013 Securosis Guide to the RSA Conference. Yup, everyone else is going to pick the House of Cards post, so I’ll show a little love to our RSA Conference Guide. But understand that RSA is only an excuse for us to document our trends and key themes for the coming year. It’s really how we see the world of security, with a bunch of vendor booth grids thrown in for convenience. Adrian Lane: The 2013 Securosis Guide to RSA. There are some gems in here. David Mortman: Twitter and OAuth Access Loophole. Rich: Mike was wrong – no one else picked the House of Cybercards, so I’m picking my own damn post. Take that! Other Securosis Posts Everything is a feature (in time). Understanding Cloud IAM: Implementation Roadmap. Incite 2/20/2013: Tartar Wars. Cars, Babes, and Money: It’s RSAC Time. Mandiant Verifies, but Don’t Expect the Floodgates to Open. Network-Based Threat Intelligence: Quick Wins with NBTI. AV’s False Sense of Security (and a possible Mac hack?) Facebook Hacked with Java Flaw. Trust us, our CA is secure. RSA Conference Guide 2013: Security Management and Compliance. Quantify Me: Friday Summary: February 15, 2013. Favorite Outside Posts Mike Rothman: What your culture really says. Thought provoking post by Shanley. I have always under-appreciated culture, but that’s probably why I don’t work very well in a corporate environment. Anyhow, you never know what a company is really like until you are there every day, but these are some good things to consider. About any company, not just those in Silicon Valley. Adrian Lane: Chinese military hacker unit behind US attacks – YouTube. I needed some humor this week! David Mortman: How I Hacked Facebook OAuth To Get Full Permission On Any Facebook Account (Without App “Allow” Interaction). Rich: Colorado’s new CISO is revamping their security program on a $6K budget. As a former Colorado state employee, I had to pick this one. Project Quant Posts Understanding and Selecting a Key Management Solution. Building an Early Warning System. Implementing and Managing Patch and Configuration Management. Defending Against Denial of Service (DoS) Attacks. Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments. Tokenization vs. Encryption: Options for Compliance. Pragmatic Key Management for Data Encryption. The Endpoint Security Management Buyer’s Guide. Top News and Posts The Mandiant Intelligence Center Report is the biggest news in security this week. If you have not read it, stop and read it. It’s good. It’s important. And it’s also important you form your own opinions. Introducing AWS OpsWorks, a Powerful Application Management Solution. I think we missed this last week. Apple releases fixes after its computers got hacked. Guns, Homicides and Data. In my best Keanu Reeves voice: “Wow”. U.S. Ups Ante

Share:
Read Post

Everything is a feature (in time)

In the least surprising news of the day, the guy who sold his start-up, Zenprise, to Citrix, concluded that selling standalone MDM was a tough sell. Even though Zenprise had around 100 developers, it would have been tough to respond to all those demands, he said. “We were feeling pressure from larger enterprises to offer data, secure email, secure browsing, and tie it into other third party and native apps,” he said. “We didn’t feel we had the resources to really deliver a lot of these pieces.” What’s the guy going to say? He took the money and ran and now can throw developers at the problem. That’s his differentiation against the start-ups that remain. And the folks who haven’t sold yet probably want to talk about how innovation stops when a start-up gets bought and how their nimble focus will provide a better solution for customers. Blah blah blah. Over time, pretty much all the MDM start-ups will be acquired and MDM will be integrated into the management stack. It could be the systems management stack or perhaps the security stack. But it will be integrated. We have seen this movie and it always has the same ending. Over time, everything is a feature. Everything. And before you tell me one of the stand-alone companies will go public and remain independent, remember that the day their stock starts trading they begin looking for other stuff to buy to integrate into their platform. As a former boss of mine said, “if you aren’t moving forward, you’re moving backward.” That’s the way technology markets work. Photo credit: “Penn and Teller Get Killed + Pee Wee’s Big Adventure” originally uploaded by Double Feature Podcast Share:

Share:
Read Post

House of Cybercards

We are in the middle of what may be the single most disruptive transition in the practice of information security. Not one of technology, threats, or practices, but of politics. It is occurring in the hallways of capitals and the planning rooms of militaries, instead of in boardrooms of enterprises and startups in California and Massachusetts. This transition will define our priorities for the coming decades, as well as the winners and losers of the future. We, as an industry and collection of communities, need to understand this transition and find our places within it, or risk irrelevance. The president of the United States has placed cybersecurity on par with gun control, tax and education reform, and job creation, in the State of the Union address. It is time to step back, take stock, and understand the implications. We are playing an old game, where we are barely in the stands, never mind on the field.   First, let’s take a moment to look at the buildup to this point. Major security incursions, even at the nation-state level, have been occurring for decades. But beginning in 2010 with Google’s revelation of the Operation Aurora attacks, followed up by disclosures that dozens of technology firms believed they were targeted and attacked by China, we have seen a flood of major attack disclosures – RSA, Stuxnet, Lockheed-Martin, and the New York Times, just to get started. Some here in the US, some perpetuated by the US, but all focused on the cat and mouse game between world powers, not merely banks and criminal hackers. The revelation of these attacks and its timing is more significant than the attacks themselves. Defense contractors don’t reveal they have been breached without a good reason. Seven recent events best illustrate the nature of the impending shift. The first, clearly, was the State of the Union address. The second followed closely with the President signing an executive order on cybersecurity. This was preceded by revelations that a classified National Intelligence Estimate was issued, naming China as the top cybersecurity threat. Combine these three events with the failure of Congress to pass a cybersecurity bill (due to competing lobbying efforts) and the European Commission proposing new cybersecurity legislation, and it becomes clear that the politicians and lobbyists are fully engaged. This was accelerated dramatically this week by Mandiant’s release of specific intelligence tying China to a massive attack campaign, and the White House’s release of the Administration strategy on mitigating the theft of U.S. trade secrets (PDF) strategy position paper. And let’s not forget that the US government apparently used cyberarms to attack Iran’s nuclear program, instead of allowing Israel to launch kinetic weapons. Cybersecurity is now operating fully at a geopolitical level. (As much as you might hate the word ‘cybersecurity’, that battle is long lost, and fighting it is the quickest way to the kids’ table). That means future regulations, and massive amounts of government cash, will be fought over by lobbyists and special interests; in national capitals and on the screens of Sunday morning talk shows. Although we may be the professionals with the most experience in security, that doesn’t buy us an inch of credibility or influence in this process. And I mean ‘buy’ in the literal sense. Just ask teachers how much influence they have over education legislation – and they even own a union. Security standards, disclosure laws, information sharing, criminal laws, and cyber arms control (vulnerability research and exploit development) are all likely to be regulated in one way or the other in the coming years across different nations. Many of these have the potential to directly affect how we do our jobs, and the direction of federal funding will influence what tools and technologies succeed in the market. It doesn’t matter if you are a vendor, researcher, or practitioner – the only way to influence this process (if you care) is to play the political game. Engage with politicians, hire lobbyists, and start making the rounds in the halls of government. Understand that other vendors or “industry representatives” won’t necessarily represent your needs, and are focused on their own narrow interests. Your opinion, however logical, doesn’t matter unless you have a lever to pry decisions in your direction – the effective ones are all built around large wads of cash. Those of you in the vendor community, in particular, need to realize you are up against defense contractors looking to maintain profits as two wars end. And they can no longer afford to perform poorly in the commercial market. If your CEO doesn’t have a travel schedule that involves Dulles or Reagan, you are already losing. You don’t need to be a cynic to know it’s the toughest game in history, and we just landed in the middle. Share:

Share:
Read Post

Twitter and OAuth Access Loophole

Brent Simmons brought up a great issue regarding the Twitter hack and the way OAuth works. Twitter’s notification to users: Twitter believes that your account may have been compromised by a website or service not associated with Twitter. We’ve reset your password to prevent others from accessing your account. And Brent’s response: … would lead a normal person to believe that resetting your password would prevent other people from accessing your account in any way. But it’s not true, not if they’ve already accessed your account. D’oh! I am betting most of you, like me, missed this subtlety. The issue is that if an attacker got to your account before the password was reset, the Twitter OAuth token they created for their own access will persist. That means that, despite a password reset, the attacker keeps access. Note that this is not intrinsic to OAuth – it is the choice in how the application platform (in this case Twitter) implements tokens. Some services, like Facebook, expire tokens by default. Twitter chose not to, but it’s not clear to most users (I certainly missed this point) that they should reset all Twitter apps if they are worried about a compromise. Tokens change the way access works behind the scenes, and it’s not always clear how. In fact many application developers can specify ‘lifetime’ access tokens, overriding the application usage of OAuth if they choose. This is not a straightforward issue – more correctly, as David Mortman pointed out: “It’s a complex problem … actually, no, it’s a complex thought process due to the fact that we poorly educate users on the issues and what they need to do”. If you got the email from Twitter, we advise you to go into the application sub-menu of your Twitter account and revoke any applications you see there. I understand when that retyping ginormous passwords in for every app on every mobile device is a pain, but it’s the only means we are aware of to invalidate old tokens and force re-authentication with the new password. Update Nishant Kaushik goes into much more detail at Talking Identity. Share:

Share:
Read Post

Understanding Cloud IAM: Implementation Roadmap

IAM projects are complex, encompassing most IT infrastructure, and can take years to fully implement and roll out. So trying to do everything at once is a recipe for failure. So we turn our discussion to how to deploy IAM without biting off more than you can chew. We will discuss how to approach building an architectural schema for your particular organization, based on the cloud service and deployment models you have selected. Then we will create different implementation roadmaps depending your project goals and most critical business requirements. The last post described three common use cases for Cloud IAM: Single Sign On, Provisioning, and Attribute Exchange. The good news is that the process of creating a deployment roadmap is largely the same, regardless of which use case you choose. But every customer’s environment and priorities are different, so delivering on these use cases requires a slightly different implementation and project plan for every customer. Implementation roadmaps start with a system design, and then describe the series of steps needed to deploy the solution in phases. The roadmap should begin with the assumption that there will be a lot of catch-up to play, because most organizations do not have a cohesive identity strategy. In fact there is rarely a dedicated identity team, much less a VP-level position supporting IAM as a critical function. It is mainly an exercise left to unlucky souls who zigged when they should have zagged, and as a reward got the title “IAM Architect” tacked onto their existing laundry list of responsibilities. These people, overwhelmed by complexity, punt and outsource the problem to consultants. The predictable result is a patchwork of partially implemented tactical solutions. We started this post in Debbie Downer mode because a) you are unlikely to successfully solve the problem without appreciating its magnitude, and b) your plans need to take the current state of IAM in your company into account. With these considerations in mind you can realistically decide which problems to address first – taking into account the available organizational, process, and technology support. Try not to think of Cloud IAM as yet another point IAM solution. The total rethink of IAM prompted by cloud computing offers more flexible and effective solutions than have been available over the last decade. So we urge you to adjust your thinking, consider where identity solutions will be useful, and figure out how one of the cloud architectures we have described can extend your capabilities. Let’s drill into the use cases and focus specifically on the ‘actor’ roles, mapping how these actors interact with one another. We touched on several common roles – Identity Provider, Relying Party, Attribute Provider, Authoritative Source, and Policy Decision Point. A good first step in outlining your strategy is figuring out which servers will fill these roles. Second, determine how the parties will communicate and what information they need to exchange. This process map should provide a good understanding of how all the pieces work together, which feature will be important, and what data needs to be available. Your map should include constraints imposed by these system actors – for example, the cloud application Relying Party likely accepts a limited set of identity tokens. Understanding limitations early is just as important as knowing what the feature requirements are. Communications are often taken for granted. It’s that Internet / cloud thing, so it must all be HTTP, right? Well, mostly, but not always. It could be API calls, or HTTP communications might rely on supplementary SSL/TLS for security. To avoid surprises and last minute fire drills over firewall rule changes, trace out the necessary end-to-end communications and protocols. Often there are requirements for non-HTTP protocols buried deep beneath the surface – this is particularly common for provisioning. Security issues crop up due to information leakage, session security, spoofing, and other concerns, so it pays to examine the dialogue between parties and specify secure communications during the design phase. As we alluded earlier, the state of play in IAM is frequently a hodgepodge of stuff, with various components bolted on to solve specific problems that popped up at various times. This forces some IAM projects to burn considerable calendar time on data cleanup and transformation. Again, the starting point is a schema for identity and accounts used for cloud access decisions. It is critical to understand what work needs to be performed, and to identify the most difficult integrations. From there the order of implementation is heavily influenced by how much of a mess you need to clean up. We caution that simple is best – do not try to build a be-all end-all uber-identity-schema. Even if schema definition is straightforward, enforcing it across multiple backends rarely is. It is important to review data sources, ensure they work with the identity schema, and establish a process for cleaning up and dealing with conflicts. Realistic expectations are your friend – be conservative about what can be achieved, and don’t get too aggressive out of the gate. Do not copy your feature list from a vendor’s capabilities document and assume everything will “just work”. Be conservative; less is more. One final word on building your schema: You need to understand not only how things work, but also what happens when they don’t work. Identity and access have ugly failure modes; when they break people notice and you will get the blame. Plan for failures at each node within your schema, and understand the side effects when each service goes down; are there interesting complications if two go down at the same time, or in the worst possible sequence? Can your system withstand periodic brief outages? You need to conduct sufficient testing to discover issues before production deployment. But most security and QA tools are not well suited to testing IAM. So for each use case you deploy, build out a set of test cases (both positive: this should work, and negative: this should fail) to ensure that what you are promoting works end-to-end. These tests may influence your deployment timeline as

Share:
Read Post

Incite 2/20/2013: Tartar Wars

5 years. It doesn’t seem that long. It seems like yesterday I was on the phone screaming at the office manager of my (previous) dentist. He told the Boss something and then backtracked on it, and I had to write a check to fix the problem. I had just dropped my dental insurance and that little optional procedure wasn’t going to be covered as he had said it would. I told them to pound sand, which was a good move – I settled for perhaps 30% of the cost 18 months later, before it went to collection. But at the same time, I dropped the dentist. He violated my trust and that was that. Though I seemed to have forgotten to find a new one. This was pretty uncharacteristic – I had been going every 6 months for cleanings since I was a kid. I had a handful of cavities but my teeth were in great shape. But none of my pals had a dentist they liked, so I kind of forgot about it. No big deal, I’ll find one. Sooner or later. And one year became two years, which then turned into 5. Turns out a friend of ours recently moved his dental practice around the corner, so I had a new guy I trusted. Combined with the call I got last week about the Boss needing a root canal (she hadn’t been in 5 years either), I knew it was time. The fact that Arthur Treacher’s famous Tartar Sauce was caked onto my teeth notwithstanding, it was time to pay my penance and go in. First of all, my guy does it right. Most folks hate the dentist, so he staffs his office with the nicest people on Earth. I wasn’t in a great mood, and within a minute they had me smiling and chatting it up. That is nothing short of amazing, given my general state of grumpiness. They were all super helpful and by the time my hygienist got through my health forms and X-rays, I knew her life story. Then she proceeded to sandblast my teeth for 35 minutes to clean them off. Evidently a lot of crap sticks to your teeth over 5 years. Yes, it was uncomfortable. But penance is never pleasant. At least she gave my gums a rest halfway through. A little polish, a bunch of floss and I was ready to meet with the big man. I was a little apprehensive because I figured with all the plaque build-up my teeth must be a train wreck. He cracks some jokes and then pokes and prods with his tools. Oh crap, here it comes… 3 new cavities and about 5 other areas to watch. Wow, it could have been a lot worse. I guess all that fluoride my Mom made me take when I was a kid worked okay. Of course he did mention my habit of grinding my teeth. Evidently that’s my subconscious way of dealing with the stress and paranoia of being me. Though it’s not causing too much damage right now. So I’ll need to be more aware and cut it out. Evidently I need to find another stress outlet. Maybe some vendor will have a nice squeeze toy or punching bag to give away at the RSAC next week. He also made an impassioned plea for me to floss more. I hate flossing. I mean hate. But hey, if it means I won’t have to get more fillings next year and the year after that, then I’ll just do it. I have declared war on tartar, and that damn floss is a key armament in my arsenal so I have no choice. A man’s got to do what a man’s got to do. –Mike Photo credits: Thong Lor dentist originally uploaded by Mrs Hilksom Heavy Research We’re back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. Network-based Threat Intelligence Quick Wins with NBTI Following the Trail of Bits Understanding the Kill Chain Understanding Identity Management for Cloud Services Architecture and Design Integration Newly Published Papers Building an Early Warning System Implementing and Managing Patch and Configuration Management Defending Against Denial of Service Attacks Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments Pragmatic WAF Management: Giving Web Apps a Fighting Chance Incite 4 U Attribution. Meh. Indicators. WIN! With the Mandiant APT1 report making mass market waves yesterday (Rich covered it, and Adrian has some thoughts below), attribution is now big news. John Sawyer discussed this on Dark Reading last week, of course quoting the Mandiant PR machine. His point is that attribution is hard and the kind of profiling and work done by Mandiant is required to really be sure who a specific attacker is. And although Jeffrey Carr brings up some decent points about considering other actors before attributing (though he has no way to know to what degree Mandiant considered competing hypotheses), the reality is that Mandiant did the work and showed with reasonable certainty the specific actor is who they think it is. But ultimately will this do anything besides force the attackers to change tactics and reconsider their OpSec? Probably not, but that misses the point. What will be most valuable is the hundreds of indicators published with the research. Kudos to Mandiant for that. – MR Siri, build me a cloud: If you have been paying any attention to anything I have written or said on cloud security the past couple years (something I’m definitely not about to assume), you know I’m a huge fan of cloud automation and software defined security. We really cannot manage cloud security manually, and need to take lessons from the whole DevOps movement to become much more efficient in protecting cloud instances. One thing I have mentioned frequently is use of tools like Chef and Puppet for configuration automation (in the

Share:
Read Post

The 2013 Securosis Guide to RSA

We have to admit, this year’s Securosis Guide to RSA is a little over the top. A lot over the top. You know how sometimes you start something, and then you start amusing yourself, and things go just a little too far? This is like that, except we loaded it with a ton of useful information… and no alcohol was involved. That includes key themes, breakdowns of trends and vendors by major coverage areas, and a version of the show floor vendor list with websites so you can look them up later. We hope you find it useful. From the introduction: Over the 15+ years we’ve been going to the show, it has gotten bigger and harder to navigate as the security industry has grown bigger and harder to navigate. This guide should give you a good idea of what to expect at the show – laying out what we expect to be key themes of the show, diving into the major technology areas we cover, and letting you know where to find us. Like last year, we have done our best to break out vendors by tech areas, and added a more comprehensive vendor list including web addresses, so you track down your favorite vendors after the show, since they probably won’t be hammering your phone 10 minutes after you get back to the office. We’d also like to thank all our Contributing Analysts – David Mortman, Gunnar Peterson, Dave Lewis, and James Arlen – for helping keep us honest and contributing and reviewing content. And we definitely need to acknowledge Chris Pepper, our stalwart editor and Defender of Grammar. Enjoy the show. We look forward to seeing you in San Francisco. Rich, Mike and Adrian The 2013 Securosis Guide to RSA (PDF)  Share:

Share:
Read Post
dinosaur-sidebar

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.