Partner Perspectives  Connecting marketers to our tech communities.
SPONSORED BY
10/11/2017
01:30 PM
Aviram Zrahia
Aviram Zrahia
Partner Perspectives
50%
50%

Can Machine Learning Outsmart Malware?

Using machine learning in the cybersecurity domain is a growing trend with many advantages, but it also has its risks.

Fighting malware is a modern arms race. Not only has malware evolved to be more evasive and harder to detect, but their vast numbers make it even more difficult to handle. As a result, detecting a malware has become a big data problem which requires the help of self-learning machines to scale the knowledge of analysts, handle the complexity beyond human capabilities, and improve the accuracy of threat detection.

There are number of approaches to this problem; choosing the right algorithm to serve the security engine’s purpose is not an easy task. In this article, we will refer to machine learning (ML) as an application of artificial intelligence (AI) where computers learn without being explicitly programmed. We will look into some use cases and challenges, starting with an interesting question: why do we see this growing trend now? The answer has to do with lower costs and increased availability of private and public cloud technology for collecting, storing and analyzing big data in real time, and the academic research progress in ML and related algorithms such as Deep Neural Networks (DNN).

Putting together a successful ML cybersecurity implementation is a multidisciplinary task, which requires coding capabilities, as well as cyber domain expertise, and deep math/statistics knowledge, originally described by Drew Conway in his data science Venn diagram. ML models can be used to classify malicious files (including ransomwares), analyze abnormal user and network behavior, perform advanced event analytics, identify encrypted malware traffic, synthesize threat intelligence feeds, and fuse in-direct telemetry signals with security events in cloud deployments.

Implementing a complete solution requires embedding the selected ML algorithm into a three-stage workflow of operation. First, the ML engine performs analysis, usually enhanced with other detection technologies to deliver open and integrated defense in depth. Then, enforcement is performed across the entire network preferably in an automatic and unified way. And finally, Cyber Threat Intelligence (CTI) is shared and received with other systems and entities, to further enrich and add context to the next analysis task -- feedback.

Cyber Defense Challenges and Machine Learning

A ML model is only as good as the content from the data sources that feed it (better known as: garbage in, garbage out). Similarly, performing analysis without domain expertise and context can be misleading, and measuring the engine’s performance/accuracy is tricky.

Another challenge is that attackers also use machines for different attack phases, as described by Intel Security in their 2017 threat predictions report. But the most interesting challenge is the risk of attackers actually manipulating ML defense engines. A visible example, as described by Dave Gershgorn in Popular Science last year,  was presented by Google’s researchers who manipulated road signs to deceive a driverless car, using black-box attack principles that can be leveraged also in the cyber domain to fool the machine.

Machines are taking over many aspects of our lives (Did anyone say autonomous cars?), but given the pros and cons described, should we let the machines take over our defense systems? The answer is yes and no. On the one hand, machines can outsmart human capabilities on certain aspects of scale and complexity. On the other hand, they can be manipulated, but so can humans. The debate is ongoing But based on the buzz in the market it's clear that machines are already transforming the way we perform cyber defense.

Aviram Zrahia is a cybersecurity consulting engineer at Juniper Networks, and a research fellow in the Blavatnik Interdisciplinary Cyber Research Center (ICRC) at Tel-Aviv University. His primary research interest is cyber threat intelligence sharing, where he uses technology ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
New Mexico Man Sentenced on DDoS, Gun Charges
Dark Reading Staff 5/18/2018
Google to Delete 'Secure' Label from HTTPS Sites
Kelly Sheridan, Staff Editor, Dark Reading,  5/21/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: "The one you have not seen, won't be remembered".
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-9317
PUBLISHED: 2018-05-23
Privilege escalation vulnerability found in some Dahua IP devices. Attacker in possession of low privilege account can gain access to credential information of high privilege account and further obtain device information or attack the device.
CVE-2018-1193
PUBLISHED: 2018-05-23
Cloud Foundry routing-release, versions prior to 0.175.0, lacks sanitization for user-provided X-Forwarded-Proto headers. A remote user can set the X-Forwarded-Proto header in a request to potentially bypass an application requirement to only respond over secure connections.
CVE-2018-1122
PUBLISHED: 2018-05-23
procps-ng before version 3.3.15 is vulnerable to a local privilege escalation in top. If a user runs top with HOME unset in an attacker-controlled directory, the attacker could achieve privilege escalation by exploiting one of several vulnerabilities in the config_file() function.
CVE-2018-1123
PUBLISHED: 2018-05-23
procps-ng before version 3.3.15 is vulnerable to a denial of service in ps via mmap buffer overflow. Inbuilt protection in ps maps a guard page at the end of the overflowed buffer, ensuring that the impact of this flaw is limited to a crash (temporary denial of service).
CVE-2018-1125
PUBLISHED: 2018-05-23
procps-ng before version 3.3.15 is vulnerable to a stack buffer overflow in pgrep. This vulnerability is mitigated by FORTIFY, as it involves strncat() to a stack-allocated string. When pgrep is compiled with FORTIFY (as on Red Hat Enterprise Linux and Fedora), the impact is limited to a crash.