Research

A good update at Threatpost: Their new exploit beat a fully patched Windows system running IE 8, the same version of the browser exploited by malware used in watering hole attacks against a number of political and manufacturing websites, including the Council on Foreign Relations in the U.S., and Chinese human rights site Uygur Haber Ajanski. More motivation to move to updated browsers, as difficult as that often is. I’m really hoping IE 10 can break this cycle a bit (and I bet Microsoft is as well). Still, IE 8 is only a bit over 3 years old, which isn’t all that ancient compared to XP. If you are stuck on old browsers, and have the capability, take a serious look at EMET. Kills most of these attacks cold. Share:

The Washington Post sort-of covers honeypots, but mixes in national security issues. But one paragraph is out of place, because the article doesn’t really cover strike-back: Those actions probably would violate federal law, FBI officials said. The bureau also warns that the use of deceptive tactics could backfire – hackers who identify data as bogus may be all the more determined to target the company trying to con them. TL;DR: good guys are baiting systems with data, not just standing up honeypots. Then they can alert any time anyone touches the bait – there are a bunch of ways to do this. We talked a little about this last year. And yep, we are implementing it ourselves in a few places – no special security products needed. Don’t ask us where. Share:

For the short version, read Rob Graham at Errata Security. Google detected someone attempting a man in the middle attack using a certificate issued in Turkey. TURKTRUST issued two subsidiary Certificate Authority certs which allowed whoever had them to sign any certificate they wanted, for any domain they wanted. Yes, this is how SSL works and it’s a big mess (I talked about it a little in 2011). Google likely detected this using DNS Pinning. Every version of Chrome checks any Google certificate against a list of legitimate Google certificates, which they build into Chrome itself. If there’s a mismatch, Chrome detects and can report it. Nice, eh? That’s why Rob says don’t mess with Google. You try to MitM any of their domains, and if any users run Chrome they are likely to find out. Everyone else (who can) should do this. Share:

Technewsdaily has an interesting follow up to yesterday’s NYT article on AV effectiveness, as we covered. I agree that using VirusTotal isn’t the best approach – far from it. But I have also heard AV-Test doesn’t use good criteria. I like the NSS Labs methodology myself, which shows higher numbers than Imperva, but much lower than most other tests. Their consumer report is free. and they also offer a companion report. But consumer products are often more different from enterprise versions than you might expect, and the tests weren’t against 0-day like the Imperva ones. These reports by NSS tested effectiveness against exploits using known vulnerabilities, rather than Imperva’s test of signature recognition of new virus variants. Apples and oranges, but I am generally more interested in exploit prevention than signature recognition. Share:

