Research

Here’s another idea I’ve been playing with. As I spend more time playing with various cloud and infrastructure APIs, I’m starting to come around to the idea of Stateless Security. Here’s what I mean: Right now, a reasonable number of our security tools rely on their own internal databases for tracking state. Now for something like IPS this isn’t a problem, but there are a lot of other functions that have to rely on potentially stale data since there are only so many times we can run security checks before pissing off the rest of the infrastructure. Take configuration and vulnerability management — we tend to lack even an accurate idea of our assets and have to scan the heck out of our environment to keep track of things. But as both security tools and infrastructure expose APIs, we can use Software Defined Security to pull data, in real time, from the most canonical source, rather than relying on synchronization or external scanning. Take the example I wrote up in my SecuritySquirrel proof of concept. We pull a real time snapshot of running instances directly from the cloud, then correlate it with a real time feed from our configuration management tool in order to quickly identify any unmanaged servers. I originally looked at building a simple database to track everything, but quickly realized I could handle it more quickly and accurately in memory resident code. Even 100,000 servers could easily be managed like this with the memory in your laptop (well, depending on the responsiveness of the API calls). The more I think about it, the more I can see a lot of other use cases. We could pull data from various security tools and the infrastructure itself, performing real time assessments instead of replicating databases. Now it won’t work everywhere, and maybe not even in the majority of cases, but especially as we add more API enabled infrastructure and applications it seems to open a lot of doors. Using a software defined network? Need to know the real-time route to a particular server and correlate with firewall rules based on a known vulnerability? With stateless security this is potentially a few dozen lines of code (or less) that could trigger automatically anytime a new vulnerability is either detected or an advisory released (just add your threat intelligence feed). The core concept is, wherever possible, pull state in real time from the most canonical source available. I’m curious what other people think about this idea. Share:

Our updated and revised 2014 Endpoint Security Buyer’s Guide updates our research on key endpoint management functions, including patch and confirmation management and device control. We have also added coverage of anti- … malware, mobility, and BYOD. All very timely and relevant topics. The bad news is that securing endpoints hasn’t gotten any easier. Employees still click things, and attackers have gotten better at evading perimeter defenses and obscuring attacks. Humans, alas, remain gullible and flawed. Regardless of any training you provide employees, they continue to click stuff, share information, and fall for simple social engineering attacks. So endpoints remain some of the weakest links in your security defenses. As much as the industry wants to discuss advanced attacks and talk about how sophisticated adversaries have become, the simple truth remains that many successful attacks result from simple operational failures. So yes, you do need to pay attention to advanced malware protection tactics, but if you forget about the fundamental operational aspects of managing endpoint hygiene, the end result will be the same. The goal of this guide remains to provide clear buying criteria for those of you looking at endpoint security solutions in the near future. The landing page is in our Research Library. You can also download The 2014 Endpoint Security Buyer’s Guide (PDF) directly. We would like to thank Lumension Security for licensing the content in this paper. Obviously we wouldn’t be able to do the research we do, or offer it to you without cost, without companies supporting our work. Share:

