Analytics
1/14/2014
08:53 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

The Changing Face Of The IT Security Team

Big data means big changes in the makeup of IT security teams at large vendors and enterprises

For a peek at the IT security team of the future, consider the team at Cisco Systems or at OpenDNS: In both firms, the security team includes not only malware experts and researchers, but also data scientists who lack any security expertise whatsoever.

The surge in "big data" resources for vendors and large enterprises -- a growing trend toward gathering internal event logs and external threat-intelligence feeds -- has pressured some organizations to rethink the type of expertise they need in their IT security departments. Enter the math majors, most of whom weren't schooled in Stuxnet or botnet traffic.

When Dan Hubbard, CTO at OpenDNS, started at his post two years ago, one of his goals was to rethink the composition of a security research team. "One of the goals was to rethink if you could restart a security research team, what would be the absolute things you have to have to be competitive?" Hubbard says.

OpenDNS built on the existing team that was in place, but added a new generation of members. "Instead of hiring [more] reverse engineers or malware researchers, we decided to augment [those experts] ... [with] data scientists who understood massive amounts of data," Hubbard says. That also meant adding algorithmic experts with Ph.D.s in machinery and graph theory, as well as some who have worked in genome research or fields unrelated to cybersecurity, he says.

The first fruit of OpenDNS's new-age team was its Security Graph, a service for security researchers that provides them with access to OpenDNS's Internet and DNS traffic data and analysis. The idea is to provide researchers with a more global view of malware, botnets, and advanced threats rather than just a snapshot or slice of the activity.

[Red October, PayPal phishing campaign connection discovered via new OpenDNS service for researchers. See OpenDNS Offers Security Researchers Free Service For Tracking Cybercrime, Cyberespionage.]

Today, one-third of OpenDNS's security team are traditional "security geeks" or experts, and one-third are data scientists who work on math problems to analyze all of the data, Hubbard says.

Cisco also has expanded its security team with algorithmic experts in its Threat Research, Analysis, and Communications (TRAC) group. "We have a whole side of the team comprised of data scientists ... They have no backgrounds in security," says Levi Gundert, technical lead of the Cisco TRAC team. "Data is data to them. At the end of the day, we're driving the use case for them, but they are managing the models and tools to quickly pull back data for analysis in an automated fashion."

Gundert says the gap between the cultures -- mainly how the two worlds can speak different languages in the context of security -- is a work in progress. "When we increase communication and the opportunities to communicate, we're seeing a lot more success," he says. "Without that, a lot gets lost in translation when shooting emails back and forth."

He says the teams hold weekly phone calls to ensure both sides are understanding one another.

Times are changing for security geeks as big data and threat intel-sharing become part of the picture. No longer can the teams work in isolation: "The days of siloing teams has to go away. Even within research teams, you find a Web team, a vulnerability team, and an email team -- they all need to come together," OpenDNS's Hubbard says.

Much of security research leads to protection when a new threat is discovered. Data scientists take a different approach: "A lot of the data scientists we have hired are looking at a problem before the attack happens," he says.

Pairing the security researcher and the data scientist is a powerful combination. "You've got someone who knows a ton about the security space and how threats work, and then you've got the math/data science person" working on crunching the data and they "feed off each other," Hubbard says.

When OpenDNS teamed up with Kaspersky Lab to study the Red October attacks targeting diplomatic entities mainly in Eastern Europe and Central Asia, Kaspersky Lab had malware samples that they had reverse-engineered. "They are really good at that kind of stuff -- they had recompiled the binary, but didn't have the data or breadth of the network ... so we helped build that."

That hunger for security intelligence from internal logs and external threat-gathering services goes hand-in-hand with what many experts consider the Holy Grail of security: continuous monitoring, where organizations watch each and every move that goes on in and out of their networks in hopes of catching the bad stuff before it does real damage.

Tenable CEO and CTO Ron Gula says this need for big data gathering and crunching expertise has a lot to do with the evolution toward continuous monitoring. "I only see data scientists with bigger companies -- with 10,000 and up or 5,000 and up employees -- not at SMBs," Gula says. "Big Fortune 500s and government agencies can measure their networks in real time and measure patch rates, for example, or tell you the number of systems patched within the last five days for the past 90 days."

That's what data scientists do, he says. "In my opinion, the reason [organizations] are doing [data science] is because they are moving toward continuous monitoring," Gula says.

OpenDNS's Hubbard sees large enterprises gradually moving toward data scientists in their security teams as well, but to solve somewhat different problems than OpenDNS, Cisco, and other vendors are solving. A large enterprise security operations center typically has experienced cyberattacks for more than a decade and, in the process, purchased all different types of security tools to defend its environment. "In many cases, they have not deployed it right, and many of these solutions are disparate systems, and there's an information gap between all of them," Hubbard says.

So some use tools like Splunk, for example, but many are struggling to apply context to the data they're gathering. "Even with all of those pulling data into one central data store, it's hard to understand that the receptionist's computer is infected or the CEO's computer" has been compromised, he says.

"The attacks are not identified and correct context isn't applied to them," he says. "Companies are hiring a big data scientist due to the business intelligence" they need to correlate, he says.

"It's about turning data into information. Getting access to data is not hard. Applying the appropriate context to it is really important," Hubbard says.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message. Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Threat Intel Today
Threat Intel Today
The 397 respondents to our new survey buy into using intel to stay ahead of attackers: 85% say threat intelligence plays some role in their IT security strategies, and many of them subscribe to two or more third-party feeds; 10% leverage five or more.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5485
Published: 2014-09-30
registerConfiglet.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via unspecified vectors, related to the admin interface.

CVE-2012-5486
Published: 2014-09-30
ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.

CVE-2012-5487
Published: 2014-09-30
The sandbox whitelisting function (allowmodule.py) in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain privileges to bypass the Python sandbox restriction and execute arbitrary Python code via vectors related to importing.

CVE-2012-5488
Published: 2014-09-30
python_scripts.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via a crafted URL, related to createObject.

CVE-2012-5489
Published: 2014-09-30
The App.Undo.UndoSupport.get_request_var_or_attr function in Zope before 2.12.21 and 3.13.x before 2.13.11, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote authenticated users to gain access to restricted attributes via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.