{"id":24805,"date":"2019-01-30T15:30:00","date_gmt":"2019-01-30T15:30:00","guid":{"rendered":"https:\/\/www.darkreading.com\/vulnerabilities---threats\/open-source-and-machine-learning-a-dynamic-duo\/a\/d-id\/1333720"},"modified":"2019-01-30T15:30:00","modified_gmt":"2019-01-30T15:30:00","slug":"open-source-machine-learning-a-dynamic-duo","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/open-source-machine-learning-a-dynamic-duo\/","title":{"rendered":"Open Source & Machine Learning: A Dynamic Duo"},"content":{"rendered":"
<\/div>\n
\n<\/header>\n

In recent months, machine-learning code has become readily available in the open source community, putting security analysts on a path toward easier data pattern recognition.<\/span> <\/p>\n

As a data scientist, I’m always looking for new patterns and insights that guide action \u2014 especially ways to make data science more effective for cybersecurity. One pattern I see consistently throughout the industry is the inability to operationalize machine learning in a modern security operations center. The challenge is that the capabilities behind different machine-learning models are difficult to explain. And if those of us in security can’t understand how something works, and how to apply it to what we do, why on earth would we trust it?<\/p>\n

Machine learning (ML) can revolutionize the security industry, change the way we identify threats, and mitigate disruption to the business. We’ve all heard that. Things break down when we start to talk about ML more in practice and\u00a0less in theory. \u00a0<\/p>\n

Trust is built through education, testing, and experience. Unfortunately, commercial interests have impaired the situation. Far too often, we see commercial offerings rolled out assuring their audiences they can hit the ground running on day one\u00a0\u2014 without explaining how the artificial intelligence (AI) behind it arrives at specific insights. We call this a “black-box approach.” But more “explainable AI” approaches are needed. We don’t need to be told why to use a hammer. We need to be told how.<\/p>\n

Understanding the “how” comes from practice and learning from others. This points to another fundamental requirement: easy access to ML code with which to experiment and share outcomes and experiences with a like-minded community.<\/p>\n

That door leads us to the open source community. The typical security analyst is coming to the table with a specific challenge needed to be solved in a network environment, such as defending against sophisticated threat actors. The analyst knows how to write rules to prevent a specific tactic or technique from being used again, but he cannot detect the patterns to proactively hunt threats because he does not have the models to dynamically assess data as it arrives. If machine learning can be demonstrated to solve particular use cases in an open forum, more analysts will be willing to adopt the technology in their workflows.<\/p>\n

Sharing code for use and constant alteration by others\u00a0\u2014 and for the good of others and the enterprises they serve\u00a0\u2014 has proved to be a wonderful learning mechanism. Two decades ago, we saw a similar challenge facing security engineers and analysts when few understood how to accurately assess network packets. Then came along Snort, which changed the game. They learned how to assess at their pace, experiment with the codes and models in simple ways, and in time began to trust real-time traffic analysis in the network intrusion detection system. The open signature ecosystem has grown over time into a global effort.<\/p>\n

In recent months, ML code has become readily available in the open source community, offering security analysts opportunities to explore, experiment with, and exchange ideas about ML models, putting them on a path toward easier data pattern recognition. As analysts begin their journey testing out ML codes and models for themselves, here are three best practices to keep in mind:<\/p>\n