Explosive growth in video, a sense that the ad marketplace might have finally “figured out” mobile, the ability to discover previously unseen demand sources — publishers are seeing more channels and methods for monetizing than they ever have. That’s great for revenue, but it also opens up an ever-increasing number of security points publishers need to monitor on their own properties.
To get a sense of the kinds of security risks tucked into otherwise run-of-the-mill transaction channels, and what publishers and their verification partners can do about it, AdMonsters Senior Editor Gavin Dunaway called up the CEO of security and verification platform GeoEdge, Amnon Siev. According to Siev, certain developments in the marketplace — like the shift toward HTML5 — have improved security. But regardless, creators of malware do everything they can to remain a couple steps ahead of the market’s legitimate buyers and sellers, and they choose points of entry somewhere other than the first place you’d expect. Read on to find Siev’s insider’s take on the security front, where creators of malware and bots face off against publishers and ad verification services.
GAVIN DUNAWAY: Are there some topics that you think have not gotten the attention they deserve?
AMNON SIEV: From our perspective, there is more and more of a need for automation. When you look at the day-to-day challenges, that’s a big problem publishers are facing. Back in the day, Flash had many challenges around security, and Flash also introduced CPU issues. People were hoping the introduction of HTML5 would solve that.
Flash was very easy for agencies to produce. But there was demand from publishers to move into HTML5, because of its superior level of performance and security. Having said that, HTML5 is a much more complicated creative. Who is responsible for putting it into one coherent entity, rendered correctly? Who is going to make sure that when the user interacts with that entity, everything is working properly?
We are also seeing the boom of content recommendation engines in companies like Taboola, Nativo and Outbrain, with many top publishers putting the pixel code of these native advertising platforms on their sites. Of course, this brings with it a security vulnerability — malicious activity is occurring through these channels.
Native is a broad term, but again, it’s another piece of technology the publisher needs to check.
GD: Is HTML5 in general a more secure format than Flash?
AS: Yes. This is going back to good old Javascript. You are not relying on a Flash plug-in that has tons of end-user vulnerabilities.
GD: Are there specific challenges in HTML5 for publishers beyond the complexity of the files?
AS: There are issues of latency. For example, the user starts to interact with the banner, and then another image needs to load. This may lead to latency because of the size of the HTML5 file. In HTML5, the publisher allows another piece of code to change the layout of the page dynamically, according to the user’s interaction. And the publisher needs to make sure that this is done in a way that maintains a good user experience.
In fact, some publishers are so concerned with this issue, they ask the agency to provide them the separate HTML5 components, planning to integrate them into one coherent piece of code themselves.
GD: Content recommendation engines are great to bring up, because those links could go to bad sites. How do you help a publisher avoid that?
AS: We look at two areas for verification. The first is a quick link, the creative and the code. We check the different objects delivered with the ad, and we look for abnormal behavior, such as auto-redirect or drive-by download, that may happen when the ad is rendered. The second area we check is the part that happens after you actually click on the banner – the post-click URL. We check all the redirects until you get to the landing page. Then we send out a notification if there is a policy breach. We not only tell you if there is malware — that’s the easy part— we provide other important pieces of information that make the alert actionable. To start with, we present the user flow — the user clicked on the banner, then was redirected to a landing page that had a drive-by download, and the drive-by download was malicious or not malicious.
Next, we pinpoint the demand partner, because even if you know you have malware, you cannot take action without knowing who you need to call.
When the demand partner is identified, the easiest approach is to say, “I’m shutting down the campaign completely.” If you find out malicious activity came through a certain SSP, and you’re looking for immediate action, the only thing you can do is shut down the SSP tag. When you shut down the campaign completely, you shut down the demand partner completely. The implication for this is a big loss of revenue which can translate into tens of thousands of dollars on a daily basis.
But you can also take a more moderate approach: Contact the demand partner and ask them to deactivate the malware source. We offer the softer approach because we distinguish between the types of malicious activity that occur, like a malicious file vs. an attempt to inject malware. We provide a precise recommendation for how to resolve any incident breach, with the mindset of not only protecting their users’ experience and their brand, but also their revenue as well.
GD: What are the biggest challenges you’re facing on mobile? And are you doing mobile web as well as mobile apps?
AS: We are. From a security perspective, I would say the biggest problem would be phishing scams and auto-redirect. If you asked the biggest mobile exchange or SSP, they would say that the biggest issue is auto-redirect. And this is not a security issue per se, but it actually creates a very bad user experience.
Another challenge is, some of these attacks target only mobile carriers. Today, part of our solution is to check content that is being targeted to mobile carriers versus regular IPs.
GD: What difference does that make, whether it’s carrier- or IP-based?
AS: It’s a matter of sophistication of the bad guys. Traditionally, companies doing the scanning would look for attacks to a regular proxy or regular IP. So the bad guys took it a notch up, and they’re carrying out attacks that only target mobile carriers. For example, you can use your iPhone via wifi and everything will be okay, but the moment you’re connected to your 4G network, you will start to see malicious activity.
GD: You guys recently introduced your video verification product. What were the biggest challenges in bringing that to reality? What is so different with video compared to display?
AS: From a technical perspective, when you analyze a typical video impression, it’s divided into two areas. One is a traditional Javascript domain, which is quite similar to what we used to see in display, when we had nested iframes. One demand partner may call another using Javascript rendered on the client side. At some point the player is loaded, and then basically the player becomes the king. This introduces extra challenges, to capture activities on VAST and on the VPAID domain.
People keep talking about the shift over to HTML5, but when you analyze the video, specifically the VPAID element, many still are using Flash. The typical video exchange serve both Flash and HTML5 objects that need to be analyzed separately. We have been able to surmount all of these challenges and provide video scanning capabilities that capture and detect the VAST and VPAID specs for our customers’ needs.
GD: I still feel like we hear a lot of publisher reluctance to use third-party security services. What is typical pushback you hear?
AS: I wouldn’t say that we hear pushback. It’s kind of a joke here internally: Usually we get the call after the client has their first malware incident.
ROI is a factor. It’s very hard to quantify the cost of a malvertising attack. It’s hard to get a publisher that never had a security incident to spend a dollar to get protection. But the moment they actually face the problem head-on, they say it’s a no-brainer.