Transcript:
My name is Rex Steele. I’m a senior security engineer with Moogsoft. I’m in charge of all security and GRC related tasks here at Moogsoft. We are a company that specializes in an AI driven event and IT metric analysis suite that is available in both an on-premise as well as SaaS based configuration.
The Moogsoft application primarily runs on Java and JavaScript with some leveraging of IaC in the form of Terraform and a couple other languages in terms of scripting and support.
The Moogsoft mainline product known as Moogsoft Cloud is primarily deployed through EKS or Elastic Kubernetes Service in AWS or Amazon Web Service infrastructure. We utilize a CI/CD pipeline in order to appropriately test, monitor, and deploy containers in a incremental fashion to ensure that the service is consistently up to date.
The primary focus of Moogsoft security has largely been a reactive nature in attending to issues as they have arisen. Our security team has been looking to shift left and enable both the security team and engineering teams to find problems before they enter production or pre, and ensure that they are resolved in the development process.
In resolving security issues, particularly those in a development state, the security team helps to manage the identification and facilitate the monitoring of the tickets as these are being processed in communications with the engineering and development teams to resolve these issues. Ideally, with the continuing shift to left, the security team will help to facilitate the setup and continuation of tools, but enable the development and engineering teams to engage with these tools directly and resolve security issues without continuous oversight from the security team.
Moogsoft engaged with the Deepfactor platform due to the diverse set of offerings that it enabled us to engage with and implement into our pipeline process, particularly the deep inspection of the runtime and the various dependencies throughout our product, and allowing us to really get a fine-grained analysis of not only what was being used but how it was being used.
One of the most useful tools that we found within Deepfactor was the analysis of the SBOM software bill of materials, which enabled me to have meaningful conversations with my engineers and developers around what was being utilized in the product and what actually needed to be there. Then take that information and have conversations with our customers around why we had certain packages or dependencies within our product and in the way that we were utilizing them.
We deployed Deepfactor across both our development and our pre-production environments to enable us to monitor the way in which we were building out the product and identifying issues as they were arising through the development process. This enabled us to have meaningful discussions around the way that we were building this and tackle issues earlier in the build process.
With the alerting from Deepfactor, we were able to parse through which dependencies were actually being leveraged and called throughout the product, and enable us to tackle the issues and the risks that those generated. Weed out those dependencies that were not being called, though were packaged with other aspects of the product, and enabled us to determine that there was not a risk associated with them, and make sure that our development team was able to apply meaningful effort where it was needed, when it was needed.
Working with the Deepfactor development team, we were able to have a webhook created that we could integrate into the Moogsoft platform, which we also utilized for internal purposes, specifically for security. With this, we were able to forward all alerts from the Deepfactor platform to our own platform, and then utilize that to help correlate against other alerts we were receiving from other security and monitoring tools. The Deepfactor development team was extraordinarily responsive and more than happy to work with us on generating this so that we could get the most value possible out of Deepfactor.