2013?!? WTF?!?! I have this time dilation theory of aging. The older you get, the smaller a as a fraction of your existence each year is, so the shorter it feels. I don’t like it. Anyway, another year down, another at bat. We had a hell of a good year for the company (I’d give a growth number, but we make fun of all the other private companies for doing that), and other than illness I can’t complain about my personal year. A few weeks ago we finished up our Securosis 2013 planning, and things are looking really interesting. A lot has changed since I started this blog company, and we try to evolve with the times. The biggest change you are likely to notice is the pace and nature of our blogging. We are trying to do more linked-list style posts, which include a link or three and some short exposition. The idea is to push more of them out daily, instead of saving everything up for the Incite and Summary. This won’t affect our bigger posts – we’ll still do those – but we realized that when we are busy or working on big projects we fall back to little more than the monster posts that build research projects, and less of the lighter daily posts. We realized you don’t need 1,000 words on everything we cover, and a few sentences can cover lots of it. Some days you might see 10 posts, others you might see none – it all depends on what we are up to. This is an experiment, and we definitely need your feedback. A ton of you are on our daily email list (more than I thought) and since those compile all our posts, that mail might make a good once-a-day every morning – you can sign up. We are also now tweeting all blog content at the @securosis account, and only pushing bigger stuff through our personal accounts. Personally, I realized the blogs I tend to read daily are mostly composed of shorter posts highlighting interesting things I can dig into if I want, and we want to bring more of that flavor to Securosis.com. We are also looking at playing more with short video and maybe even audio content, but we are holding off on other changes while we work out the blog posting and pacing first. Finally, we have a ton more coming up this year. The Nexus launch is going to happen, for real, and we learned a ton in the beta test, which has driven many adjustments. It’s definitely time to ship that puppy. We are also looking at providing more end-user advisory services, but we don’t want to hire any sales execs so that will all be opportunistic. Additionally, our agendas are firming up nicely, and you will hear more on that soon. We weirdly think we can pull all this off with our little cadre of folks. Silly us. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s Dark Reading Post on Database Threats and Countermeasures. Rich’s excellent TidBITS post on Apple’s Security Efforts in 2012. Adrian’s Dark Reading post on Big Data Security Recommendations. Favorite Securosis Posts Mike Rothman: Best Post of 2012: Inflection. As we enter 2013, I wanted to point to probably the best piece we did in 2012, at least IMO. That’s Rich’s Inflection post. Things are always changing, and if you don’t see the change coming you can get steamrollered. Read this. Then read it again. And see whether you’ll see 2013 from the undercarriage of the bus that’s about to run you over. Or not. Mike Rothman: The CloudSec Chicken or the DevOps Egg. I had a very similar conversation regarding the impact of SDN on network security this week. It’s hard to balance being ahead of the market and showing so-called thought leadership against building something the market won’t like. Most of the network security players are waiting for VMWare to define the interfaces and interactions before they commit to much of anything. Adrian Lane: Can we effectively monitor big data?. Yes, it’s my post, but I think DAM needs re-engineering to accommodate big data. Other Securosis Posts Yes, honeypots are new again. SSLpocalypse, part XXII. Responses to AV articles. Karmic Career Advancement. Incite 1/2/13: Consistent Variety. Threatpost: What Have We Learned in 2012. The New York Times on Antivirus. Favorite Outside Posts Adrian Lane: A Pickpocket’s Tale. The use of diversion and control of the subject’s attention is the key ingredient. Fascinating story. Mike Rothman: How to Live Without Regret in 2013. It’s a new year. Folks take time to reset. But are you moving in the right direction? Interesting food for thought here… Mike Rothman: Why Collect Full Content Data? Rich: Stephen Haywood on SSH issues. With PoC code, while still debunking the hype. Excellent. James Arlen: The process myth. Incredibly useful way of thinking about process for Infosec folks. Research Reports and Presentations 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. Pragmatic WAF Management: Giving Web Apps a Fighting Chance. Understanding and Selecting Data Masking Solutions. Top News and Posts Does Your Alarm Have a Default Duress Code? How PCI Standards Will Really Die. Enhancing Certificate Security. Dell acquires Credant Technologies. Cloudpassage adds file integrity monitoring for cloud servers. Someone totally should have patented that FIM stuff. Blog Comment of the Week This week’s best comment goes to our friend Jack Daniels, in response to The New York Times on Antivirus. Amazing, next the NYT will discover newspapers are largely obsolete, too. Or maybe we’ll have to read that new flash on an anti-virus company’s blog to even things up. Share:

2012: What Have We Learned The biggest shift in 2012 was the emergence of state-sponsored malware and targeted attacks as major factors. The idea of governments developing and deploying highly sophisticated malware is far from new. Such attacks have been going on for years, but they’ve mainly stayed out of the limelight. Security researchers and intelligence analysts have seen many of these attacks, targeting both enterprises and government agencies, but they were almost never discussed openly and were not something that showed up on the front page of a national newspaper. A good read by Dennis Fisher, but I have a slightly different take. State-level cyberattacks definitely “broke out” in 2012, but I think a bigger lesson is that pretty much every organization finally realized that signature-based AV isn’t very helpful. Some of this is related to what China has been up to, but not all of it. Over the past year I couldn’t talk to any large organization, or many medium, that isn’t struggling with malware. I couldn’t say that on December 31, 2011. Share:

