 Information Security Officer, Ms. Swana Jones-Hee. I'm also here with Jackie from AFRL, Air Force Research Laboratory. We team together to put together this Fast Track ACO process. So, I'm just gonna give a little background. I came up in the Air Force. I joined the Air Force when I was 19. I went to this horrible place called Aviano Gellerby in my first base. And I did from the health desk to a small computer work to I worked this cap, die cap, RMF. We were doing cybersecurity before cybersecurity was a term and before it was sexy. Now it was sexy to get invited to everything and now we're cool. That wasn't the case. So I say that to say I am passionate about this work. Been doing it for a very long time. Now switched over to the contracting side. In this case, I actually own my own contracting company that I support. I am set up to a larger company on this particular project. I'm not saying company's name because it's really not a shameless plug. I say that to say that I don't necessarily need to support this contract. I do it because I really care and I really believe in it. And anybody have kids out here? Anybody? OK, everybody. And so do you remember maybe long, long, long time ago when your kid was trying to take their first step, right? They tried to get up and it was uncomfortable. It failed the first time. It failed very hard. You held the hand. You still shoot it more. You break it back up. And the second time it stood up a little longer. But it failed maybe not as hard this time. Maybe the third time around they walked over to the coffee table and they held on. And then they were able to stand and they were able to walk. And you guys tear them on the whole way, right? Because you believe. You didn't say, hey, kid, you're not going to walk it up. Same concept with this. It's the same exact concept. You have to believe that we're going to take this to the next step. But everybody around you have to be able to hold you up, help you up, encourage you. This process doesn't belong to one person. This process doesn't belong to Mr. Mary. This is our process. And so we really have to believe that we can kind of move this thing forward. I always spend a lot of time on this because just like Mr. Mary said today, he asked that anyone adopt the FastTrack ATO. And then you want to adopt the FastTrack? OK, I think we've got one hand. I think he deserve a prize. Ma'am, you might be asking, where are you from? What, AC? I mean, what? Anyone at home? Oh, yeah, it's perfect. Perfect. Thank you. Are you doing, like, new software development? Perfect. Well, thank you. Thanks for trying something new. Is there any folks from the AO shop here or SEA? Have any ones raised their hand? I know it's the guys who's up here. OK, what about the ISMO or ISSO community? Any of those guys out here? OK, I'm glad to see that. I think, honestly, that the ISMO and ISSO community is probably one of the key players, not probably. They are the key players in this, but we don't give enough attention and information to that community. And that's something that we're starting to work on. So we're going to start this off. I really just say this, though, really for as we go through this process, guys, please remain open. Please allow your folks to try something new. But when they fail, cheer them on and help them up, that really is the key to us being successful moving forward. So this is our next pathway. And so I'll try to move through this fairly quickly. I'm going to be honest. As soon as fast track came out, what we realized when we went around and started doing this road show about fast track is not a lot of people really understand our method. And so it's very difficult to streamline a process that we really don't understand. So we understand and assist on understanding that that's the issue that we are going to work on. We're going to try this with distributed training and reach out, especially to the ISM community, a lot more. And really try to help that community grow from an RMF process. Because what you really see is you really have the authority to do a lot of streamlining with that RMF without this memo that came out. And so anyway, so from RMF now, what happened was we did a lot of research. And we did some things that, side of the words, we brought industry together. We brought some of the PDOs together. And they laid out the process to say, OK, what is wrong with RMF and how do we go to the next level? And so some of the work that you're doing in RMF now, because we always have to coin so turn, it typically doesn't make any sense. But RMF now, we start seeing what were the issues. And I've heard some of those issues this week about governance. And when we say governance, we're saying, OK, Cybers and treaty folks are here making decisions and mission owners are involved, right? That should be the case. The Cybers and the April, we don't own a mission. And so we start looking at, what is that? We look at the risk executive function. How do we bring those folks together? So that's something that we're still working with A3. Culture and communication, just kind of what we talked about just a second ago, is really getting buy-in. Getting buy-in from you guys, really getting to the point where you feel like this is part of you. This is your process. We don't own RMF. SAF doesn't own RMF. Yes, I can give you some policy, but I haven't touched the system since I worked with Sarah Hamilton probably back in Atlanta, which was a long time ago, right? And that's why we did this, my team up with AFRL. And we have the team up with you guys who are out there touching the systems. Automation, we'll talk a lot about automation. You'll hear automation innovation and all those buzzwords and buy-in. So we'll talk about how we're really getting after that. Documentation, I think this week everyone's talking about how bad documentation is. It was like, I really don't even want to touch that. But documentation, but some documentation is still necessary, right? There's going to be some automation piece, but there's going to be some documentation that's still necessary. Though I think a lot of the documentation that we should be having should be doing the system development lifecycle. If you're doing our method, we're just creating all these documents, but I think we've done something wrong with the development process. Also, control standards, looking at different baselines, different overlays, looking at who are our common control providers. When we get those things in place, that's when we're going to help automate the process. Those are the foundations that make it as quick outside of that track. And then again, when we talk about, I'm not sure how many of you guys are familiar with the new 837-2, they added the prepared staff. And so that's by looking at things from an organizational standpoint. And then we're looking at from an organization as well as system level. And what we can take from a staff perspective are all of you guys play from organizations like maybe an organizational enterprise why it continues to monitor strategy. And now you're just focusing on a plan. And that's why you see some of those things like how we're doubt-containing them and those type of things. Those are organizational controls that the CIO has decided that we're going to control that at a common enterprise perspective. That's right. I'll tip over that because we're going to talk a lot about that. And you heard a lot about DevOps and the continuous ATO. And that's the software factory. So that's going to make it as generic as possible. But you can say that's authorizing the factory and everything that comes out of it as an authorization. Oh, that's that clever. Thank you. OK, so I happen to get used to this life that I really want to put my head like that. But I know I don't need to. So fast track ATO, this is the background. Mr. Marion came out with a memo, sent a memo. And larger this year, and many of you may have seen this memo. But it really just was the, it really just said, hey, he's, him and many of the leadership has received a lot of feedback regarding the IRF process. And how horrible it is, and how long it takes, and how much documentation is required. And so I think what he did was there, OK, then I'm going to give you an additional tool in your tool kit to use to help him in faster, right? And so he came out with this memo. And there, you're still going to see there was two additional documentation, the overview of the entire process, as well as a sample decision brief. So just kind of ways to make, different ways to make decisions that's not necessarily based on 150 documents and entering individual controls kind of in IRF. It's kind of where we, I mean, and E-MAS is where we started. But you still have the requirements to meet your, you still have to meet physical requirements you still have to meet, you still have to be sure you are, any overlays, yeah, overlays, those requirements do not go away. And then you still have to register in ICS, as well as E-MAS, and we'll talk a little bit about that because E-MAS currently does not lend itself well to the fast track ATO process. So that's something that we're going to continue to work. I guess the next slide. So I'm going to go over this real briefly. Some of the things you're going to see is we tried, what we did was we put a framework behind fast track, right? And so that you'll see that fast track is does not take us away from RMF. It's a more streamlined approach to implementing RMF. So we're not saying that this is distinct separate, you know, process, it really falls within a RMF framework. And so we've done some work to kind of really lay that out. It's just a different way of thinking of implementing each of the steps. And we'll go into this a little further. Now, fast track we feel really covers that two through five. So a lot of what you do from an assessment standpoint, instead of doing typical kind of documentation, we'll assess security, you know, using things like above, down, or penetration tests. And that's kind of what makes it faster. And some folks definitely feel like it makes it more secure. I think the combination of the both really does make it secure. The other piece I want to highlight this is this is the AO, the AO really defines this as far as that the AO has to agree for your systems to go through the fast track process. The AO is going to define some interest criteria. And so what we've done, and let me also highlight this because someone asked a question to Mr. Marion in the main brief that something similar to they didn't, they didn't adopt fast track because fast track is for kind of the newly developed systems and it's not for the legacy systems, right? And so I think that was the original intent of fast track was our newly developed software that went through this steps that process and was going to be transitioned over to a fair grant approved cloud service offering. That was this original intent. How many people out here are developing new software? How many people out here really focus on the legacy systems? Exactly. And so what happens when this memo went out, it was okay, the legacy system's like what about us? We are the ones that need to use this and we really agree. There's a lot, I think, going on from a Dexel box and Kelso Ron, I think we're getting a lot of marketing and a lot of help in the Dexel box area. And it's sexy, right? It's new, it's sexy. Legacy systems are not so much. And so I think what we try to do with this process is really, really outline how can we develop this same line frame, same framework for our legacy systems because that's what we see. We need the bulk of the help. Next slide. So when Mr. Marion, when this memo came out and it was signed, we did a lot of outreach. We received a lot of comments from the field and this is kind of the answer to some of those comments. We tried our best to implement some of your concerns or most of your concerns in this process, right? So one of the main issues I think that went out, the main issue was that when folks all in memo, they felt the memo was too vague and it was very difficult for people to adopt this because they didn't feel like the memo gave enough direction on how to adopt or what the process was or the intent. And so, and I think from Mr. Marion's perspective, that was done purposefully. It was done purposefully. Their thought is, okay, A.O.s, I'm just gonna give this to you. I want you guys to think about the best way to implement this via system. And so I think it worked well because it did force all of us and especially us career siren folks to really start thinking about color outside the lines. And I think this really kind of gave us that the go ahead to do that. I think there was a lot of questions regarding going away from policy, going away from what DOD has mandated. I just want to assure you guys that we sent this process through General Counsel. We've sent this process through DOD. They actually were very excited. So this has been approved up the chain. So what we've done from a vague perspective, we did try to, we did, we developed some processes. Again, this is where we really have team with AFRL. The staff perspective, we are policy. We are governance. We are compliance. We are not necessarily the technical arm. We are not necessarily the process folks. So this is, again, what we kind of colored outside the lines that we reached out to our partners in both the Air Force and in industry. So we've developed templates. We've developed guidelines, assessment guidelines. We've developed artifact rubric. We're going to go through some of these things further one in a briefing. It was also an issue with folks, especially from an AO community, are saying, okay, you're going to use this process. It can be implemented in EMAZ. How you're taking away my visibility. We heard that loud and clear. So what we're doing now, if this will, with AFRL, after we go through a couple of use cases, we want these legacy systems, we're going to document those work flows and then we're going to make sure that those work flows are available within EMAZ. So you'll be able to adopt this in EMAZ. What we're trying to do is, we're doing everything from a customer experience focus. So we're doing a lot of reverse engineering. So not focused on necessarily the controls. We looked at, okay, what document will answer this control? So instead of saying, okay, let's implement CMV, you may say that, okay, if you've updated your hardware software list, we're going to reverse engineering. We know that this answer 15 control. I'm just being very generic, but I can have a really cool, ugly slide and back up if you want to read. So that's the type of work. So we're thinking through all of that. It's taking time, but it's all in the work. Adversary assessment. I think this was really the crutch. This was an issue that, this was a concern for many. Yesterday we had a separate brief that was specific just to penetration testing. And so we had Air Corral as well as Air Corral, Jessica, she briefed as well as both from Dartmouth. And so we kind of really went into kind of adversarial assessment. The issue there was who are our pentest resources in the Air Force? Is what is considered a trusted advisor? How do we get access to those pentest resources? And so what we've done, we've developed kind of a documental single. We've worked with the DDS Defense Digital Services. They focus on bug bounty and cloud sourcing. We had Alyssa P. O. over to be helping us out with that. And we also have worked with again Dark Wolf now and AFRL. So we've identified at least three resources that we've partnered with to give them access to that. We're not saying by any means that that is the only resources. Not to say that you couldn't go out and work with your own bug bounty team, but if you use one of our partners, they know and they're familiar with the fast track ATO process. And it's gonna make it fast track, the purpose of it is to be fast. So we have to go out and secure additional, if you have to secure additional pentest resources and go through the contract and process, it's not gonna be so fast. And so from cyber hygiene, that was another area. The NEMO focus mostly on the CSF framework. It didn't necessarily speak to controls. I think at the time leadership was really not happy about the term control. So they kind of wanted to push away from controls and implementers are saying, hey, wait a minute, that's our common lexicon. So I think we've really worked hard. I've had to work hard. I think this don't seem to be that kind of, but work hard to say that, using the controls of the common lexicon really is a big step for us. And so you don't wanna take that common lexicon away because really everyone is using it, right? If you're gonna do physical reporting, they link it to controls. Anyone that you're dealing with, if you're dealing in supply chain recent management, they link those requirements to control. So that really is the common lexicon that we're all using. I think it's just that the leadership is concerned because people are saying, I have to implement 1,000 controls and PCIs and we're not putting a lot of fault in the requirement of how we're implementing. But that goes back to not understanding that our map. Yes, sir. Yes, ma'am, we're working a lot of cyber-physical systems. Let's go back to your adversarial assessments. Is there space in there to use wood-team table-topping versus the adversarial assessments? But it's a little dangerous where you're dealing with cyber-physical systems and cyber-physical operations. Is there opportunities for you to do that? Yeah, so I'm gonna repeat the question. I think is, is there opportunity to not only use kind of a pen test, but also using things like table tops and maybe IDMDs and different options with that? Is that the question? Well, this is most of the lexicon legacy systems that are in operation or producing parts, but in ICS types. So it's very difficult to go in there and do a pen testing of something that's creating parts and running it. So is there acceptance of wood-team and paper-topping that we need people in? So I think that we can, I think that's something that we can look at. We do have that from, and I'll get to a slide a little later as it relates to continuous monitoring. We've kind of outlined some things that we can use like a table-topped, different forms of IDMD, as well as penetration testing. Now I think there are also going to be options that maybe you're not doing a live in operational type of pen test. You may have to do some, maybe a test environment, right? If you have the ability to do a test environment as that's identical to your live environment. I don't know if, did you want to add, did you hear that question, Jen? Yeah, so I think it really depends on the discussion with your AOA. Are they going to have a comfort? What's going to be done on the wood-team? Because I understand legacy systems don't always have test environments, and the condition is that you don't want to bring down, potentially bring down wood-tent tests. Having that discussion with the AOA, they may say, okay, present me a test plan. What it's going to look like. Then they'll make a decision from there, but it's hard to say, yes, you can go do this without knowing who your AOA is, and if you're willing to accept it. Answer the question. No, it's not a great answer, but it's an answer. I mean, no, that brings a good point, right? This is not going to be, this particular process is not a cookie cutter process. It really is about making risk-based decisions. It really is. It is really that you have to look at your environment. You're going to have to collaborate across with your PM, with your AOA, with your Scott, to see what's going to be acceptable to them. I know we're working with Ms. Pam Piazza for Pam who ain't here. I think she's somewhere. Thought she should be somewhere here, but so that's the, from an enterprise perspective, right? So APC, and so they are developed in a process using this foundation, but really they're going to develop a process on what they are comfortable accepting, and a process that they are willing, are they willing to accept from their PMs and their ISMs? And so that's exactly right. You really have to think these things through and analyze what works for your environment. So cyber hygiene, and I think that's what we are, we really focus on, again, and then we'll really focus on cyber security framework. So more kind of identify, protect, protect, and find. So that's a high level. And that's important because that's the way that we're really going to have to start communicating to our leaders, but then to understand the importance of cybersecurity. When we go in and brief our leaders and say, hey, sir, you know, RA-7 is red and AC-3 is this, and they're like, what are you talking about? And so one thing we haven't done a very good job in the cybersecurity community is learning how to communicate with others outside of our community. The we understand, but and it's because for the most part, honestly, no one outside of our community in the past have been very interested in hearing what we have to say. And so now we have to learn how to communicate in a compelling way to those folks. And that's why we have some different frameworks like the CSF, but again, that's very high level. You can't just communicate based on that, you know, identify. Really, what does that mean? So it is a lot of, we crossword the arm of controls to the identify category. And then now we can start having those conversations, right, from an implementer's perspective up to the C-suite. And so we also, from a security based non-perspective, we started looking at things in the automation and using things like TANIUM. I know we just saw that again, that memo signed by Mr. Mary and AQ that kind of forced TANIUM to be added on our system, which I think that's a move in the right direction. And so those things like a TANIUM, once we get to the point where TANIUM can match directly to controls, we can do a lot of automated updating of your controls and you're not trying to answer 400 controls on your own, right? That's hopefully in the near future, but we know that that's in the future. And so we're still working that. And then we also work to make sure not only does it answer individual controls, but that it can also roll up and get to that CSF category to say, okay, from a dashboard perspective, I see we have some issues in responding, right? Or recover. And so now, not only can we implementers provide input to that, but our decisions, our leaders can make decisions. It's very difficult to make a risk-based decision based off controls right now from a leadership perspective, okay? And so our workforce knowledge of IRMAP, if I had, I know a thing it's like a blood hole, though everyone has one, I would say something else, but thanks for talking to me. But in my opinion, our major issue in the Air Force really is people. It really is the workforce. It really is training, but a lot of it has to do with the people and getting them information and make sure they're trained and make sure that we don't make this too complex for people. A lot of us are real, this is some real smart folks in here. Very smart. Some engineers, some industry partners. And there's some smart folks out there in the field, but maybe they are not as knowledgeable on this process. And so we make it, right now it's pretty complex for them and it's difficult for them to implement this in the field. And we're seeing that, that folks are raising their hands there. We need help. We don't understand. And so we're finding a way to do distributed training. We're working with DAU to put some training out there, not only from a fast track perspective, but training is gonna help folks kind of understand the foundation of IRMAP and understand their bounds now. You will be surprised really at this level right now in the AO community. You can decide what your critical set of controls are. You can say, hey, I'm gonna do these critical set of controls and I'm gonna give myself a conditional ATO and then from a conditional ATO I'll continue to implement. You are empowered to do that now. But people don't really understand and I understand that we really don't know what's acceptable. So we're working on a risk tolerance kind of baseline from the Air Force perspective to help with, okay, these are our bounds, right? We're also gonna have some start facilitating DCS sessions. I hope that we keep this up. The first three is gonna be focused on fast track, but hopefully we will continue to grow this and as new topics come out, we'll provide DCS sessions so you guys can reach out to us. And honestly, in this process until AFRL came, I was a long ranger kind of developing this. And so it's hard to develop a process and to constantly have to do the communication and have to do the individual breeze. I love it because I love when you ask for a doctor to help us develop a more thorough process. And we love hearing the feedback that you guys, but we have to find a way to kind of do some more, some trainings like this when we get more people involved. I think that was my cue that I stayed on that slide too long. And so, okay. Thank you. Okay, 10 to 20 30. Okay, so we talked about the key to success for fast track is your security baseline, the assessment we're talking about with the PIN test and continues mine. I'm gonna go through each of these, but I just wanna highlight the decision point here. So we're gonna have some form of an interest criteria. We're just gonna give you a template of an interest criteria. From an AO perspective, they're gonna develop that what really, what really fits the bill for fast track, right? What's acceptable. So from a baseline perspective, we talked about this, what are our minimum set of controls? What are we just in that's critical controls? The difference here is what we're saying is not only gonna be the controls done or how we're gonna answer the controls. We may not answer each individual control in fast track. You may have some form of what we're looking at as an executive summary, right? You may answer this control in paragraph form and say, this is how I'm getting after this. You know, I have my seat in place, I get this, this, and this, whatever that may be. Again, we're gonna find a way because we don't wanna focus on documentation. We want you to say, hey, I went through the, whatever, set that process and I'm moving here. So more so kind of explaining to make a risk-based decision. We also have what we developed from an AO's perspective. I think that will help the AO as well as the PM. We'll go to the next slide. It's a rubric, it's an artifact rubric. So what you see here, and we still have our work to do here is we're overlaying like the tool set that'll really help us get after a lot of this. So on the left side, we'll see like, these are some of the artifacts that we're gonna ask for or some of the information, but it may not be a traditional documentation like we're accustomed to. And so this is a way to kind of break what those documents look like from a core to an excellent. So what we're looking at here is it's gonna help from an SCA perspective or from the enterprise perspective. This gives us scalability on the process. It really is good to have a memo where people need to be able to scale this across the Air Force. It needs to be repeatable and people need to be working towards the same goal. And so that's what we're kind of outlining here. This has been through about five iterations since this last week. So not exactly this, but what this also helps you do is once you get to your continuous monitoring where you're looking at these same documents, the AO or the SCA, they'll be able to say am I progressing or am I regressing? And based off that, okay, last time maybe you were at a three plus specific documentation and now you're at a two. So when it comes to continuous monitoring, I may not be able to do that tabletop. Maybe for you, I'm gonna have this little pen test because I see there's some issues here. So that helps you kind of decide again, this is a really, this is a thinking exercise. So it's gonna be making a lot of risk-based decisions. So going back to the scripted slide, we'll see in the ARMA controls column that some of them are golden and those are the FISMA related controls. So we're trying to take a way to focus on artifacts and producing different documents. And although we know documentation is important to understand what your hardware is, what your software is, what does your topology look like? How's data flowing through the system? We want to reduce that emphasis and create a centralized baseline that really focuses on your system engineering documents that are gonna should be produced for you. Some of the legacy systems may have a delta there in the field. It's something we're trying to get away from the traditional documentation piece to go more towards our assessment piece. So understanding what the vulnerabilities on your system are and allowing the SCOT and AO to make and your Pion or information system owner understand what the risks they're taking on with this system, how it looks like right now. So going through penetration tasks, having them go through that painful process with you, but being willing to get better, improve your system, understand where it's at, it's gonna give you an opportunity to learn your system potentially, especially those legacy systems. Having those servers that you don't necessarily know you have, and then all of a sudden they're found during the test, while those servers you didn't know you had were probably not getting patched either. Therefore, they had vulnerabilities. Therefore, there's your attack factor, there's your opening. So the penetration tests are the assessment piece of Vast Track is really to take an approach away from the documentation, say you do things, say you patch the system, actually showing that you can do it, seeing if they can escalate privilege and get rid of your system and exploit data. Obviously, the plan that's developed needs to be screwed up through your PMO or our Pion information system owner or the AO staff is to understand what the boundaries are. What do you need to, you know, or should I not go past? Should I not probably move down the mission? Those are all the discussions that need to be had. So here's a fairly high level workflow for the penetration test. And you're developing the plan, you're going through the test and a report's going to be generated. From that report, it's going to feed into an AO decision-free. It's going to allow you to identify the risks in the system. Where you're weak, where you need to get better. How can you get better? From there, you know, you're going to work with the AO and SCOT and then develop the plan. And if they're comfortable with everything, potentially the ATO. ATO Conditions or Re-Engineering Applying or maybe Fast Track is in the right path. So the next big key to Fast Track is continuous monitoring. So you've had your penetration test and your standardary system is, it's documented, everything's good to go. And then you get a three-year ATO and then you say, okay, it's been good for two and a half years. And then I got to scrub and figure out, oh crap, I got to go patch stuff again. And you actually know where your system has another compromise, I guess you'll find out. That's not a recipe for success. So that's why there's a focus on all these automated tools. You're using automated services as much as you possibly can. Legacy systems, that may not be an option. But we need to develop a plan on how you're going to monitor your system, how you're going to patch your system, how you're going to record metrics. That's one of the key pillars for Fast Track ATO. You need to have a strong staff that's going to be able to do this, willing to improve and really focus on, let's keep your system secure rather than just updating your documents all the time. So on an AO prescribed basis, you may get a, throw this out. This is not a one-size-fits-all process. This is why the communication is important with your SCA and your cybersecurity staff. You understand, I may only get an ATL for a year and next year when I need to renew it, I may need to have another penetration test. Well, maybe not, maybe you just need to provide some scans, updated, your topology, your data flows. Maybe there's a new threat that forms in your system, but you understand it and protect it against it and then present that to the AO. Sometimes there may be an IV and V requirement, so a team come out, sit down with you, understand the system, where it's at, and provide that recognition to the AO. This is really all AO recognition. What we're doing here is, we want to go through this fairly quickly because we wanted to get some time for you to ask a question, but the whole premise behind this is to show you that from a framework perspective, we are still using the RMF framework when we're talking to FastTrack. So it's not that we're getting away from a framework, this is just to pick that this is a different option to get it after an authorization, but it still fits within the framework. So we're still asking that, we're still fit within that CSF construct, though most from a CSF perspective, we're using that from a communication staff, from our implementers to our C-suite and our decision makers so they can make decisions based off this process. So this really is just depicting that. We've kind of talked about some of these documents already that we've developed. We are in the process of really just kind of developing, I want to say a tool set for you guys to use to implement this. I will highlight the fact that with the memo, right now, you are empowered to use FastTrack ATO. If we didn't put a document up here, if we didn't put a workflow up here, you guys can use it as long as your AO is in agreement and your system owner and ISM, as long as you guys are on the same page and you're talking with one another, you can use FastTrack. You can use pieces of FastTrack. You can say, I'm going to have a baseline, I'm going to do pincers and you can call that FastTrack, right? The memo really kind of just says, hey, go out and think differently about this. If we don't move quicker, we're going to be left behind. So it's really kind of get after this quicker. Incapability to the warfighter quicker is the real focus behind FastTrack. So the path forward and take away. So this is some actions that we've taken at the CISO level. Again, we've forced this partnership with AFRL and that we are very grateful to because they came and they really did help the SAC out for your charge. So we appreciate that. And so they helped with developing a lot of the documentation and I think because they touched the system, they helped give us some street cred. And so we've also developed a partnership with DEA. We spoke about that for training. And we're really kind of focusing on, we're kind of going out here, getting with the users so that we can really focus on a user experience, right? How you guys will really implement this process. What type of tempers that you need. We're still working to do that. And they really communicate between the AOs and the PMO. Then we had a question yesterday about, hey, everyone, you're going out here doing this, but what you're just talking to the AOs and the PMs don't agree, then we're not going to be able to implement this, but really it's really a shared responsibility. It's really going to have to be a lot of communication between the AOs staff and the PM staff. And then we want to help kind of facilitate that where we can and we're going to help kind of give foundational training and a tool set. But the decisions are going to come from you guys out there to use this market. So we really urge you guys as much as possible, fail forward, it may not be perfect, but just try it. That's the only way that we're going to get to the next level is trying something new. And so I think, and so I do, we want to leave it open for questions. I think we have 10 minutes. Miss, don't see if you want me to take questions down there. You have to go and wrap up. Okay, any questions? Yes, sir. So how many on-play videos have that excluded or is that a traditional video? That's actually a good question. I know because Pia, did you hear that one? I didn't, I didn't hear what you have to say this morning. Yeah. Great questions. So we have had a lot of questions about the song. I'm sure if you guys heard the question, is again, are we able to use Fast Track ATO for on-plays? So when initially when we put this down, even when you look at the memo, if you look at the overview and everything that was developed, you're going to see on there is saying that we don't want to, we don't think Fast Track is a little fit for on-plays. The reason they're behind that is because if the on-play has to provide, if the on-play has to be a common control provider and systems or applications have to go within your on-play, that's, you're gonna get it, it's a little difficult, right? Because now when a system is coming to your on-play, they are expecting to inherit specific controls from you. And if you have not documented those controls, really how is the system to add to your on-play once you know the ones that inherit the controls? That was our original answer. I would say since then it's changed a little bit. So I guess to say we're on a great area. We're also looking at doing a new case when a on-play because it started making us think again, okay, we want back to the old, R&F mentality really, right? Because that is typically, that's what we want to say. But it's really how can we accomplish that? So with that, we're looking at doing some, okay, let's, we may have a higher baseline for on-plays because you're gonna be a on-play, we're gonna provide common controls. You may identify even what common controls you have to provide. Maybe those particular controls, we might have to do some specific answering of those controls. We can also do some reverse engineering. If you are on-play, maybe we say, if you did a pen test or a bug bounty, and in that case, if the on-play is on-play, maybe you want to go something more, maybe a little more hardcore, like a bug bounty or crowd sourcing, right? But crosswalking that pen test responses and reports back to your actual controls. And that's how we can still answer the controls that you will be providing as a common control provider. The, I was just talking to my boss about this yesterday, but the, this goes back to a risk-based decision. If you are on-play, you're gonna have to make a risk-based decision that if an AO wants to come on my on-play, and they do not accept this process, and they do not accept what we've answered, what we used to answer the controls, and they wanna walk away and not use the on-play, there have to be a risk that we're willing to accept, right? So that goes back to some risk-accepting. And so, yes, we are looking to use this for on-plays, long or short, yes, sir? Yeah, so I was trying to add a fourth comment to the question. I did raise my hand in the structure. Yeah, yeah. I spent three in every life, we just went through this, it works. We went from our initial CV with our AO and our SCA through our AO attendants. Yes, so there we hit it, yeah, okay. Exactly, exactly. If it's our, where, who are you with? Okay. 8-4. 8-4, yeah. And just to caveat it out, we do not know any fellow. Exactly. We are used to getting commercial sacks. Yeah, okay. From the SCSB. The lawful ones, we had to wait two years to live with their IO5. Yeah. They got their IO5 in April, we got our initial meeting with the AO first of May, we got our 8-2, 8-2, 5-2. Perfect. No, and 8-4 is really good, because 8-4 is also one a lot with crowdsourced, they're one a lot with love, family, they are really feeling forward. So we are, thank you, we appreciate it. We have to guess someone is out there adopting, because, and then maybe, I mean, you can start and you can raise your hand again. Okay, so maybe you guys, if you have questions for, let's sorry to push you out here, but if you have questions for individuals who use this, I mean, that's what it's about, we have to help each other, we have to learn from one another, right? So if you have questions, sir, what was your name? Mike Schlapp. Mike Schlapp, let's see, Mike Schlapp. Okay, thank you, sir. Yeah, so that's logistics. Yes, sir. So, so right now, I don't know if any weapons systems, AO, so we don't have any use cases from the weapons systems of AO. So the question was, it seems like it's a more information focused and not necessarily weapons of AO, so it really would depend on the AO and what they have in that boundary, like maybe even some of the weapons systems, I don't know, maybe looking at some of the brown bags, some of the BDSs or something like that, maybe they could use something similar to this. It really just depends on the system and the environment, and you can pull pieces and parts of it. So they may not be able to do all pieces of fast-track, and maybe in some cases, they may not be able to do the automation from a continuous monitoring standard, and we're talking about kind of the scale of folks. So I think it really is kind of just developing that process with the three tenants in mind, but no, we have not had a use case from a weapons systems perspective. We haven't been working with others on this anymore. Any other questions? Yes, sir. So, obviously, you're right now on this file. So the process is like this SCAR and SCA, I mean, talking to the last thing, helping me identify this as a possible candidate, or I can break my hands and say, hey, hey, I think this might work. When I remember the processes, the final process, top-down, I was just like, you know what I'm saying? Yes, absolutely. So the question is, we, really how do you get into this process from if you at the PM level, or you should be working to say, hey, STAA, hey, Sky, I think this is a good candidate, or should the SCI be kind of looking through this portfolio and saying, hey, I think you are a good candidate? I think it's gonna be a little above, but I will say that more than likely, if you wanna use it, it's probably gonna be more of a bottom-up, the same way as if you were trying to decide how you were gonna initially move forward from a RMF perspective, or what controls you were gonna implement. So I would say for the most part, I'm gonna start from a bottom-up perspective, that you say, hey, this is something that we're interested in using. Does this make sense? Would this be acceptable to you, Sky? Now, long as we're going for the use case, we are kind of looking across the portfolios, just from a use case perspective. Now we are in the process of trying to see what are good use cases for the Air Force, and the Air Force does have a little seed money when it comes to this. So within the Ms. Kanasa Berge's boundary, she has money from Dark Wolf that she can use to run some penetration testing, and Air Correl has also agreed to do some use cases and do some penetration testing there. So that's where that seed money will come from, and now we're going to do some use cases. So we will be asking for possible candidates from that perspective. Any other questions? Yes, sir. So how do we plan to implement this training or information into Air Force-wide ISM training? That's the question. I think that's the excellent question, and we know that we have a lot of work to do there. And so that's where we started. Now, again, we're going to start teaming with the DAU, we're going to start with some distributed training, and we're going to start looking from outside of keys, learning outside of you, leaving tech school. What training are we providing our ISMs? You know, and maybe we are providing the ISMs training at a specific level, that's in this, but we want to start looking more into that. But we definitely know that's been highlighted that we need to, so we're working toward that. No problem. Any other questions? Yes, sir. Seeing before we're talking about hardware for the US, this and that, and so on, that's all the fundamental to the candidate, how does that work? And that's not a part of that problem to do with ISM, not just the fast type of problem. Is there a way to see that? Again, I think that whether it's not only with the RMF and with FastTrack, it really goes back to the, we talked about a lot of things via a DAF stuff, some of it may be, okay, when are we using penetration testing? Because you can use pen testing at different levels of the acquisition, you know, process as you're developing. Maybe we're doing some form of a pen test as we're developing and we're looking at those scripts and we're looking at code, right? So we don't necessarily have to wait until the end, but all of this is really gonna have to be kind of put in place by those kind of system developers and the folks at the PN level on how we plan to use it. Yes. I'm a third one. We're doing penetration testing on the internet as a part of this now. Yes. No, I'm thinking what was the documentation about? Okay. How do you document a server that's at a station? Okay. Yes. We agree. Okay. Totally, and I know that now some cool servers going out here, and I think that industry agrees to this too. I thought some cool servers going out there different ways and get a hug and we're kind of bringing in kind of as you are developing and create an automated documentation that feed back to the ism. So there's some cool things from a development standpoint that's kind of going out here and things like servers, but you are absolutely right. I don't think that we have 100% caught up to that yet. In general, not just for that, right? Yeah. Yeah, agreed. Any other questions? Yes ma'am. Thank you. And so everything is posted on the RMF Knowledge Service. So please, that is the Air Force and DOD authoritative source for information and documentation because we have figured out that policy moves very slow and policy can't keep up to how we're moving with our processes. So they move to kind of a more online automated system. So everything that we have in FastTrack will be posted out there. Now from someone asked from industry, from Lockheed, a reference to the documents that we have here, I know this went through a PA review and so my assumption is once the conference is over, these documents will be posted on a FITX, it's gonna be posted online at a FITX if you don't have like DOD cat access to get anything from the Knowledge Service. Any other questions? Did we pass down the sign-in sheet? Okay, so we do have a sign-in sheet out here. If you guys can just sign up, what we'll do is as we have our DCS sessions, we will kind of invite you to those. If you guys are interested in having any further discussion, we are here at TO, well, Wednesday, early morning, but if you can catch us in the back, we do have a lot of the process document. We just don't have enough time to talk about it. We can go a lot more in-depth on the processes. But we're willing to do that if you are willing to provide, yeah, if volunteer review's case, that's what I'm gonna say, but I'm willing to help you guys out. You can provide a lemon drop martini, if you don't, we'll ship it around. Yeah, I mean, so a happy hour, we can discuss this even further. But any other questions, I know we're kind of a little over. Thank you guys so much. We appreciate it.