Research

I do not think Mike’s and Rich’s points are at odds at all. Mike’s post lays out what in my view is infosec’s Achilles heel: lack of strategic alignment with the business. There are very few things that basically everyone in infosec agrees on; but a near universal one is that you can, should, and will never show a Return on Security Investment. “The business” is just supposed to accept this, apparently, and keep increasing the budget year after year; the People’s Republic of Information Security shall remain unsullied by such things as profit and loss, and breeze merrily along. Of course in the very next breath, after waving away the petty request for return on investment, infosec teams routinely complain that “the business” doesn’t get security. I humbly suggest that while that may be true, security doesn’t actually get “the business” either. Rich’s approach to this issue is quite pragmatic: close collaboration. Business is already driven by externalities – infosec is not unique in this regard, although security does have different drivers (although they get more closely aligned every day). I like Rich’s approach, but I would take it one step farther. Andy Jaquith tweeted the other day on OWASP that ‘ITsec guys need to “embed” into existing OSS projects not make new ones’ – this applies to security teams in spades. Embed security in the business. We are so used to trotting out things like breach statistics, but what is “the business” supposed to get from these meaningless out-of-context numbers? They look at the world in terms of transaction volume, throughput, customer retention, cash flows, ARPU, and other business relevant metrics. Every industry has its own key metrics – does your security team know yours? When General David Petraeus took over US forces in Iraq, one of the first things he changed was how to measure success. The previous command used classic military metrics – how many American soldiers got killed and how many enemy combatants did we kill. Petraeus changed the measurement and thus the mindset. He used metrics like how many little old ladies can get safely to the market in Baghdad to buy oranges. This is a totally different way of looking at measuring success and failure. There are precedents for this kind of mind shift in certain industry segments. Banks have sophisticated fraud detection teams and schemes. They are able to map events and compare fraud rates against total transactions and customer interactions. It is a simple way to communicate fraud control program effectiveness with “the business”, once you stop looking at security as something separate and see it as part of the whole. The practical point here is to very clearly understand your business’ competitive advantage. There is no generic answer for this – business imperatives and competitive differentiators vary from one business to the next. That is a major reason there is no magic set of security metrics that broadly addresses the whole industry. You need to know what your moat is, and to organize metrics and processes around moats. If you are Walmart you care about anything that drives up cost because a big part of your moat is being the low-cost provider. If you are an ecommerce company then availability is a big moat. You can bet that Amazon can tell you very precisely what 5 minutes of downtime or an extra second to load a page costs in real dollars. All communication with “the business” should be within this context – then we can map our own internal infosec issues such as attacker innovation and operational efficiency onto a framework that is much more trackable for productive collaboration with “the business.” One more thing: there is no security. There is just “the business” – with everyone sharing the same mission and working together as best we can. Share:

We generally avoid talking about the NSA, Snowden, and such, but this piece is actually illuminating, without any sort of political commentary. Steven J. Vaughan-Nichols points out that moving your stuff outside the US gives the NSA more freedom to snoop: Because, in the United States, the NSA and friends need to jump through the FISC hoops to listen in to your e-mail, cloud data transfers, phone calls, whatever. If you’re doing any of the above to someone or some site outside of the US, any of your communications are pretty much fair game. I always like to out reactionary foolishness like this. Just a little bit of knowledge and analysis make clear that your data isn’t safer overseas. Consider this a commentary on reactionism – not on the scope of NSA monitoring. Share:

The Payment Card Industry Security Standards Council recently released a preview of potential changes in PCI 3.0 that will go into effect in 2014. It looks like they read the Verizon DBIR: The PCI Standards are updated based on feedback from the industry, per the standards development lifecycle as well as in response to current market needs. Common challenge areas and drivers for change include: Lack of education and awareness Weak passwords, authentication Third-party security challenges Slow self-detection, malware Inconsistency in assessments Nothing is final, but a few highlights worth understanding now, since they may sure as heck nail you later: Better current documentation of cardholder data flow and everything within PCI scope. Penetration testing is a requirement. If they are serious about this I am not sure how that will play out for the SMB side of the world. This one I’m darn curious to see how they handle. I predict total failure: To address compromises where the organization had been PCI DSS compliant but did not maintain that status. Recommendations focus on helping organizations take a proactive approach to protect cardholder data that focuses on security, not compliance, and makes PCI DSS a business-as-usual practice. An emphasis on consistency of assessments. More specifics on “daily log reviews”. Oh my. PCI isn’t totally worthless, but I don’t expect much practical improvement to come out of the 3.0 updates. These are very reasonable holes to address, and will help, but we may be about to burden many organizations with activities they cannot possibly support. Start your SaaS engines now… Share:

We touched on the Risks of the Extended Enterprise and the specifics of Assessing Partner Risk, so now let’s apply these concepts to a few use cases to help make the concepts a little more tangible. We will follow a similar format for each use case, talking about the business needs for access, then the threat presented by that access, and finally how Ecosystem Threat Intelligence (EcoTI) helps you make better decisions about specific partners. Without further ado, let’s jump in. Simple Business Process Outsourcing Use Case Let’s start simply. As with many businesses, sometimes it is cheaper and better to have external parties fulfill non-strategic functions. We could be talking about anything, from legacy application maintenance to human resources form processing. But almost all outsourcing arrangements require you to provide outsiders with access to your systems so they can use some of your critical data. For any kind of software development an external party needs access to your source code. And unless you have a very advanced and segmented development network, developers have access to much more than just the (legacy) applications they are working on. So if any of their devices are compromised, attackers can gain access to your developer’s devices and build systems, and a variety of other things that would probably be bad. If we are talking about human resources outsourcing, those folks have access to personnel records, which may include sensitive information including salaries, employment agreements, health issues, and other stuff you probably don’t want published on Glassdoor. Even better, organizations increasingly use SaaS providers for HR functions, which moves that data outside your data center and removes even more of your waning control. The commonality between these two outsourcing situations is that access is restricted to just one trading partner. Of course you might use multiple development shops, but for simplicity’s sake we will just talk about one. In this case your due diligence occurs while selecting the provider and negotiating the contract. That may entail demanding background checks on external staffers and a site visit to substantiate sufficient security controls. At that point you should feel pretty good about the security of your trading partner. But what happens after that? Do you assess these folks on an ongoing basis? What happens if they hire a bad apple? Or if they are attacked and compromised due to some other issue that has nothing to do with you? Thus, the importance of an ongoing assessment capability. If you are a major client of your outsourcer you might have a big enough stick to get them to share their network topology. So at least you won’t have to build that yourself. In this scenario, you are predominately concerned with bot activity (described as Sickness from Within in our previuos Risk Assessment post) because that’s the smoking gun for compromised devices with access. Compromised Internet-facing devices can also cause issues so you need to consider them too. But as you can see, in this use case it makes sense to prioritize internal issues over the public-facing vulnerabilities when you calculate a relative risk score. In this limited scenario it is not really a relative risk score, because you aren’t really comparing the provider to anyone else, because only one external party has access any particular dataset. So if your Ecosystem Threat Intelligence alerts you to an issue with this partner you will need to act quickly. Their access could cause you real problems. Many Partners Use Case To complicate things a bit let’s consider that you may need to provide access to many trading partners. Perhaps external sales reps have access to your customer database and other proprietary information about your products and services. Or perhaps your chain of hospitals provides access to medical systems to hundreds of doctors with privileges to practice at your facilities. Or it could even be upstream suppliers who make and assemble parts for your heavy machinery products. These folks have your designs and sales forecasts, because they need to deliver inventory just in time for you to get the product out the door (and hit your quarterly numbers). Regardless of the situation, you have to support dozens of trading partners or more, offering them access to some of your most critical enterprise data. Sometimes it’s easier for targeted attackers to go after your trading partners, than to target you directly. We have seen this in the real world, with subassembly manufacturers of defense contractors hacked for access to military schematics and other critical information on a particular weapons program. In this situation, as in the use case above, the security team typically cannot refuse to connect with the partner. Sales executives frown on the security team shutting down a huge sales channel. Similarly like the security team cannot tell the final assembly folks they can’t get their seats because the seat manufacturer got breached. Although you can’t stop the business, you can certainly warn the senior team about the risks of connecting with that specific trading partner. But to substantiate those concerns, you need data to back up your claim. This is where calculating relative risk scores for multiple trading partners can really help make your case. It’s probably not a bad assumption that all trading partners are compromised in some fashion. But which ones are total fiascos? Which partners cannot even block a SQLi attack on an ecommerce site? Which has dozens of bots flooding the Internet with denial of service attacks? Specifics from your Ecosystem Threat Intel efforts enable you to make a fact-based case to senior executives that connecting to a partner is not worth the risk. Again, you can’t make the business decision for that executive, but you can arm them with enough information for them to make a rational decision. Or you could suggest an alternative set of security controls for those specific partners. You might force them to connect into your systems through a VDI (virtual desktop) service on your premises (so your data never leaves your network) and monitor everything they do in

Something has been bugging me. It’s big data. Not the industry but the term itself. Every time I am asked about big data I need to use the term in order to be understood, but the term itself steers the uninitiated in the wrong direction. It leaves a bad taste in my mouth. It’s wrong. It’s time to stop thinking about big data as big data, and start looking at these platforms as the next logical step in data management. What we call “big data” is really a building block approach to databases. Rather than the pre-packaged relational systems we have grown accustomed to over the last two decades, we now assemble different pieces (data management, data storage, orchestration, etc.) together in order to fit specific requirements. These platforms, in dozens of different flavors, have more than proven their worth and no longer need to escape the shadow of relational platforms. It’s time to simply think of big data as modular databases. Big data has had something a chip on its shoulder, with proponents calling the movement ‘NoSQL’ to differentiate these platforms from relational databases. The term “big data” was used to describe this segment, but as it captures only one – and not even the most important – characteristic, the term now under-serves the entire movement. These databases may focus on speed, size, analytic capabilities, failsafe operation, or some other goal, and they allow computation on a massive scale for a very small amount of money. But just as importantly, they are fully customizable to meet different needs. And they work! This is not a fad. It is are not going away. It is not always easy to describe what these modular databases look like, as they are as variable as the applications that use them, but they have a set of common characteristics. Hopefully this post will not trigger any “relational databases are dead” comments. Mainframe databases are still alive and thriving, and relational databases have a dominant market position that is not about to evaporate either. But when you start a new project, you are probably not looking at a relational database management system. Programmers simply need more flexibility in how they manage and use data, and relational platforms simply do not provide the flexibility to accommodate all the diverse needs out there. Big data is a database, and I bet within the next couple years when we say ‘database’ we won’t think relational – we will mean big data modular databases. Share:

VMWare is pushing hard on the virtual datacenter concept this week at VMWorld, with the first release of their new SDN networking approach based on the Nicira acquisition. Greg Ferro has a good take (hat tip to @beaker/Hoff for the link): VMware NSX is a solution for programmable and dynamic networking service that interoperates with VMware vCloud director, OpenStack or Hyper-V–this is where the real value is derived. In the near future, servers will no longer be “operating systems” but “application containers.” Instead of installing an application onto a operating system, the application will part of a service template that will do most or all of these: Three things: I don’t think it is a game changer itself, but it is a (sort of new) entry by a major player into an area of growing interest. It will certainly create a lot more dialogue. Oh crap, now I need to brush up on networking again. And you networking types need to brush up on programming and APIs. SDN coupled with the cloud can enable seriously cool security capabilities. Like a couple API calls to identify every server on every network segment, every path to said servers, and all the firewall rules around them. In real time. Share:

As we discussed in the introduction post of our Ecosystem Threat Intelligence series, today’s business environment features increasing use of an extended enterprise. Integrating systems and processes with trading partners can benefit the business, but dramatically expands the attack surface. A compromised trading partner, with trusted access to your network and systems, gives their attackers that same trusted access to you. To net out the situation, you need to assess the security of your partner ecosystem; and be in a position to make risk-based decisions about whether the connection (collaboration) with trading partners makes sense, and what types of controls are necessary for protection given the potential exposure. To quote our first post: You need to do your due diligence to understand how each organization accessing your network increases your attack surface. You need a clear understanding of how much risk each of your trading partners presents. So you need to assess each partner and receive a notification of any issues which appear to put your networks at risk. This post will discuss how to assess your ecosystem risks, and then how to quantify the risks of partners for better (more accurate) decisions about the levels of access and protection appropriate for them. When assessing risks to your ecosystem, penetration tests or even vulnerability scans across all your partners are rarely practical. You certainly can try (and for some very high-profile partners with extensive access to your stuff you probably should), but you need a lower-touch way to perform ongoing assessments of the vast majority of your trading partners. As with many other aspects of security, a leveraged means of collecting and analyzing threat intelligence on partners can identify areas of concern and help you determine whether and when to go deeper and to perform active testing with specific partners. Breach History Investors say past performance isn’t a good indicator of future results. Au contraire – in the security business, if an organization has been compromised a number of times, they are considerably more likely to be compromised in the future. Some organizations use publicly disclosed data loss as a catalyst to dramatically improve their security posture… but most don’t. There are various sources for breach information, and consulting a few to confirm the accuracy of a breach report is a good idea. Besides the breach disclosure databases, depending on your industry you might have an ISAC (Information Sharing and Analysis Center) with information about breaches as well. Although there are some limitations in this approach. First of all, many of the public breach reporting databases are volunteer-driven and can be a bit delayed in listing the latest breaches, mostly because the volume of publicly disclosed breaches continues to skyrocket. Some organizations (think military and other governmental organizations) don’t disclose their breaches, so there won’t be public information about those organizations. And others play disclosure games about what is material and what isn’t. Thus checking out public disclosures is not going to be comprehensive, but it’s certainly a place to start. Mapping Your Ecosystem The next step is to figure out whether the partner has current active security issues, which may or may not lead to data loss. The first step will be to associate devices and IP addresses with specific trading partners, because to understand a partner’s security posture you need an idea of their attack surface. If you have the proverbial “big bat” with a partners – meaning you do a lot of business with them and they have significant incentive to keep you happy – you can ask them for this information. They may share it, or perhaps they won’t – not necessarily because they don’t want to. It is very hard to keep this information accurate and current – they may not have an up-to-date topology. If you can’t get it from your partner you will need to build it yourself. That involves mining DNS and whois among other network mapping tactics, and is resource intensive. Again, this isn’t brain surgery, but if you have dozens (or more) trading partners it can be a substantial investment. Alternatively you might look to a threat intelligence service specializing in third party assessment, which has developed such a map as a core part of their offering. We will talk more about this option under Quick Wins in our next post. Another question on network mapping: how deep and comprehensive does the map need to be. Do you need to know every single network in use within a Global 2000 enterprise? Because that would be a large number of networks to track. To really understand a partner’s security posture you should develop as comprehensive a viewpoint as you can, within realistic constraints on time and investment. Start with specific locations that have access to your networks, and be sure to understand the difference between owning a network and actually using it. Many organizations have large numbers of networks, but use very few of them. Public Malaise Now that you have a map associating networks with trading partners, you can start analyzing security issues on networks you know belong to trading partners. Start with Internet-accessible networks and devices – mostly because you can get there. You don’t need permission to check out a partner’s Internet-facing devices. In-depth scanning and recon on those devices is bad form, but hopefully attackers aren’t doing that every day, right? If you find an issue that is a good indication of a lack of security discipline. Especially if the vulnerability is simple. If your partner can’t protect stuff that is obviously be under attack (Internet-facing devices), they probably don’t do a good job with other security. Yes, that is a coarse generalization, but issues on public devices fail the sniff test for an organization with good security practices. So where can you get this information? Several data sources are available: Public website malware checking: There are services that check for malware on websites – mostly by rendering pages automatically on vulnerable devices and seeing whether bad stuff happens. Often a trading partner will buy these services themselves