Outmaneuvered at Their Own Game, Antivirus Makers Struggle to Adapt The antivirus industry has a dirty little secret: its products are often not very good at stopping viruses. Consumers and businesses spend billions of dollars every year on antivirus software. But these programs rarely, if ever, block freshly minted computer viruses, experts say, because the virus creators move too quickly. Everyone in security knows this, but it is a bigger deal when the mainstream press starts covering it. Although too much of the article is a love song to various vendors who still need to prove themselves more. Share:

I am on a plane headed home after a couple days of business development meetings in Northern California, and I am starting to notice a bit of a chasm in the cloud security world. Companies, for good reason, tend to be wary of investing in new products and features before they smell customer demand (the dream-build-pray contingent exempted). The winners of the game invest just enough ahead of the curve that they don’t lose out too badly to a competitor, but they don’t pay too much for shiny toys on the shelf. Or they wait and buy a startup. This is having an interesting inhibiting effect on the security industry, particularly in terms of the cloud. Security companies tend to sell to security buyers. Security buyers, as a group, are not overly informed on the nitty-gritty details of cloud security and operations. So demand from traditional security buying centers is somewhat limited. Dev and Ops, however, are deep in the muck of cloud. They are the ones tasked with building and maintaining this infrastructure. They buy from different vendors and have different priorities, but are often still tasked with meeting security policy requirements (if they exist). They have the knowledge and tools, and in many cases (such as identity, access, and entitlement management), the implementation ball is in their court. The result is that Dev and Ops are the ones spending on cloud management tools, many of which include security features. Security vendors aren’t necessarily seeing these deals, and thus the demand. Also, their sales forces are poorly aligned to talk to the right buying centers, in the right language, which inhibits opportunities. Because they don’t see the opportunity they don’t have the motivation to build solutions. It’s better to cloudwash, spin the marketing brochures, and wait. My concern is that we see more security functionality being pushed into the DevOps tool sets. Not that I care who is selling and buying as long as the job gets done, but my suspicion is that this is inhibiting at least some of the security development we need, as cloud adoption continues and we start moving into more advanced deployment scenarios. There are certainly some successes out there, but especially on the public cloud and the programmatic/software defined security side, advancement is lacking (specifically more API support for security automation and orchestration). There are reasonable odds that both security teams and security vendors will fall behind, and there are some things DevOps simply will not do, which may result in a cloud security gap – as we have seen in application security and other fast-moving areas that broke ‘traditional’ models. It will probably also mean missed opportunities for some security vendors, especially as infrastructure vendors eat their lunch. This isn’t an easy problem for the vendors to solve – they need to tap into the right buying centers and align sales forces before they will see enough demand – and their tools will need to offer more than pure security, to appeal to the DevOps problem space. The problem is easier for security pros – educate yourself on cloud, understand the technical nuances and differences from traditional infrastructure and operating models, and get engaged with DevOps beyond setting policies that break with operational realities. Or maybe I’m just bored on an airplane, and spent too much time driving rental cars the past few days. Share:

I have an on again / off again, love/hate relationship with Twitter. Those of you who follow me might have noticed I suddenly went from barely posting to fully re-engaging with the community. Sometimes I find myself getting fed up with the navel gazing of the echo chamber, as we seem to rehash the same issues over and over again, looking for grammatical and logical gotchas in 140 characters. Twitter lacks context and nuance, and so all too easily degrades into little more than a political talk show. When I’m in a bad mood, or am drowning at work, it’s one of the first things to go. But Twitter also plays a powerful, positive role in my life. It connects me to people in a unique manner unlike any other social media. As someone who works at home alone, Twitter is my water cooler, serving up personal and professional interactions across organizational and geographic boundaries. It isn’t a substitute for human proximity, but satisfies part of that need while providing a stunning scope and scale. Twitter, for me, isn’t a substitute for physical socialization, but is instead an enhancer that extends and augments our reach. When a plane disgorges me in some foreign city, any city, it is Twitter that guarantees I can find someone to have a beer or coffee with. It’s probably good that it wasn’t invented until I was a little older, a little more responsible, and a lot married. As a researcher it is also one of the most powerful tools in the arsenal. Need a contact at a company? Done. Have a question on some obscure aspect of security or coding? Done. Need to find some references using a product? Done. It’s a real-time asynchronous peer network – which is why it is so much better for this stuff than LinkedIn or Facebook. But as a professional, and technically an executive (albeit on a very small scale) Twitter challenges me to decide where to draw the line between personal and professional. Twitter today is as much, or more, a media tool as a social network. It is an essential outlet for our digital personas, and plays a critical role in shaping public perceptions. This is as true for a small-scale security analyst as for the Hollywood elite or the Pope. What we tweet defines what people think of us, like it or not. For myself I made the decision a long time ago that Twitter should reflect who I am. I decided on honesty instead of a crafted facade. This is a much bigger professional risk than you might think. I regularly post items that could offend customers, prospects, or anyone listening. It also reveals more about me than I am sometimes comfortable with in public. For example, I know my tweet stream is monitored by PR and AR handlers from companies of all sizes. They now know my propensity for foul language, the trials and tribulations of my family life, my favorite beers, health and workout histories, travel schedules, and more. I don’t put my entire life up there, but that’s a lot more than I want in an analyst database (yes, they exist). One day Twitter will help me fill a cancelled meeting on a business development trip, and the next it will draw legal threats or lose me a deal. Tweets also have a tendency to reflect what’s on my mind at a point in time, but completely out of context. Take this morning for example: I tweeted out my frustration at the part of the industry and community that spends inordinate time knocking others down in the furtherment of its own egos and agendas. But I failed to capture the nuance of my thought, and the tweet unfortunately referred to the entire industry. That wasn’t my intention, and I tried to clarify, but additional context is a poor substitute for initial clarity. My choice was to be honest or crafted. Either Twitter reflects who I am, or I create a digital persona not necessarily aligned with my real self. I decided I would rather reveal too much about who I am than play politician and rely on a ‘managed’ image. Twitter is never exactly who I am, but neither is any form of writing or public interaction. This explains my relationship with Twitter. It reflects who I am, and when I’m down and out I see (and use) Twitter as an extension of my frustration. When I’m on top Twitter is a source of inspiration and connection. It really isn’t any different than physical social interaction. As an introvert, when I’m in a bad mood, the last thing I want is to sit in a crowded room listening to random discussions. When I’m flying high (metaphorically – I’m not into that stuff despite any legalization) I have no problem engaging in spirited debate on even the most inane subjects, without concern for the consequences. For me, Twitter is an extension of the real world, bringing the same benefits and consequences. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s Dark Reading post on Big Data Security Recommendations. Rich quoted on DLP at TechTarget. Favorite Securosis Posts Mike Rothman (and David Mortman): The CloudSec Chicken or the DevOps Egg. I had a very similar conversation regarding the impact of SDN on network security this week. It’s hard to balance being ahead of the market and showing ‘thought leadership’ against building something the market won’t like. Most of the network security players are waiting for VMWare to define the interfaces and interactions before they commit to much of anything. Adrian Lane: Can we effectively monitor big data?. Yes, it’s my post, but I think DAM needs to be re-engineered to accommodate big data. Rich: Building an Early Warning System: Deploying the EWS. Mike is taking a very cool approach with this series. Other Securosis Posts Selecting an Enterprise Key Manager. Incite 12/12/2012: Love the Grind. Building an Early Warning System: Determining

