Speaker: Scot Lunsford, L534 Department Chief Engineer
What made you look into working with the MITRE Engineering Platform?
Scot Lunsford: We were developing a prototype application that we wanted our sponsors to be able to use during an upcoming exercise. That meant it had to be hosted in a way that was accessible external to MITRE. Normally that process would mean a bunch of extra work for the team, including setting up cloud infrastructure, ensuring all of it was secure, not to mention submitting an external service request with InfoSec. We had a minimal budget and a short timeline to get the job done. When we heard that the MITRE engineering platform already had all these external requirements in place, we were immediately interested. As the software lead for the project, I knew that meant we could focus our efforts on developing the novel aspects of the prototype, and we could leverage MITRE's existing hosting solution in the MEP to deliver faster to our sponsor. Using the map would save us weeks, if not months, of time.
Tell us about your experience working with the MITRE Engineering Platform?
Scot Lunsford: We had a great experience working with the MEP. The MEP team wants to offer a production level experience. That means lots of documentation, a responsive support team, and infrastructure that stays up and running. After our initial meeting, I knew what changes we'd need to make for our application to be hosted in the MEP. For us, this largely meant writing a Helm chart and some Kubernete's resource files so our application could be deployed to one of the MEPs Kubernetes's clusters. We did have one additional requirement. Our application utilized large language models to build a series of AI agents. That meant we needed network access to MITRE's internally hosted AI platform. This connection wasn't something that existed in the MEP when we first approached them, but everyone involved saw the value in making it happen. The MITRE Engineering Platform team and the AI platform team worked together with InfoSec to trailblaze, exposing a network route from our application back to the AI platform's large language models. They advocated for our needs and ensured that we had the resources available so that our sponsor could experience our application, not as a recorded video or pictures on a slide, but as a user from their own workstations. I have a lot of good things to say about the MEP support team. They were very responsive to my emails and Slack messages. They really tried to make sure that I had the information that I needed to be successful deploying our application. I remember two occasions where we were experiencing some weird behavior with our application. Both times, a MEP staff member jumped to help, using logs on their side to help troubleshoot quickly the issues I was having. They maintained a constant line of communication, not just with me, but all their customers through their dedicated Slack channel #MEP, which is a great resource for their customers. This is a team that cares about your success.
What value/impact did the MITRE Engineering Platform provide to you and/or your sponsor?
Scot Lunsford: The key value the map provided us was a platform where we could host our application in a way that was externally accessible. Some teams or sponsors may not realize what an undertaking it would be if they had to create, secure, and get approval for the infrastructure and networking needed to externally expose an application. We recognized that the MEP had already done all that hard work. This was a key value for us, reducing our time to delivery. The MEP connected our sponsors to our application. Allowing them to experience it for themselves. It's one thing to sit in a briefing about a tool's capability. It's quite another to be able to try that tool out for yourself.
What are some lessons learned working with the MITRE Engineering Platform?
Scot Lunsford: One of the many great things about the MEP is that it provides modern infrastructure for a team to use, namely a Kubernetes cluster with a gateway to manage request routing. Depending on the team, this might be more advanced than what they are currently doing. Some projects only run development versions of servers intended only for internal testing and evaluation. Others may be a step beyond that, using Docker and Compose to run their applications in a multi-container environment on a remote virtual machine. Kubernetes takes a team one step beyond that. It assumes you know how to properly containerize the system components of your application. It wants you to define in terms of resources, connectivity, compute, and storage what your application needs in order to run, and then it tries to keep all that in a healthy state. That can provide a learning curve if you haven't worked with Kubernetes before, even more so if you haven't worked with Docker. Our team was mostly familiar with Docker and Kubernetes, so we just had to freshen our memories, but it is something to keep in mind when considering the map as a platform for your application. That being said, the MEP team wants to meet teams where they are at. They truly care about your success and are willing to help teams find and use the resources they need for a successful deployment.
