• United States



Senior Staff Writer

RSAC 2014: RSA Conference (Day 4)

Feb 27, 20146 mins
Core Java

It is day four of the RSA Conference in San Francisco, California, and thing's are winding down. Below is the latest from the show floor.

Thursday at the RSA Conference is the last day for most of the expo and the sales events. There are talks taking place, and the expo hall is open, but for the most part people are starting to head home, creating a bit of a lull in the action.

The morning was full of meetings, which yielded some interesting bits of information, but also set the stage for things down the line. However, when asked about the topics of the hour here at the show, the key topic mentioned by most of those we met with was threat intelligence. However, while threat intelligence seems sexy and has a nice ring to it, it’s something that’s easier said than done. In fact, most of the vendors talking about threat intelligence are actually rebranding old business intelligence services.

Such offerings don’t help with anything if you don’t understand the data that’s being presented. And the general feel here is that most organizations are swimming in data and “intelligence” but they haven’t a clue as to how to leverage it.

During another briefing this morning, AppRiver mentioned the uptick in malicious traffic that’s been taking place in the last month or so.  The Asprox botnet is observed in this trend, but another botnet, still unknown to AppRiver (it hasn’t gotten a name yet, and it uses fresh IP addresses) has taken center stage. It operates on unusual hours, activating between 10am and noon each day, blasting up to 20 million spam messages with Zeus malware when it hits peak volumes.  This might explain the bump in malware that’s been hitting inboxes as of late.

While all of this was taking place, Grant published a solid piece on incident response on the main site, recapping the panel he attended at RSA yesterday.  And finally, if you installed the RSA Conference mobile application, you may want to rethink that decision.

As it turns out, the application has a few problems.

“Technically the highest impact vulnerability had to do with the app being vulnerable to man-in-the-middle attacks, where an attacker could inject additional code into the login sequence and phish credentials. If we were dealing with a banking application, then heads would have been rolling in an engineering department, but this particular app has only been downloaded a few thousand times, and I seriously doubt that some evil hacker is going to take the time out of their day to target this one application (out of tens-of-millions) to try phish credentials to a conference.

“It was the second most severe vulnerability that caught my eye though. The RSA Conference 2014 application downloads a SQLite DB file that is used to populate the visual portions of the app (such as schedules and speaker information) but, for some bizarre reason, it also contains information of every registered user of the application–including their name, surname, title, employer, and nationality.”

IdM (Identity / Privilege Management)

In an email exchange before the RSA Conference, Salted Hash asked Leonid Shtilman, the CEO of Viewfinity, to outline his thoughts the good, bad, and the ugly of IdM.

Good: Privilege management is both a security solution and a solution for savings on IT support calls. Privilege management solutions allow an application to run and work perfectly, yet the end user will not have administrator rights, thus ensuring the environment is secure, and because the privilege management solution handles the elevation, IT support doesn’t need to be involved.

Bad: Without privilege management, support costs can be very, very expensive. We recently became aware of a use case from an organization with more than 100,000 computers. They calculated that their privilege management solution has saved the company $2.5 million in just one year. Security and cost-conscious organizations understand that they need granular privilege management capabilities.

Ugly: Allowing users to have administrative rights creates a highly vulnerable security loophole. When users are setup as local administrator accounts, an intruder will use these accounts to install malware. At the moment the malware is installed, the intruder will likely gain access to an organization’s passwords. Actually, he’s apt to have access to everything. 

Multi-factor Authentication

As before, prior to the start of the RSA Conference, Salted Hash asked asked Paul Martini, the CEO of iBoss, his thoughts on the good, the bad, and the ugly aspects of multi-factor authentication.

Good: (1) Using multiple factors for authentication increases security by validating a user accessing the system is the person authorized to access the system. (2) Combining multiple authentication methods such as a password with a secure ID token substantially reduces compromise and data loss.Bad: This can make accessing systems a little more difficult. For example, if a you forget your authentication token ID at home and need to make a bank wire transfer online that requires it, your online banking password will not be enough to get the job done.Ugly: Users may become overly confident with multi-factor authentication (such as having a secure token) causing them to lose sight of basic security principles. For example, making sure you enter your password over a secure web connection (https) and not writing your password down on a piece of paper may be disregarded by the not so tech savvy.

True multi-factor authentication requires authentication elements from three distinct categories; something a user knows (i.e. their pin or password), something the user has (an ATM card), and something the user is (such as using a fingerprint on a biometric scan). Incorrect implementations use two items from the same category. For example, asking a user for their password then a security question such as “Where street did you grow up on?”

“I’ve personally never been sold on the concept of multi factor. I don’t think it really solves anything and it’s very often cumbersome.  And, in any case, there’s always the problem that the authentication token has to be stored somewhere, and if hackers get a hold of that, no factor will be sufficient to protect us.” – Pierluigi Stella, Chief Technology Officer, Network Box USA