Now that you have a better understanding of major key manager features and options we can spend some time outlining the selection process. This largely comes down to understanding your current technical and business requirements (including any pesky compliance requirements), and trying to plan ahead for future needs. Yes, this is all incredibly obvious, but with so many different options out there – from HSMs with key management to cloud key management services – it’s too easy to get distracted by the bells and whistles and miss some core requirements. Determine current project requirements Nobody buys a key manager for fun. It isn’t like you find yourself with some spare budget and go, “Hey, I think I want a key manager”. There is always a current project driving requirements, so that’s the best place to start. We will talk about potential future requirements, but never let them interfere with your immediate needs. We have seen projects get diverted or derailed as the selection team tries to plan for every contingency, then buys a product that barely meets current needs, which quickly causes more major technical frustration. List existing systems, applications, and services involved: The best place to start is to pull together a list of the different systems, application stacks, and services that need key management. This could be as simple as “Oracle databases” or as complex as a list of different databases, programming languages used in applications, directory servers, backup systems, and other off-the-shelf application stacks. Determine required platform support: With your list of systems, applications, and services in hand; determine exactly what platform support you need. This includes which programming languages need API support, any packaged applications needing support (including versions), and even potentially the operating systems and hardware involved. This should also include encryption algorithms to support. Be as specific as possible because you will send this list to prospective vendors to ensure their product can support your platforms. Map out draft architectures: Not only is it important to know which technical platforms need support, you also need an idea of how you plan on connecting them to the key manager. For example there is a big difference between connecting a single database to a key manager in the same data center, and supporting a few hundred cloud instances connected back to a key manager in a hybrid cloud scenario. If you plan to one or more key managers in an enterprise deployment, with multiple different platforms, in different locations within your environment, you will want to bee sure you can get all the appropriate bits connected – and you might need features such as multiple network interfaces. Calculate performance requirements: It can be difficult to accurately calculate performance needs before you start testing, but do your best. The two key pieces to estimate are the number of key operations per second and your network requirements (both speed and number of concurrent network connections/sockets). If you plan to use a key manager that also performs cryptographic operations include those performance requirements. List any additional encryption support required: We have focused almost exclusively on key management, but as we mentioned some key managers also support a variety of other crypto operations. If you plan to use the tool for encryption, decryption, signing, certificate management, or other functions; make a list and include any detailed requirements like the ones above (platform support, performance, etc.). Determine compliance, administration, reporting, and certification requirements: This is the laundry list of any compliance requirements (such as which operations require auditing), administrative and systems management features (backup, administrator separation of duties, etc.), reporting needs (such as pre-built PCI reports), and certifications (nearly always FIPS 140). We have detailed these throughout this series, and you can use it as a guide when you build your checklist. List additional technical requirements: By now you will have a list of your core requirements but there are likely additional technical features on your required or optional list. And last but not least spend some time planning for the future. Check with other business units to see if they have key management needs or are already using a key manager. Talk to your developers to see if they might need encryption and key management for an upcoming project. Review any existing key management, especially in application stacks, that might benefit from a more robust solution. You don’t want to list out every potential scenario to the point where no product can possibly meet all your needs, but it is useful to take a step back before you put together an RFP, to see if you can take a more strategic approach. Write your draft RFP Try to align your RFP to the requirements collected above. There is often a tendency to ask for every feature you have ever seen in product demos, but this frequently results in bad RFP responses that make it even harder to match vendor responses against your priorities. (That’s a polite way of saying that an expansive cookie-cutter RFP request is likely to result in a cookie-cutter response rather than one tailored to your needs). Enough of the soapbox – let’s get into testing. Testing Integrating a key manager into your operations will either be incredibly easy or incredibly tricky, depending on everything from network topography to applications involved to overall architecture. For any project of serious scale it is absolutely essential to test compatibility and performance before you buy. Integration Testing The single most crucial piece to test is whether the key manager will actually work with whatever application or systems you need to connect it with. Ideally you will test this in your own environment before you buy, but this isn’t always possible. Not all vendors can provide test systems or licenses to all potential customers, and in many situations you will need services support or even custom programming to integrate the key manager. Here are some suggestions and expectations for how to test and minimize your risk: If you are deploying the