Research

FierceCIO’s Derek Slater offers an interesting perspective on why W. Edwards Deming hates your approach to IT security. I was educated as an industrial engineer, so we had to study Deming left, right, and center in school. Of course when I graduated and went into programming, nobody realized that Deming’s concepts also apply to software development. But that’s another story for another Six Sigma. Derek’s point is that as long as security is treated as a tactical, reactive, part of the organization… it’s doomed to fail. The most common approach is that IT security is regarded as a tactical discipline. The IT security director is part of the IT department, reports to the CIO (or lower), and manages his or her work based on a set of tactical metrics–many of which are merely forms of counting: We blocked this number of web-based attacks and this other number of malware attachments. This approach is purely reactive and therefore doomed to fail. The late business management guru W. Edwards Deming said this about reactive management–that it’s not rational: “Rational behavior requires theory. Reactive behavior requires only reflex action.” He also said this about counting: “It is easy to count. Counts relieve management of the necessity to contrive a measure with meaning.” Yup. The answer is to become more strategic in the eyes of the folks who matter. You could certainly become Pragmatic as a means to do that. But Derek offers a few pointers on that front as well. First is to treat security as a risk management function. As long as you can gain consensus on how to quantify security risk, that’s a good start. Second, you had better React Faster, because you are only as good as your last response. We agree. Finally, security needs better measurement. No kidding. There, friends, is the biggest gap in security: becoming strategic to the business. It’s measuring what we do relative to the business metrics that make an impact on the value of your company. Unfortunately there is no simple answer to the question of what matters to your business. Photo credit: “W. Edwards Deming–statistician…saint” originally uploaded by Peter Kazanjy Share:

It’s nice that my kids are still at a stage where they don’t want to disappoint me or the Boss. They need our approval and can be crushed if we show even the slightest measure of dissatisfaction in what they do. My ego-centric self likes that, but the rest of me wants them to learn to stop worrying about what everyone thinks and do what they think is right. Of course, that involves having enough life experience to understand the difference between right and wrong. I know that a 12 (soon to be 13) year old is not there yet. She still has much to learn. I’m happy to share my experiences so she can learn from them. I told the stories about when I was bullied. About how I learned that hard work creates results (with a bunch of luck). I have tried to impress upon her how important it is to surround yourself with people who appreciate the uniqueness we all possess in different ways. And for all I do, the Boss does 10x. All to give the kids a chance to be productive citizens and good people. If I could teach her even a portion of my experiences over the past (almost) 45 years, she wouldn’t need to go through my angst, suffer my disappointment, or learn the lessons I’ve learned… the hard way. But I can’t. Because kids don’t listen. Maybe they listen or pretend to, but they certainly don’t understand. How could they understand? Some things you just have to learn for yourself. But hopefully there aren’t tens of millions of people watching as those hard lessons are learned. And hopefully the lesson isn’t documented in video and photos, and doesn’t go viral via more Tweets per second than the Super Bowl. Yes, I am talking about the fiasco that Miley Cyrus has become. To be honest, I haven’t watched the performance on the MTV VMAs. I can’t bring myself to do it. I’ve seen that movie before. Child star gets too famous too fast, makes too much money, surrounds themselves with too many vultures and predators, gets very very lost, and becomes tabloid fodder. I’ve got November 10 in the Miley rehab pool. And where are her parents to tell her she’s being an idiot? I mean, what do you think Billy Ray was thinking as he watched her performance? Actually, I don’t care what he was thinking. What would you be thinking if that was your child? It brings front and center Chris Rock’s famous line: “If you can keep your son off the pipe and your daughter off the pole, you’re ahead of the game.” But you still can’t teach kids everything. Sometimes they have to learn hard lessons themselves. And it’s gonna hurt. Your job is to pick them up. Dust them off. Then help them get back on the horse. But most of all, they need to know that you love them. During the good times and bad. Especially during the bad times… –Mike Photo credit: “Bad Teacher” originally uploaded by Sonya Cheney Heavy Research We are 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. Ecosystem Threat Intelligence Use Cases and Selection Criteria Assessing Ecosystem Risk The Risk of the Extended Enterprise Continuous Security Monitoring Migrating to CSM The Compliance Use Case The Change Control Use Case The Attack Use Case Classification Defining CSM Why. Continuous. Security. Monitoring? Database Denial of Service Countermeasures Attacks Introduction API Gateways Implementation Key Management Developer Tools Newly Published Papers 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 Incite 4 U I get AV’s cufflinks: Great thought-provoking post by Wendy Nather about the marketing-driven evolution of anti-malware technology. Succinctly stated: “what comes after advanced?” Her points are well-stated: no AV vendor merely uses signatures, and it’s all about detection – not necessarily prevention – now. I guess this React Faster stuff might have some legs. Though the best line in the post is “Nobody wants to say antivirus is dead, but let’s just say they’re planning ahead for the wake and eyeing the stereo.” That kind of prevention is obsolete, but as evidenced by the IBM/Trusteer deal, clearly there is a great future (at least from a valuation standpoint) for companies with new-age prevention technology. But what happens when that advanced stuff isn’t differentiated anymore? I guess the marketeers will need to come up with a new term to describe the next shiny object. – MR Tick tock: Dealing with a breach is never a lot of fun. First you need to detect it in the first place, then you need to figure out whether it’s real, what exactly is going on, what was affected, and how. All while containing the incident, keeping as many important things running as possible, and figuring out a recovery strategy. For anything resulting in lost data, it is an unenviable process to work through. Then, if regulated data is lost, there is the eventual breach notification, which senior executives love. Okay, now imagine that you have 24 hours to notify authorities of any breach and get all the details to them within 72 hours. Because if you operate in the EU, that is your new time limit. I’m all for breach notification laws, but that one might be a tad unrealistic. Keep in mind that we still need to see how it is going to be enforced, but you had better get your lawyers cracking on it now. You know, just in case. – RM Growth business: The latest Nilson Report on global card fraud rates is out, and fraud now accounts for 5.22% of all card transactions. In fact, even with card usage up 11.4% YoY, fraud is up 14.6% over the same period. And when you’re

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: