Read the full post at darknet.org.uk
Read the full post at darknet.org.uk
Microsoft Authenticator is a pleasant enough two-factor authentication app. You can use it to generate numeric authentication codes for accounts on Google, Facebook, Twitter, and indeed, any other service that uses a standard one-time password. The login process is straightforward: first you sign in to each site with your username and regular, fixed password, then you use the code generated by the app.
But for Microsoft accounts, Redmond is offering something new: getting rid of that first password and using just the phone to authenticate. With phone-based authentication enabled, after entering your Microsoft Account e-mail address, you'll receive an alert on your phone. From that alert, you can either approve or reject the authentication attempt—no password necessary.
This same approve-or-reject choice on the phone has been offered previously to Microsoft Accounts, but in the past, it still required the use of the fixed password.
To unleash creativity, my middle school art teacher occasionally offered up all the painting, woodcarving, pottery, and collage resources in the studio, with no guidelines or constraints other than our imaginations and the available class time. The results ranged from the mundane to the inspired. I carved a 3D lobster. (Sadly, no picture survives, but let’s pretend it is as wonderful as the one here carved by Ryousuke Ohtake).
OpenDXL as a Blank Canvas
As an open source integration framework, OpenDXL is like that art studio. Creative security analysts and developers can use the OpenDXL SDK (libraries, classes, and helper classes), the python client, and code examples on github to express their own ideas and activate their APIs. They can build everything from simple productivity boosters to sophisticated conditional workstreams.
Unfortunately, unlike the art classroom, OpenDXL projects aren’t easily visible. So, we at McAfee created a virtual studio, a contest to see what our sales engineers would create with OpenDXL. [We also captured some examples in our new Idea Guide, downloadable here.]
One of the first contest submissions, now published to github.com/opendxl-community, helps solve the age-old malware analysis dilemma: how many sandboxes are enough?
Simple POCs with high value
Jesse Netz, a sales engineer on the East Coast, used OpenDXL to integrate the open source Cuckoo sandbox and the Palo Alto Networks Wildfire sandbox with the DXL messaging fabric and the McAfee Advanced Threat Defense sandbox. These integrations can help enterprises get more value out of their existing resources and share the latest threat data for the fastest detection of emerging threats.
- A Cuckoo sandbox can pull changing malware file reputations maintained by the McAfee Threat Intelligence Exchange and include these reputations in its processing as well as the Cuckoo report. TIE provides visibility into the local prevalence of the file, helping the analyst understand how widespread an infection might be. In addition, customers who have the McAfee Advanced Threat Defense sandbox would see the ATD verdicts appear within the Cuckoo report, enriching the Cuckoo details about what the sample did while executing.
- DXL-integrated applications can use a lightweight DXL interface (service wrapper) instead of the Cuckoo APIs to access Cuckoo sandbox details (socket connections, registry writes, etc.) from anywhere, on-network or off-network. For this integration, Jesse reused a reference example provided in the OpenDXL SDK, the ePO API service wrapper.
- Wildfire verdicts update McAfee Threat Intelligence Exchange’s reputation database with new scores. Any application that listens to TIE reputation scores will get the updated information without having to integrate directly with Wildfire, and can immediately inoculate its systems by blocking the newly identified malware. This example converts verdicts to TIE reputations.
Done in Hours, Not Weeks
The three integrations took a total of about 30 hours, with the hardest part being learning each third party API. Once he had done the first OpenDXL integration, the subsequent ones were much easier. Without OpenDXL’s support for SSL, Authentication, and Authorization, Jesse estimates these integrations would have taken at least twice as long. Now, others don’t need to invest the time learning the Cuckoo and Wildfire APIs and doing point-to-point integrations; they can just leverage OpenDXL topics and Jesse’s new service wrapper.
Looking ahead, Jesse is considering his next OpenDXL development, but we won’t know until he formally submits it to the programming contest. In the meantime, please stay tuned to github.com/opendxl-community for more examples, and fuel your own projects with the new Idea Book.
The post OpenDXL Case Study: Sandbox Mania featuring Cuckoo and Wildfire appeared first on McAfee Blogs.