I spend a lot of time in public places. I basically work in coffee shops and spend more than my fair share of time in airports and restaurants. There is nothing worse than being in the groove, banging out a blog post, and then catching a whiff of someone – before I can see them. I start to wonder if the toilet backed up or something died in the wall. Then I look around the coffee shop and notice the only open table is next to you. no. No. NO. Yes, the sticky dude sits right next to you. Now I’m out of my productivity zone and worried about whether the insides of your nostrils are totally burned out. Sometimes I’m tempted to carry some Tiger Balm with me, just to put under my nose when in distress. Yes it would burn like hell, but that’s better than smelling body odor (BO) for the next couple of hours. It’s not just BO. How about those folks that bathe in stinky perfume? Come on Man! The Boy had a tutor once that just dumped old lady perfume on. I wonder if she thought we were strange because we had all the windows in the house open in the middle of winter. Finally the Boss had to tell her the perfume was causing an allergic reaction. Seems we’re all allergic to terrible perfume. I just don’t get it. Do these folks not take a minute to smell their shirt before they emerge from the house? Do they think the smell of some perfumes (like the scent that smells like blood, sweat and spit) is attractive or something? Do they have weak olfactory senses? Do they just not care? I know some cultures embrace natural human smells. But not the culture of Mike. If you stink, you should bathe and wear clean clothes. If you leave a trail of scent for two hours after you leave, you may be wearing too much perfume. There’s got to be a Jeff Foxworthy joke in there somewhere. What should I do? There are no other tables available in the coffee shop. I could throw in the towel and move to a different location. I could suggest to the person they are hygienically challenged and ask them to beat it. I could go all passive aggressive and tattle to the barristas, and ask them to deal with it. Maybe I’ll get one of those nose clips the kids wear when swimming to keep my nostrils closed. But I’ll do none of the above. What I’ll do is sit there. I won’t be chased away by some smelly dude. I mean, I paid my $2.50 to sit here as long as I want. So I pull the cover off my coffee and take a big whiff of java every 10 seconds or so to chase away the stench. By the way, it’s hard to type when you are inhaling coffee fumes. It’s unlikely I’ll get a lot done, but I have no where else to be, I can just wait it out. Which is stupid. My ridiculous ego won’t accept that body odor is likely covered under the 1st Amendment, so I couldn’t make the guy leave even if I wanted to. I’ll suffer the productivity loss to prove nothing to no one, instead of hitting another of the 10 coffee shops within a 5 mile radius of wherever I am. Thankfully I have legs that work and a car that drives. I can just go somewhere else, and I should. Now when the stinky dude occupies the seat next to you on a 7 hour flight, that’s a different story. There is no where to go, but 30,000 feet down. In that case, I’ll order a Jack and Coke, even at 10 in the morning. I’ll accidentally spill it. OOPS. You have to figure the waft of JD > BO every day of the week. -Mike Photo credit: “body_odor“_ originally uploaded by istolethetv 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. Ecosystem Threat Intelligence 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 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 Incite 4 U Define “Integration”: So Forrester’s Rick Holland took the time machine for a spin advocating for security solution integration and the death of point solutions. Nothing like diving back into the murky waters of the integrated suite vs. best of breed issue. It’s not like a lot has changed. Integration helps reduce complexity, at the alleged cost of innovation since it’s mostly big, lumbering companies that offer integrated solutions. That may be an unfair characterization, but it’s been mostly true. Then he uses an example of FireEye’s partnerships as a means to overcome this point solution issue. Again, not new. The security partner program has been around since Check Point crushed everyone in the firewall market with OPSEC in an effort to act big, even as a start-up. But the real question isn’t whether a vendor has good BD folks that can get contracts signed. It’s whether the solutions are truly integrated. And unless the same company owns the technologies, any integrations are a matter of convenience, not necessity. – MR Movies are real: Yesterday I had an interview with a mainstream reporter about some of the research presented at DEF CON this year. Needless to say, there was the ubiquitous “terrorism” question. It

Two interesting items. First up, whatever actual vulnerability was used, the Apple Developer Center was exploited with a code execution flaw: On the site, Apple credits 7dscan.com and SCANV of www.knownsec.com for reporting the bug on July 18, which is the same day the Developer Center was taken offline. During the downtime, Apple reported that the Developer Center website had been hacked, with an intruder attempting “to secure personal information” from registered developers. The company noted that while sensitive information was encrypted, some developer names, mailing addresses, and/or email addresses may have been acquired. Expect to see constant developer targeting, on all platforms, as operating systems themselves become hardened. No details on the flaw other than that, but I didn’t even expect them to release that much. They also credit the researcher who pulled user account info using, it turns out, a different flaw. That’s the guy some expected them to go after legally, which is even more interesting. Item number 2. Researchers from Georgia Tech slipped some test malware into Apple’s App Store: A group of researchers from Georgia Tech developed an app that masqueraded as a news reader that would phone home to reprogram itself into malware – something that was apparently not picked up in Apple’s security screening procedures, reports the MIT Technology Review. Charlie Miller did this once before, and I’m sure it will happen again. It’s a big cat and mouse game, and Apple is in for constant battles (as are Google, Microsoft, and Amazon with their stores). It will keep getting harder, but likely never impossible. The real question is mitigation. Apple yanks apps when needed, but generally won’t claw them back off a device. For Macs that requires a software update, and I am investigating whether it is more automated for iOS. Share:

It appears that Lockheed Martin has trademarked the term “Cyber Kill Chain”. This should be no surprise, and you can read my House of Cybercards post if you want to know why this isn’t merely humorous. In an interview, James Arlen, creator of the term ‘Cyberdouche’, confirmed his term “is still free to use, as also demonstrated by Lockheed.” Share:

Last week, IBM announced a deal to acquire Trusteer, an Israeli company focused on advance endpoint malware detection. The price tag was reported to be $800MM – $1B, so it was a pretty healthy 7-8x multiple of rumored 2013 bookings. Trusteer’s technology fills a huge gap in IBM’s advanced malware story. They do some stuff on their network (IPS) box, but without a real presence on the endpoint, their solution is limited. And for company pushing a total security solution story like IBM, you can’t really have holes. Not obvious one’s anyway. IBM has been selling Trend Micro’s endpoint security suite for years, but it hasn’t been a focus of their story and since the new security regime came in with the acquisition of Q1 Labs, any mention of endpoint security has largely been muted. Obviously that will change now that they have Trusteer (and their emerging enterprise capabilities) in their bag. To be clear, Trusteer didn’t get a huge valuation based on their story of disrupting the anti-virus market. They had built a signifiant market licensing their anti-malware toolbar for distribution through financial institutions. Basically, a bank provides Trusteer’s toolbar to their customers for free and a percentage of customers would use it, resulting in dramatically lower fraud rates for those protected customers. Of course, a bank can’t mandate the use of any technology to their customers, but the reduction in fraud for even the minority of protected devices was significant enough it became a no-brainer for the banks to write a very large check to Trusteer to cover their entire customer base. If anything after the deal closes, IBM’s global channels and presence selling technology to other financial institutions should provide a boost to Trusteer’s existing FI business as well. That’s how you justify writing that kind of check. This was a new path to market for security technology, and that provides a bulk of Trusteer’s existing revenue. But they had bigger designs to target the broader enterprise anti-malware market with a still raw, but interesting set of technologies for advanced malware protection. It’s early, but there is a clear opportunity for someone to totally disrupt the endpoint protection racket. Similar to what Palo Alto did to the perimeter firewall. IBM is betting on being able to spur that disruption. By combining Trusteer’s advanced endpoint protection capabilities with the BigFix endpoint management suite, they have pretty much everything the existing EPP vendors provide with better advanced malware protection. So getting rid of the incumbent is much more achievable, rather than asking a Fortune-class enterprise to trust a start-up. But IBM still has work to complete their endpoint security offerings. As described in our recent Endpoint Security Buyer’s Guide series, IBM now has better heuristics and some lockdown technologies. Though we expect endpoint activity monitoring to become a significant requirement over the coming few years, so that remains a gap in their offering. IBM also has to ensure they keep a good portion of the Trusteer expertise and DNA after the acquisition. They’ve been able to do so with the Q1 Labs acquisition, and as with most big M&A this is a critical success factor to get the value out of the deal. The fact that IBM has already made it clear that Trusteer’s Israeli-based research team will become a key part of a new IBM cybersecurity lab should help keep those folks for a little while. So is the beginning of the end for EPP? If you take a step back, EPP has been on a path to irrelevance for years. More than a few large enterprises have commented on how they are using the absolute cheapest means possible of checking the compliance box requiring AV and deploying these advanced products on critical endpoints. Providing years of suspect value will get customers to think like that. The good news for the existing EPP vendors is that their existing suites integrate some (but not all) of the advanced technologies needed to really address advanced malware. They’ve just done a very poor job at describing how their products have evolved, and that’s resulted in a clear negative market perception of the technology. We’ll be doing a more in-depth analysis of advanced endpoint protection starting next month, but suffice it say all the EPP guys don’t necessarily have to die during the transition. Yet the fact remains, they need to kill their golden goose if they are going to get there. If Big AV continues to position these new technologies as a minor upgrade with just a few added features to their existing offering (not to antagonize their installed base), they won’t create enough urgency to upgrade to the current version of the EPP suite. As we saw with the NYT breach (missing 44 out of 45 attacks) earlier this year, deprecated EPP is not much of a defense against modern, advanced attacks. These vendors basically need to make it very clear that the old stuff doesn’t work and make it very attractive to upgrade to the new stuff. This probably requires pulling support from the old suites despite the clear risk of customers picking a different solution when facing the upgrade. But we believe it’s a bigger risk to let 80% of their installed base use obsolete technology. We also should mention other huge winners as a result of this deal are the folks that do advanced endpoint protection, like Bit9, Bromium and Invincea. And Cisco gets some of these capabilities via the Sourcefire acquisition (who has bought Immunet a few years back). These emerging vendors have different approaches to solve the advanced malware problem, but with the valuation Trusteer was able to get they should feel pretty good about having a high value comp when they inevitably shop their companies. Photo credit: “Scrooge McDuck’s money bin for DuckTales Remastered at iam8bit gallery” originally uploaded by insidethemagic Share:

Much of the security industry spends significant time and effort focused on how hard it is to deal with today’s attacks. Adversaries continue to improve their tactics. Senior management doesn’t get it, until there is a breach… then your successor can educate them. And the compliance mandates hanging over your organization like albatross remain 3-4 years behind the attacks you see daily. The vendor community compounds the issues by positioning every product and/or service as a solution to the APT problem. Which means they don’t really understand advanced attackers at all. But complaining doesn’t solve problems, so we put together a CISO’s Guide to Advanced Attackers to help you structure a programmatic effort to deal with these adversaries. It makes no difference what a security product or service does – they are all positioned as the only viable answer to stop the APT. Of course this isn’t useful to security professionals who actually need to protect important things. And it’s definitely not helpful to Chief Information Security Officers (CISOs) who have to explain their organization’s security programs, set realistic objectives, and manage expectations to senior management and the Board of Directors. So as usual your friends at Securosis are here to help you focus on what’s important and enable you to wade through the hyperbole to understand what’s hype and what’s real. This paper provides a high-level view of these “advanced attackers” designed to help a CISO-level audience understand what they need to know, and maps out a clear 4-step process for dealing with advanced attackers and their innovative techniques. The landing page is in our research library. You can also download The CISO’s Guide to Advanced Attackers (PDF) directly. We would like to thank Dell Secureworks for licensing the content in this paper. Obviously we wouldn’t be able to do the research we do, or offer it to you without cost, without companies supporting our efforts. Share:

I got my first computer back in the mid-80’s, a few years after I started playing and programming in the back half of elementary school. It was a shiny new Commodore 64 a friend of my Mom’s gave me – we weren’t financially lucky enough to afford one ourselves. In retrospect, I probably owe that man more than anyone else outside family. I quickly fancied myself a ‘hacker’ because, after getting my first modem, I was mentally capable of logging into bulletin board systems with the word ‘hack’ in the title. As with most things in life, I had no idea what I was doing. In college I played with tech, but emergency medicine, martial arts, NROTC, and other demands ate up my time. Even when I started working in tech professionally, in the mid-to-late 90’s, I never connected with the 303 crew or any of the real hackers surrounding me. I was living and working in a bubble. I knew I wasn’t a real hacker at that point, but you could call me “hacking curious”. Fast forward to two weeks ago at Black Hat. Thursday morning at 8:22 I woke up, looked at my phone, and realized I had missed 2 calls and a text message from the Black Hat organizers. I spent the weekend and first part of the week teaching our cloud security class, and had, at some point, agreed to be a backup speaker after my session pitch didn’t make it through the process. I figured it was a sympathy invite to make me feel good about myself, that would never possibly come to fruition. Nope. They offered me a slot at 10:15 if my demo and presentation were ready (based on this software defined security research). Another speaker had to pull out. I said yes, forgetting that it wasn’t ready, because I broke part of it in the class. Then I pulled up my slides and realized they were demo slides only, and not an actual session and concept narrative. Then I went to the bathroom. Three times. Number 2. I managed to pull it together over the next 90 minutes, and made my very first Black Hat technical presentation on time. The slides worked, the demo worked, and after the session I got some major validation that this was good research on the leading edge of defensive security. To be honest, I was worried that it was so basic I would be laughed out of there. It was a career highlight. A wannabee script kiddie from Jersey managed to hold his own on the stage at Black Hat, with 90 minutes warning. I can’t stop talking about it – not because of my prodigious ego but because I’m still insanely excited. It’s like being the smallest kid on the football team and, years later, finding yourself in the NFL. Except a lot more people have played in NFL games than have spoken at Black Hat. I am a very lucky and thankful person. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Mike in SC Magazine on the Trusteer deal. Adrian on mainframe hacking at Dark Reading. Dave Lewis: Hitting The Panic Button. Mike and I are both quoted by Alan Shimel in this article about whether we would want our kids to work in infosec. Another one from Mike in Dark Reading on Innovation at Black Hat. Mike’s column in Dark Reading: Barnaby Jack & the Hacker Ethos. Favorite Securosis Posts Mike Rothman: Is Privacy Now Illegal? It depends on who you ask, I guess. A thought-provoking post from Rich. David Mortman: Rich’s Incomplete Thought: Is the Cloud the Secproasaurus Extinction Event? And Are DevOps the Mammals? Betteridge’s law does not apply. Rich: Credibility and the CISO. Yup. Other Securosis Posts Research Scratchpad: Outside Looking In Incite 8/14/2013: Tracking the Trends. HP goes past the TippingPoint of blogging nonsense. Incite 8/7/2013: Summer’s End. Continuous Security Monitoring: Migrating to CSM. Continuous Security Monitoring: Compliance. Continuous Security Monitoring: The Change Control Use Case. Favorite Outside Posts Mike Rothman: Godin: More Gold on Human Behavior. “Your first mistake is assuming that people are rational.” LOL. He must be a part-time security person… David Mortman: “Big Filter”: Intelligence, Analytics and why all the hype about Big Data is focused on the wrong thing. Dave Lewis: NSA “touches” more of Internet than Google. Rich: Unsealed court-settlement documents reveal banks stole $trillions’ worth of houses. Crime takes all forms, and justice doesn’t apply equally. Mike Rothman: HowTo: Detecting Persistence Mechanisms. Figuring out how your Windows machines are pwned is critical. I learn a lot from this cool windowsir blog. This post deals with detecting new persistence mechanisms. Research Reports and Presentations 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. Defending Against Denial of Service (DoS) Attacks. Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments. Top News and Posts Every Important Person In Bitcoin Just Got Subpoenaed By New York’s Financial Regulator. 2003 Blackout: An Early Lesson in Planetary Scale? Cisco readies axe for 4,000 employees. Assessment of the BREACH vulnerability. ‘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. Crimelords: Stolen credit cards… keep ‘em. It’s all about banking logins now. Blog Comment of the Week This week’s best comment goes to Marco, in response to Incomplete Thought: Is the Cloud the Secproasaurus Extinction Event? And Are DevOps the Mammals? I think this is a valid point. My take on it is that whether we like it or not, external compliance requirements drive a majority of security initiatives. And seeing that e.g. PCI DSS is still trying to react to internal virtualization gives you an idea on how up to date that is. Simply no big

I have bunch of random research thoughts I am working on. I think they are building into a cohesive whole but cannot make any promises. I’m branding these forming ideas as my “research scratchpad”, and will appreciate any feedback. Yesterday, while working with a client, I was asked to define Software Defined Security. This won’t be that post, but as part of discussing the definition and characteristics we got into another concept that has really been standing out to me for a while, and I suspect is on the verge of changing in a big way. Early security was pretty much just another aspect of infrastructure. Access controls, networking, and our minimal other controls were built into the infrastructure. This started changing in the 90’s, into what I call our “outside looking in” posture. The vast majority of security controls starting moving to external tools that are often desynchronized from the underlying infrastructure. This isn’t an absolute rule – the balance has shifted materially to a security control layer, not merely a security management layer… added to infrastructure, not necessarily embedded within it. A heck of a lot of our security involves cutting wires between boxes and inserting new boxes, or adding software agents where no one really wants them. This was a natural, proper evolution – not a mistake or stupidity. It was all we had. But the cloud and virtualization blow this apart in two ways: We are regaining hooks, thanks to APIs, into the infrastructure itself. The security management plane doesn’t necessarily need to be as decoupled as in ‘traditional’ infrastructure architectures. We are losing the ability to insert external security controls into the infrastructure. Adding these integration/choke points adds performance and functional costs beyond those we have learned to generally work around over the past couple decades. The ability to manage large swatches of infrastructure security using the same tools, techniques, and interfaces as those building and maintaining the infrastructure is a major opportunity to remediate many perceived shortcomings of existing security methods. Share:

A key aspect of business today is the extended enterprise. That’s a fancy way of saying no organization does it alone anymore. They have upstream suppliers who help produce whatever it is they produce. They have downstream distribution channels that help them sell whatever needs to be sold. They outsource business processes to third parties who can handle them better and more cheaply. With the advent of advanced communication and collaboration tools, teams work on projects even if they don’t work for the same company or reside on the same continent. Jack Welch coined the term “boundaryless organizations” back in 1990 to describe an organization that is not defined by, or limited to, horizontal, vertical, or external boundaries imposed by a predefined structure. They are common today. In order to make the extended enterprise work, your trading partners need access to your critical information. And that’s where security folks tend to break out in hives. It’s hard enough to protect your networks, servers, and applications, while making sure your own employees don’t do anything stupid to leave you exposed. Imagine your risk – based not just on how you protect your information, but also on how well all your business partners protect their information and yours. Well, actually, you don’t have to imagine that – it’s reality. Let’s do a simple thought exercise to get a feel for the risk involved in one of these interconnected business processes. Let’s say that for cost reasons the decision was made to outsource software maintenance on legacy applications to an offshore provider. These applications run in your datacenter, and maintenance only involves pretty simple bug fixes. You can’t shut down the application, but it’s clearly not strategic. What’s the risk here? Start getting a feel for your exposure by asking some questions: Which of our networks do these developers have access to? How do they connect in? Who are the developers? Has the outsourcer done background checks on them? Are those checks trustworthy? What is the security posture of the outsourcer’s network? What kinds of devices do they use? Even if the developers are trustworthy, can you trust that their machines are not compromised? Yes, you can segment your network to ensure the developers only have access to the servers and code they are responsible for. You can scan devices on connection to your network to ensure they aren’t pwned. You can check the backgrounds of the developers yourself. You can even audit the outsourcer’s network. And you can still get compromised via business partners, because things move too fast to really stay on top of everything. It takes seconds for a machine to be compromised. With one compromised machine your adversary gains presence on your network and can then move laterally to other devices with more access than the developers have. This happens every day. The point is that you have very little visibility into trading partner networks, which means additional attack surface you don’t control. No one said this job was easy, did they? These interconnected business processes will happen whether you like it or not. Even if you think they pose unacceptable risk. You can stamp your feet and throw all the tantrums you want, but unless you can show a business decision maker that the risk of maintaining the connection is greater than the benefit of providing that access you are just Chicken Little. Again. So 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. We call this an Early Warning System, and external threat intelligence can give you a head start on knowing which attacks are heading your way. Here is an excerpt from our EWS paper to illuminate the concept. You can shrink the window of exploitation by leveraging cutting-edge research to help focus your efforts more effectively, by looking in the places attackers are most likely to strike. You need an Early Warning System (EWS) for perspective on what is coming at you. None of this is new. Law enforcement has been doing this, well, forever. The goal is to penetrate the adversary, learn their methods, and take action before an attack. Even in security there is a lot of precedent for this kind of approach. Back at TruSecure (now part of Verizon Business) over a decade ago, the security program was based on performing external threat research and using it to prioritize the controls to be implemented to address imminent attacks. Amazingly enough it worked. Following up our initial EWS research, we delved into a few different aspects of threat intelligence, which provides the external content of the EWS. There is Network-based Threat Intelligence and Email-based Threat Intelligence, but both of those sources are more about what’s happening on your networks and with your brands. These really help you understand what’s happening on your partner networks, which clearly pose a risk to your environment. So we are spinning up a new series to continue our threat intelligence arc. This series is called Ecosystem Threat Intelligence and will delve into how to systematically assess your extended network of trading partners to understand the risk they present. Armed with that information you will finally have the information to block a trading partner or tune your defenses based on the risk they pose. As with all our research, we will focus on tangible solutions that can be implemented now, while positioning yourself for future advances. As a reminder, we develop our research using our Totally Transparent Research methodology to make sure you all have an opportunity to let us know when we are right – and more importantly when we are wrong. Finally, we would like to thank BitSight Technologies for potentially licensing the paper at the end of this process. Our next post will delve into the types of information you need to assess your trading partners, and how it