From the Wall Street Journal (via The Verge): The attack began at 2 a.m. Sunday morning and was followed by a more intense attack at 4 a.m., according to the China Internet Network Information Center, which apologized to affected users in its statement and said it is working to improve its “service capabilities.” The attack, which was aimed at the registry that allows users to access sites with the extension “.cn,” likely shut down the registry for about two to four hours, according to CloudFlare No idea on the motivation yet, which is interesting. China has one of the most sophisticated filtering systems in the world and analysts rate highly the government’s ability to carry out cyber attacks. Despite this, China is not capable of defending itself from an attack, which CloudFlare says could have been carried out by a single individual. Dear mass media, offense isn’t defense. They come out of different budgets with different motivations. China has IT silos just like we do, get over it. Share:

With seven trips in the last eight weeks – and I would have been 8 for 8 had I not been sick one week – I’d have been out of the office the entire last two months. It almost feels weird blogging again but there is going to be a lot to write about in the coming weeks given the huge amount of research underway. Something really hit home the other day when I was finishing up a research project. Every day I learn more about computer security, yet every day – on a percentage basis – I know less about computer security. Despite continuous research and learning, the field grows what seems like an exponential rate. The number of new subject areas, threats and response techniques grows faster than any person can keep up with. I was convinced that in the 90s I could ‘know’ pretty much all you needed to know about computer security; that concept is now laughable. Every new thing that has electrons running through it creates a new field for security. Hacking pacemakers and power meters and vehicle computer is not surprising, and along with it the profession continues to grow far beyond a single topic to hundreds of sciences, with different distinct attack and defense perspectives. No person has a hope of being an expert in more than a couple sub-disciplines. And I think that is awesome! Every year there is new stuff to learn, both the ‘shock and awe’ attack side, as well as the eternally complex side of defense. What spawned this train of thought was Black Hat this year, where I saw genuine enthusiasm for security, and in many cases for some very esoteric fields of study. My shuttle bus on the way to the airport was loaded with newbie security geeks talking about how quantum computing was really evolving and going to change security forever. Yeah, whatever; the point was the passion and enthusiasm they brought to Black Hat and BSides. Each conversation I overheard was focused on one specific area of interest, but the discussions quickly led them into other facets of security they may not know anything about – social engineering, encryption, quantum computing, browser hacking, app sec, learning languages and processors and how each subsystem works together … and on and on. Stuff I know nothing about, stuff I will never know about, yet many of the same type of attacks and vulnerabilities against a new device. Since most of us here at Securosis are now middle-aged and have kids, it’s fun for me to see how each parent is dealing with the inevitability of their kids growing up with the Internet of Things. Listening to Jamie and Rich spin different visions of the future where their kids are surrounded by millions of processors all trying to alter their reality in some way, and how they want to teach their kids to hack as a way to learn, as a way to understand technology, and as a way to take control of their environment. I may know less and less, but the community is growing vigorously, and that was a wonderful thing to witness. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich on Threatpost- How I Got Here. I got to do my third favorite thing, talk about myself. Dave Mortman on Big Data Security Challenges. Mike’s DR column “Prohibition for 0-day Exploits”. Mike quoted in CRN about Proofpoint/Armorize deal. Favorite Securosis Posts Rich: The CISO’s Guide to Advanced Attackers. Mike’s latest paper is great. Especially because I keep having people thank me for writing it when he did all the work. And no, I don’t correct them. Adrian Lane: Hygienically Challenged. After 10 weeks of travel, I’m all too familiar with this element of travel. But after 3 days fishing and hiking in the Sierra’s I was one of these people. Sorry to the passengers on that flight. David Mortman: Research Scratchpad: Stateless Security. Mike Rothman: Lockheed-Martin Trademarks “Cyber Kill Chain”. “Cyberdouche” Still Available. A post doesn’t have to be long to be on the money, and this one is. I get the need to protect trademarks, but for that right you’ll take head shots. Cyberdouche FTW. Other Securosis Posts “Like” Facebook’s response to Disclosure Fail. Research Scratchpad: Stateless Security. New Paper: The 2014 Endpoint Security Buyer’s Guide. Incite 8/21/2013 — Hygienically Challenged. Two Apple Security Tidbits. Lockheed-Martin Trademarks “Cyber Kill Chain”. “Cyberdouche” Still Available. IBM/Trusteer: Shooting Across the Bow of the EPP Suites. New Paper: The CISO’s Guide to Advanced Attackers. Favorite Outside Posts Adrian Lane: Making Sense of Snowden. Look at my comments in Incite a couple weeks back and then read this. Chris Pepper: Darpa Wants to Save Us From Our Own Dangerous Data. Rich: Facebook’s trillion-edge, Hadoop-based and open source graph processing engine. David Mortman: Looking inside the (Drop) box. Mike Rothman: WRITERS ON WRITING; Easy on the Adverbs, Exclamation Points and Especially Hooptedoodle. Elmore Leonard died this week. This article he wrote for the NYT sums up a lot about writing. Especially this: “If it sounds like writing, I rewrite it.” Research Reports and Presentations The 2014 Endpoint Security Buyer’s Guide. The CISO’s Guide to Advanced Attackers. Defending Cloud Data with Infrastructure Encryption. Network-based Malware Detection 2.0: Assessing Scale, Accuracy and Deployment. Quick Wins with Website Protection Services. Email-based Threat Intelligence: To Catch a Phish. Network-based Threat Intelligence: Searching for the Smoking Gun. Understanding and Selecting a Key Management Solution. Building an Early Warning System. Implementing and Managing Patch and Configuration Management. Top News and Posts Hackers for Hire. Bradley Manning Sentenced to 35 Years in Prison Declassified Documents Prove NSA Is Tapping the Internet ‘Next Big’ Banking Trojan Spotted In Cybercrime Underground How the US (probably) spied on European allies’ encrypted faxes Researcher finds way to commandeer any Facebook account from his mobile phone Blog Comment of the Week This week’s best comment goes to michael hyatt, in response to Research Scratchpad: Stateless Security. I think we’re working our way in that direction, though not as explicitly as you define it. But while

Every company makes mistakes, especially when it comes to researchers disclosing security bugs and/or vulnerabilities. And when the frustrated researcher goes public and makes a scene, the company has a few choices. Break out the lawyers. Throw mud at the researcher in the press. Own the mistake and try to fix it. Yes there are other options. But we tend to see #1 and #2 a lot more than we see #3. Which is why I “like” (to use Facebook’s terminology) how they responded to the issue. The researcher in question basically showed how he could post to Zuckerberg’s timeline (yes, the CEO). That would usually cause some lawyerly type of activity from a company. But this was their response: I’ve reviewed our communication with this researcher, and I understand his frustration. He tried to report the bug responsibly, and we failed in our communication with him. Um, that’s pretty clear. Facebook accepted responsibility. They took their lumps, which is what they should do. They did explain that there wasn’t sufficient detail in the bug report, so it got routed incorrectly. But all the same, they didn’t shy away from their part in the situation. But far too many company’s don’t do that. But it gets better because Joe Sullivan, Facebook’s CSO, commits to a few changes to the program. We will make two changes as a result of this case: (1) We will improve our email messaging to make sure we clearly articulate what we need to validate a bug, and (2) we will update our whitehat page with more information on the best ways to submit a bug report. Now they still won’t pay a bounty because the vulnerability was proven against a real user (yes the CEO). But some folks in the security community, lead by Marc Maiffret, banded together and raised over $12K for the guy anyway. Win win. Which rarely happens when you are talking about vulnerability disclosure. Share: