The Weekly Ink #10
##THE WEEKLY INK## The Weekly Ink is the weekly newsletter brought to you by Duo Labs, the security research team at Duo Security, with curated links of interest in the security world to inform the community on security happenings and culture.
In an interview with GovInfoSecurity, Michael Daniel - the White House Cybersecurity Coordinator, the man who "leads the interagency development of national cybersecurity strategy and policy" - argued that his lack of a technical background was not a liability, but an asset, saying "you don't have to be a coder to really do well in this position. In fact, actually, I think being too down in the weeds at the technical level could be a bit of a distraction..."
This interview has caused a bit of a firestorm in what Daniel might call the "cybersecurity" community. In particular, luminaries like Alex Stamos (CISO at Yahoo) and Ed Felten (Princeton CS Professor) pointed out that this argument would be soundly rejected in other fields:
I find Felten's perspective extremely compelling and credible, not least because he recently spent a year serving as Chief Technologist at the FTC. Meanwhile, the points that Daniel and his defenders make are valid, but irrelevant. Sure, a senior administration official should not generally be writing code (even if we at Duo occasionally need to remind our CEO of this notion) - just as we would expect the Surgeon General not to be routinely seeing patients, or the Attorney General not to be personally prosecuting cases. These officials are primarily administrators, not practitioners - but that doesn't mean they don't need to understand the technical underpinnings of their policy decisions. To write "cybersecurity" policy without this perspective is, to my mind, extremely dangerous.
"Isn’t it ironic getting a Java exploit via java.com, the primary source for one of the most commonly used browser plugins?" Well, maybe, but if Java is really still one of the most commonly used browser plugins, then we're all a lot worse off than I thought! After all, the Java plugin's record on security over the last few years has been so bad that major browser and OS vendors have taken to make users jump through hoops to get it running... er, well actually, I should cut this Java rant short, because that's not the real point here.
Rather, we've become conditioned to believe that we'll generally be OK browsing the internet as long as we don't visit any 'bad' sites (and the likes of Google and Microsoft have developed sophisticated systems - Safe Browsing and SmartScreen, respectively - based substantially on this premise). It turns out, however, that this model is broken by the very plumbing that greases the (financial) wheels of the web; after all, what are online ad networks but a way for arbitrary third parties to inject content into the websites you and I like to frequent? That these ads might sometimes be malicious shouldn't come as a surprise to anyone, and it's not exactly a new trend. Still, as Fox-It reports, the bad guys have been getting a lot more sophisticated.
For end-users, we'll probably be sticking to the same sorts of advice, though: make sure you're running a secure, up-to-date browser (might I recommend Google Chrome?), disable or uninstall as many plug-ins as possible (or at least enable click-to-play), install EMET if you're a Windows user, and... well... be vigilant.
We recently mentioned the announcement of Google's Project Zero - a wide-ranging effort to find and fix bugs in other vendors' products. Aside from numerous credits in changelogs from the likes of Adobe and Apple, one of Project Zero's most interesting outcomes (so far) has been its blog. Over the last couple weeks, Chris Evans has penned two deeply-technical posts on some of the peculiar bugs they've identified; while these posts may be a bit difficult to follow for those not intimately familiar with memory allocators, they're most impressive in their wit and humility:
... I decided to develop against Fedora 20, 32-bit edition. Why the 32-bit edition? I’m not going to lie: I wanted to give myself a break. I was expecting this to be pretty hard so going after the problem in the 32-bit space gives us just a few more options in our trusty exploitation toolkit...
At this rate, this could quickly become one of my favorite security blogs to follow.
We'll end this edition of The Weekly Ink with a shout-out to our friends at the University of Michigan (among others), who recently studied and documented severe failings in the capabilities of those X-Ray body scanners on which the TSA spent billions. I'll just let J. Alex Halderman do the rest of the talking:
“These machines were tested in secret, presumably without this kind of adversarial mindset, thinking about how an attacker would adapt to the techniques being used,” says Halderman, who along with the other researchers will present the research at the Usenix Security Conference Thursday. “They might stop a naive attacker. But someone who applied just a bit of cleverness to the problem would be able to bypass them. And if they had access to a machine to test their attacks, they could render their ability to detect contraband virtually useless.”