Cybersecurity and Information Systems Webinar

welcome and thank you for joining us for this webinar presentation we are the cyber security and information systems information analysis Center or CS stoppac one of three IAC domains in the dod information analysis centers operating under the defense technical information center d-tick within the office of the under secretary of defense for research and engineering our informative webinar Series highlights current and emerging research and Technology developments it presents an opportunity for accelerating The dod&#39;s Leverage of these advancements by increasing awareness and fostering technical collaboration csix serves as one of the Premier information research partners and curators of technology advancements and trends for the cyber security and information systems community as such our organization supports those working in the cyber security and information systems domain of DOD research and engineering we do so by helping navigate the vast landscape of scientific and Technical information allowing our customers to get a head start on their technical projects with an understanding of the cyber security and information systems DOD research and Engineering landscape we provide research and Analysis services we help unlock access to information knowledge and best practices from government industry and Academia to stimulate Innovation Foster collaboration and eliminate redundancy we hope you enjoyed this webinar presentation and that it serves as a catalyst for Community collaboration and improved DOD cyber security and information systems research okay good day everyone hopefully everybody can hear me uh thank you very much for tuning in to today&#39;s webinar uh just for a couple of administrative items real quick uh the chat is open for everyone uh but the everybody&#39;s microphones are muted so if you need to uh if you&#39;re free to check some chat amongst yourselves uh chat to myself um and uh or the presenter and um we should be able to see it but if you do have a specific question uh there should be a menu kind of a three dot ellipses menu on the bottom right hand side next to the chat that will open a q a and if you have a specific question uh we asked that you posted in there and at the end I will read it to the presenter for uh for the Q a session at the very end with that I I&#39;d like to go ahead and introduce today&#39;s presenter who uh I just uh passed the presentation over to to you uh so you should be able to start sharing your screen um but today&#39;s presentation is is on the system security engineering cyber guidebook and it is being presented by Katie whatmore who is a systems engineer at the Cyber resiliency office for weapon systems at Wright-Patterson Air Force Base Ohio responsibilities of our current duty position include leading system security engineering team of diverse Engineers computer scientists and acquisition security Specialists to provide SSC guidance to the Department of the Air Force she&#39;s responsible for the content within the daf SSE cyber guide book as well as the technical content in Associated training so with that I can see your slides Katie and if you want if you would like you can take it away all right so hopefully you can can you still see my slide I had to switch back to unmute myself I could I could I could say it all right so uh good afternoon everybody thank you for joining um during that intro video it was really interesting hearing a bunch of the comments about collaboration and uh eliminating redundancies and things like that um because that&#39;s exactly what we have tried to do uh in developing the system security engineering cyber Guidebook so um hopefully as I share with you about that today uh that will shine through and um hopefully you&#39;ll be able to see how you can use the information we have in the guidebook uh in your day-to-day job uh the other thing I want to mention is uh if you were able to attend the webinar last month um you were able to hear about the Cyber survivability endorsement implementation guide and the 10 cyber survivability attributes uh what&#39;s really cool is that uh this this briefing builds off of that um the requirements from the CSA csas are decomposed and actually translated into system level requirements within the SS ECG so we&#39;ll get to that but just wanted to kind of put big picture if you were here last month that&#39;s how those things kind of tie in together so moving forward if you have never heard of the crows the Cyber resiliency office for weapon systems uh we&#39;ve been around now for a little bit of time um started back for during the the Cyber campaign plan um and ultimately we&#39;re focused on how do we get uh you know how do we get or improve weapon system cyber security so from there we established our mission vision and goals which are are still the same today um ultimately we want to increase the Cyber resiliency for both the air and the space force by baking in and being able to bolt on uh mitigated uh vulner or mitigations for vulnerabilities um and we want to do all of that by trying to change the culture of the Air Force and the space force by not thinking of cyber is something as an after the fact uh problem that they have to address rather as addressing it as part of just overall systems engineering right it&#39;s another discipline that falls underneath systems engineering so if you have any any questions about the crows as a whole uh I can certainly try to answer those at an end at the end but that just gives you some high level uh overview of of what it is that we&#39;re trying to do as an organization so change the culture uh and and get things addressed as part of systems engineering so why did we create a guidebook um the reason we we did this is because as we started to pull apart the problem we found uh just thousands and thousands of pages worth of policy and guidance that people in the program office are expected to do uh are you know um required to do statutory regulatory requirements Etc and so what you see here on this slide is a summary uh that&#39;s not all inclusive but a summary of the the big players um that my team has gone through where we have uh tried to consolidate and deconflict um streamline the Redundant information and pull it all together in a best practices guide book which includes a process Katie can you uh can you hear me it looks like your audio cut out all right apologies everybody uh it looks like we lost audio from what was that can you hear me yeah can we get I can hear you now we lost you for uh about 30 seconds there okay um all right so not sure where you lost me but um bottom line well you cut out again might be a problem with your microphone is it still not working I can hear you now but it it cut out again just a minute ago just a second ago hmm I&#39;m not getting any errors I mean I can hear you okay now maybe try to push it so I will just go on to the next slide so the system security engineering cyber guide book we just published version five in uh February of this year version five unfortunately is still listed as distro D um and so if you want a copy of that you can request it um but we&#39;re not able to publish it publicly yet um because it&#39;s still going through the the public affairs review so hopefully we get that approval for version five we did have a distro a approval so you can uh probably very easily find the the version 4 guidebook out there um if you do have access to the the Air Force Portal you can go to the crows Air Force Portal page and version five is on that page that is CAC enabled um so anyways what is the guidebook uh the guidebook is uh it&#39;s it&#39;s still pretty large so if you open it for the first time it is uh approximately 500 pages or so um but that that&#39;s better than 20 000 plus pages of policy and guidance right um so how do how do you use this 500 pages of information um it&#39;s not meant to be a cover to cover read uh the first 50 pages or so is the main body of the document that&#39;s where we have the executive summary that&#39;s where there is the workflow process itself that includes a detailed work breakdown structure which we&#39;ll get to um and then from there the the bulk of the document our supplemental appendices and I&#39;ll talk more about these appendices as we move forward but the idea is that given where you are at in the acquisition life cycle you may be at a point where you need guidance on writing requirements in which case you would go to appendix a you may need guidance on how to do um you know how to how to decompose your requirements more clearly from you know your CBD to uh your your actual system level requirements right so how do we compose that capability and maintain traceability and that&#39;s where maybe appendix C might come into play um and so we&#39;ll talk about that as we move forward but again it&#39;s not meant to be a cover to cover read it is meant to uh go where you were at within your acquisition program and find out where you can jump in and start making the best use of these uh recommendations and best practices so this is just a slide that highlights some of the collaboration and endorsements that we have through various organizations um the SSC cyber guidebook was not put together just by the crows we have had partnership with um all of the centers across the Air Force as well as space force as well as navair uh their cyber warfare Department we have also worked very closely with industry through ndia the system security engineering subcommittee um and then just uh what was it well I guess it&#39;s been a couple years now um I guess this memo was resigned out in 2019 um but we we got the memo uh coming from the four uh air force center commanders saying that you know they encourage the use of the sscg to make sure that that the RFP language is appropriate appropriately addresses system security engineering so here is a snapshot of the workflow process itself um and at a very high level the next couple of slides I&#39;ll walk through just kind of big chunks of it so what you&#39;ll see over here on the left this is where the bulk of the heavy lifting comes in within the SS ECG um and that&#39;s because if you get your requirements on contract and you get your requirements right then the rest of the things kind of fall into place because you have the requirements there so we spend a lot of work uh providing guidance on how to make sure that you understand your system you understand the scope you understand the boundary um and you can start applying for system security engineering requirements to the appropriate areas of your system so that you&#39;re optimizing Your Design solution right because we all know that there&#39;s a trade space there um between performance schedule budgeting um and then there&#39;s also you know size weight uh you know all those different constraints that we have to work within and so um this helps this this area of the guidance helps provide a way to to basically have um informed decision on on the trade space and how to make sure that we&#39;re addressing the most important parts of our system so as you go through this process uh as I mentioned there&#39;s a work breakdown structure so if you were all the way over here on the left and you were at the very first step the very first step in this process says form a system security working group okay so how do I do that well you can go and look at the work breakdown structure and there&#39;s a a table within the ssecg uh and you can see the the detailed information that we have in there we have sub steps to those boxes uh so um you can see the sub steps in there there&#39;s a description of things that you can do uh so for this uh for example there&#39;s recommended uh Personnel to include in your working group if possible there&#39;s artifacts that this step might inform so as you&#39;re forming your sswg that&#39;s going to help populate some of your program protection plan um and then there&#39;s also additional references there so if you want to go and try to read through the policies that relate to this particular step uh those are right there for you to take a look at as well the other big thing with uh this upfront section um appendix a primarily applies to all of this upfront work um as well as some of the the systems engineering work that we&#39;ll talk about in a little bit but appendix a addresses these these areas seen here uh the biggest thing to to note is that there is tailorable uh statement of work language there is tailorable system requirements uh language as well that ties back to or has been decomposed from the 10 cyber survivability attributes um and then there&#39;s also a bunch of guidance on how to make sure our overall systems engineering type of documentation actually has system security engineering integrated throughout it um so for example when you&#39;re looking at appendix a and you go and you&#39;re you&#39;re in section two and you&#39;re looking at the the cell requirements you&#39;re going to see sample language along with that sample language you will see uh seadrolls called out so for that paragraph a that you see on the right there you see cedral one sedral 10 called out at the very end of appendix a there is an attachment that has a sedral table in it so it has the corresponding seed Rolls by name for these paragraphs it has the corresponding data item descriptions that can be used to put that cedral on contract as recommended delivery schedules Etc um and here is a snapshot of that Seadrill table so um you can see that if you were in paragraph 2.3.2 a it called out Sidra one Sidra 1 is the program protection implementation plan uh and so you can go and look up a data item description listed here and as you&#39;re you&#39;re filling out um or you&#39;re getting all of the contractual documents prepared for your request for proposal you can make sure you have all of that documented appropriately um so I think there are approximately right now um maybe 40 seadrolls or so caught out in the table again it&#39;s tailorable so uh you can choose which ones are going to bring the biggest value to your program but they&#39;re at least all presented for the system requirements there is uh an attachment within appendix a and there&#39;s an embedded Excel sheet within that Excel sheet there are multiple tabs at the bottom which you can see kind of highlighted here in red the very first tab is called the the system requirements worksheet which is uh the tab that has very high level requirements um I think there&#39;s like maybe I don&#39;t know there&#39;s maybe like 20 or so on that first tab um I forget the actual number off the top of my head um but they&#39;re higher level requirements and then what you see after that are additional tabs that have that focus on each individual CSA so for example if you know that you need to address csa1 you could click on csa1 and there are the parent requirements that are listed on the system requirements worksheet but then there are also decomposed requirements that take it a little bit further down a little bit more detail and so you can look at those as well um again these are tailorable so as you as you look at them as you read through them uh a lot of times you&#39;re probably going to need to add additional information um to them to make them applicable to your weapon system uh but it at least gets you thinking um kind of in the right direction and get those first steps taken um one thing worth noting is that as you are working through the soc CG process all of the areas highlighted here in in are shaded in that gray grayish blue color these are the areas of your program protection plan that the ssecg process is going to help you populate so it&#39;s either going to um so for like section five threats and vulnerabilities and counter measures there are very specific sections within the ssecg that call out uh getting threat information Intel information and using that to understand your vulnerabilities so that you can do risk assessments and when you do risk assessments then that leads to coming up with mitigations and mitigations or just countermeasures right um so that&#39;s just one example so all of these sections within the PPP are uh populated by by following this process so moving forward if you look at the right side of the workflow this is really where we get into I think where most of us spend our day-to-day and that&#39;s just living living the systems engineering acquisition life cycle so whether it&#39;s going from one systems engineering tech review to another whether it&#39;s um you know going from Milestone to Milestone um if you&#39;re doing any kind of the Adaptive acquisition framework um that&#39;s where all that falls in and gone through all of that in order to get to your verification validation and then ultimately into Fielding um so that that&#39;s what happens um I guess let me go back that&#39;s what happens in that area um I don&#39;t have uh slides on the details there but what I will say is that uh within appendix a there is information on uh entrance criteria that should be included in your RFP as far as the systems engineering technical reviews go and what this does is it helps ensure that as you&#39;re approaching these technical reviews which are essentially you know decision points um you know to proceed on and continued development um whether or not you&#39;ve actually addressed the the system security engineering concerns uh adequately so um by putting that in there that makes sure that uh the program will address those instead of waiting until it&#39;s too far down the line um and and more costly one thing you&#39;ll see is that this process is very heavy on risk assessments um and that is by Design so um you want to do risk assessments early often throughout the life cycle so that as the design is maturing as maybe the threat or Intel information uh changes because we all know that cyber is a very Dynamic environment to be working in um we&#39;re staying up to date and we&#39;re saying as informed in our decision making as possible um ultimately trying to reduce the risk um and and what that means is going to be dependent upon your program right like what an acceptable level of risk is is going to be dependent on the program dependent on the mission uh Etc so I added this slide in kind of at the last minute um a lot of people when I I talk about the ssecg process uh bring up RMF um and the purpose of this slide is at a very high level um to show you that by doing the steps within the ssccg just like for the program protection plan you are going to be generating the data needed to uh develop your authority to operate package your ATO package so what that means is that if you are doing this process along the way when the time comes to actually submit your ATO package it&#39;s not going to be scrambling and trying to pull together documents and make sure that you have everything documented appropriately because you will have gone through and done the analyzes done the risk assessments everything will have been documented along the way and so at that point in time it&#39;s really just going to be compiling the data in whatever format you&#39;re authorizing official needs to see it in um another thing I want to talk about is appendix C and D within the SSC cyber guide book um these two appendices are in my opinion really really important and actually are going to kind of lead into the the next month&#39;s uh webinar which is going to be provided by Miss Sarah standard and focus on Cyber tne um but appendix C and D are focused on the the functional threat analysis which the main purpose here is to decompose the system starting all the way up at the mission um and and there&#39;s been a lot of discussion on what is the mission is it you know Big Air Force Mission or is it platform Mission and and that&#39;s really at the program level that&#39;s for you to decide where you want to um start your your breakdown but being able to look at that mission Trace that mission to the capabilities within your CDD which then should be traced to the csas that that uh are in the cscig um from there you&#39;re going to want to decompose those capabilities into actual system requirements and from your system requirements right you&#39;re going to have different levels of fidelity as your design matures and you&#39;re going to go from uh you know functional requirements to actually allocated system requirements Etc but if you follow the process outlined in appendix C you are going to have that traceability from whatever the lowest level you are currently at all the way back up to the mission you know it&#39;s going to be a bi-directional traceability and that&#39;s really important because uh one it ensures you know that we&#39;re not implementing uh cyber counter measures just because it&#39;s a good idea we&#39;re we&#39;re implementing them because they have impact to our overall mission um and so uh the work done in appendix C also leads into having the information needed for your attack path analysis so that moves into appendix d um appendix D takes the information that was developed in the functional thread analysis and it starts to look at how the system could be attacked right um how how entry could be gained into the system where there&#39;s potential vulnerabilities Etc um now appendix C and D are pretty important because uh as the as the test Community has mandated the use of mission-based cyber risk assessments appendix C and D fulfill uh the intent of a mission risk cyber-based assessment and mbcra so um if you are following the guidebook and you&#39;re doing these things then guess what by the time you get to DT you&#39;re going to have the information needed about your system so that the developmental testers are going to be able to move forward with the tests that that have been planned for your system as opposed to trying to go back and ReDiscover the the information that they need um so with that um that that is a I said through that brief um I&#39;m hoping to have some questions and discussions um so with that I will pause and see if there are any questions so far yes yes uh so there are several questions in the chat and uh uh so I&#39;ll go through them and it looks like some of your colleagues have been answering some of the questions uh and one thing I will point out is that Catherine holder posted that if anybody would like the uh ssecg version 5 sent to them they can email her and her email address she posted in the chat but it&#39;s Catherine k-a-t-h-r-y-n dot holder h-o-l-d-e-r dot for the number four at us.af dot mil says catherine.holder.4 us.af dot mil uh you can send her a request for a copy of version five and as long as you&#39;re able to receive it she will send it to you via DOD safe [Music] um so a few of the other questions that came in that I I don&#39;t think have been answered in the chat uh uh first one is simply is the Army using this ssecg um so good question um we so let&#39;s see am I I am still presenting um so the uh this is sorry this will be a little bit of a detour answer so back in 2018 the government audit agency basically came out with a report that said none of the services are addressing cyber security for weapon systems within their requirements documents and so there was a go do uh out of that GAO report for all of the services to basically start addressing that what we&#39;ve done in the ssecg is the Air Force&#39;s response to that initial GAO report in 2021 they did a follow-on report and you can read some of the excerpts here um but basically what came out was that uh still to date the crows and the Air Force are really the only service that has provided this level of specific guidance and they actually recommended that all of the sister services do something similar um what I can say is since 2021 and and even prior to we have shared our guidebook with the army with the Navy um and the Navy is standing up some very similar processes within uh their their service I believe the Army is as well um but but what I will say is that even though the ssecg uh has been developed by the department of the Air Force uh there may be some I guess what I&#39;ll call Air Force isms in there right like some Air Force specific things but for the most part um it is written at a high enough level that it could be applicable to any of the services um so you know some of the stuff that was derived from Air Force instructions may or may not be applicable to the Army um but as far as the the tailorable requirements and things like that go uh the Army can certainly um you know take it and and borrow what they want from the ssecg as they move forward all right thank you uh the next question there was some people discussing this in the chat so but I&#39;m not 100 sure if the question itself was answered so uh the question is do you offer a list of known vulnerabilities for a set of Technologies often used in Solutions wow that is an excellent question um so I I do not think at this time we have a list like that that exists what I what I do know is that uh part of our organization part of crows we have um a team that looks at uh I guess kind of just generic uh vulnerabilities that could apply like um to multiple weapon systems right and from there we go we go out and we research mitigations and so we do have a document um called the mitigations handbook that is on the classified side and if you&#39;re interested in that again as you reach out to Kate for the ssecg uh throw that request in there as well and then Kate we can um we can compile a list of names that would like to see uh that document the mitigations handbook and we can get that over to uh the team to get that supplied to them um that&#39;s that&#39;s where we&#39;re at today and I know Joe typed in um about the the vulnerabilities database um but as far as crows goes we don&#39;t have something that we maintain for that okay great thank you um let&#39;s see another question uh who do you see being the Billet assigned to do these tasks the issm a dedicated SSE uh the PPS I&#39;m sorry I I&#39;m not sure of all the acronyms so I I hope they&#39;re familiar to you sure um so that&#39;s an excellent question um and again uh coming from um the at least for the Department of the Air Force part of crows is has actually provided that manpower to our program offices through what we call our cyber focused teams our cfts So within each program office we have positioned a cyber focused team lead as well as other cyber focused team members to be that cyber Smee to be able to support programs as they navigate through uh their their cyber terrain for lack of better words um now that being said not everybody is going to have a cyber Focus team that&#39;s readily available right sometimes smaller programs may not have the help that they need um and likewise maybe larger programs are like hey we got this under control we&#39;re doing it by ourselves um in which case then ISM could be somebody that does this it could be uh if you if your program has a system security engineer actually billed it for the program um they are somebody that could be doing it uh but I think in in standard engineering fashion I&#39;ll give you the it depends answer um so hopefully that helps and if you need more uh information on the Crow&#39;s cyber Focus teams um again please feel free to reach out to me and I will help get you the information that you need based on either what programs you support or anything like that all right great and another question uh do you have an overall mapping from RMF to the guidebook uh I work in an area that doesn&#39;t use the same procurement processes and we&#39;d like to see how we can apply portions of the guidebook to our processes um yes give me just a minute I am going to share a different screen um this is the one I want to share okay so um this is the slide that I had up earlier um and what I want to point out is that within the ssecg appendix f i I&#39;m sorry I did not talk about appendix F and it&#39;s one of my favorites because um appendix f is the relationship to other processes so appendix F will discuss how by doing the ssecg you&#39;re going to meet uh test and evaluation needs by doing the sscg you&#39;re going to meet these RMF needs and we actually have the discussion on um really how and why those things uh you know are in alignment or complementary of one another so here what I did was I I really just kind of tried to break down that section of appendix F that talks about RMF and the ssccg and pull it out into some slide pictures so uh this is the slide that you saw before within appendix F we also have this slide which is just the RMF process right this as a refresher is just the sscg process and then what we have a very very explicit detail this is obviously an eye chart um but this is a table that we have that&#39;s that&#39;s much more readable in the guidebook itself that goes through every one of those boxes on the the slide two that I showed you for RMF and traces them to um a step within our work breakdown structure in the sscg what I point out on this slide is that there are only these these two steps or these sorry these three steps um that do not have a direct Chase trace to the ssccg um but I think that uh some of that p7 I think um actually that we might need to look at that one a little bit more closely um because I do believe we have some stuff in there for uh continuous monitoring um but so hopefully if you take a look at that section that that might help you with that traceability question all right great um another couple questions um is there anyone from the space that you are working with um yes so we do have um I do not have names off the top of my head um but we do have Representatives um that we work with out at space we are in the process of trying to hire a cyber focused team members to directly support the space force um we have a let&#39;s see I believe uh Kate is actually miss holder is actually meeting with SSC the space systems command a couple of folks tomorrow to give them kind of the same rundown of of what the guidebook is and how the crows can can help them out so um if there are more specific questions on how space can get help from crows please reach out to me directly and um we can have that follow-on conversation wonderful uh another question are you seeing any work in the leverage or sorry are you seeing any work to leverage and BSE slash D bottle-based systems engineering slash digital engineering to support FTA and attack path analysis absolutely um so the crows has been funding the development of two separate tools that will directly uh impact that area so one is the Assurance tool and the other one is the CSA Tool uh the CSA tool is is very near and dear to my heart because I&#39;ve been working with that development team for a couple of years now um and and the tool has really started to to grow into something that&#39;s going to be very beneficial um that tool starts by um actually taking all of the the CSA language all of the requirements that are in the ssecg um nist controls uh basically they spent a lot of time pulling in all of the the backbone um information needed to build a model uh from an SSC perspective of your system um so that you can have that requirements traceability so the CSA tool will provide uh basically the the SSE inputs to your request for proposal package um if you would like a demonstration on the CSA Tool uh I can get with the program manager of of that and and we can schedule um some kind of demonstration they&#39;re they&#39;re always willing to give demonstrations of the tool um but from there uh my so we actually have the the CSA and the Assurant team um are doing a workshop this week uh to work on integration stuff so from there uh we are in the process of making sure that the CSA tool and the Assurance tool can talk to one another because ideally the model built in uh CSA tool will be able to be exported into assurance and then the Assurant tool will able be able to run an attack path analysis to be able to help identify those potential vulnerabilities within the system um we are working to have that communication of Assurant and CSA bi-directional so that say we run an analysis in Assurant um that Assurant can then uh export its findings back out to CSA and CSA can you know make whatever requirements modifications if necessary um and and that we can then export it back run the analysis again see if we&#39;ve done some mitigation so um that is right now uh our biggest focus in the mbsc uh de Arena as far as it it relates to cyber great um next question and still got a few more coming in so um our atos and cras transferable between all defense branches or our risk assessments environment dependent um I don&#39;t know if I am qualified to answer that question um that would be honestly I think that would be up to the authorizing officials so like if you were to do say you&#39;re working I guess a joint program right um if you were to do like the processes within the ssecg would the Navy accept that risk assessment um I would I would tend to believe if you can show the The Sound Engineering and due diligence behind the assessment that yes it would be accepted um but I don&#39;t know that uh for fact so that would be something that you would have to probably follow up with your AOS on all right uh this question I you may have addressed it another answer but uh I&#39;ll ask it anyway do you address how to define measurable requirements in the requirements the decomposition to an extent so uh recall I did say that these um requirements are uh tailorable so um that&#39;s really where the measurable part comes in so um like if you&#39;re gonna say there&#39;s a requirement for um restoring back to a known baseline or or like so one you detect in an anomaly you have the the requirement in there to detect anomalies okay great um there&#39;s probably some kind of time requirement that you would want associated with that right and so that&#39;s where your program uh specifics are going to come in and and that&#39;s where I believe uh Miss standards brief next month is kind of going to pick up from where this briefing is leaving off foreign okay great uh next question is simply do you use EMASS yes EMASS is a uh called out in the ssecg um and I know that that uh our cyber Focus teams are aware of how to use EMASS Etc okay and then uh the next kind of two-part question comes from somebody who is the person that asked the previous question on uh mapping from RMF to the guidebook uh yes how about mapping how the nist controls are accounted for I see how some are accounted for but not others and can you share the more detailed slides with the RMF mapping uh yes I can share those slides um and I will uh what I&#39;ll probably do is send those to Phil and let Phil figure out how to send those out um if that&#39;s all right um that&#39;ll work yep okay so um let&#39;s see uh mapping back to the news controls yes um so what we did when we wrote These system requirements um those requirements were written it&#39;s been it&#39;s been quite a few years now because we&#39;ve spent the last couple of years developing other content within the sscg so when those requirements were first written we were using nist uh 800-53 version 4. I know version 5 is out there now um but what we did was we used the uh aircraft overlay for the nist controls we looked at um the requirements that were on or the controls that were called out on that aircraft overlay and then we pulled those requirements or we looked at those controls within this and we translated those requirements into or we translated those controls into actual requirements it is important to note that those controls are always supposed to be translated into requirements language unfortunately uh I think we&#39;ve gotten in bad practice of not doing that um but within the Excel sheet if you scroll over to the right um you&#39;ll see the mapping to what Mist control that satisfies now going back to that CSA tool that I was just talking about if you&#39;re using that tool the mapping is already done in there for you so if you select a control it&#39;s going to pop out the requirement that&#39;s corresponding to it if you select a requirement it&#39;s going to pop out and show you what control that correlates to okay um the next question simply does your guide apply to an industrial control systems um so it was developed specifically for weapon systems that being said uh I don&#39;t think there&#39;s anything that precludes it from not being used for those kind of systems again it&#39;s all tailorable okay great uh I think I got all the questions that are in there uh right now um I&#39;ll just point out and get to give people an extra minute if there is a last minute question uh the slides a few people asked about where the slides are available if you go to the csiac.org website uh click on webinars find today&#39;s webinar the slides are there and then when the uh when the webinar goes up on YouTube should be there by the end of this week uh you can also get the YouTube link from that very same uh website or just go to the csiac YouTube channel um uh supersonic uh there&#39;s one more question superset Lynn wallet oh did I miss a question up here okay so there was one more question I I must uh missed this question would you say that you haven&#39;t accumulate how you have accumulated and documented the superset of activities that a program should do during the system life cycle was that your intent can you ask that again uh the way reads is would you say that you have accumulated and documented the superset of activities that a program should do during the system life cycle was that your intent um it&#39;s a super set I would say it&#39;s a comprehensive uh set of activities that um if you were going through the most rigorous you know standard waterfall approach development cycle that you should do that being said if you&#39;re going through uh a devsecops or you&#39;re going through some kind of accelerated acquisition Etc uh there are ways to tailor the process uh to go faster um but at the same time we have documented um I guess what what we would recommend as a a bare minimum of things to do dependent upon which pathway you&#39;re going um so I hope that helps answer yeah uh yes and then uh one last question will this be used for a new or an existing program or both it can be used for all of the above um and that&#39;s why what&#39;s uh what&#39;s interesting about when you look at um the workflow process itself you will see that it&#39;s not aligned to milestones and the reason we did that is because regardless of if you&#39;re a brand new system you&#39;re um an upgrade to a system you&#39;re like a 1067 where you&#39;re you know bolting something on uh you still need to go through all of those upfront steps of understanding if it&#39;s a brand new system obviously you have a lot to to understand and uncover there if you&#39;re bolting something on you still need to understand what is your system what is your system boundary how does this impact you know if I bolt this on here what does that do to the rest of the system and so you still have to go through all of that um analysis and understanding of your system you still have to go through putting stuff on contract uh and and you still have to go through you know doing whatever kind of reviews to get to decision points and so that&#39;s why um we kind of set set the process up in the way that we did all right great well thank you so much Katie that that looks like it&#39;s the last of the questions uh and I thank you for the wonderful brief um I&#39;ll I&#39;ll send you the the chat history just so you can see the number of people that said what an outstanding brief you you provided uh this was great uh great with the question question and answer portion so thank you so much and thank you to everybody that joined us today I&#39;ll go ahead and close it out here I&#39;ve already told people how to get to the slides into the YouTube video so again enjoy the rest of your day and enjoy the rest of your week thank you so much all right thank you

welcome and thank you for joining us for this webinar presentation we are the cyber security and information systems information analysis Center or CS stoppac one of three IAC domains in the dod information analysis centers operating under the defense technical information center d-tick within the office of the under secretary of defense for research and engineering our informative webinar Series highlights current and emerging research and Technology developments it presents an opportunity for accelerating The dod&amp;#39;s Leverage of these advancements by increasing awareness and fostering technical collaboration csix serves as one of the Premier information research partners and curators of technology advancements and trends for the cyber security and information systems community as such our organization supports those working in the cyber security and information systems domain of DOD research and engineering we do so by helping navigate the vast landscape of scientific and Technical information allowing our customers to get a head start on their technical projects with an understanding of the cyber security and information systems DOD research and Engineering landscape we provide research and Analysis services we help unlock access to information knowledge and best practices from government industry and Academia to stimulate Innovation Foster collaboration and eliminate redundancy we hope you enjoyed this webinar presentation and that it serves as a catalyst for Community collaboration and improved DOD cyber security and information systems research okay good day everyone hopefully everybody can hear me uh thank you very much for tuning in to today&amp;#39;s webinar uh just for a couple of administrative items real quick uh the chat is open for everyone uh but the everybody&amp;#39;s microphones are muted so if you need to uh if you&amp;#39;re free to check some chat amongst yourselves uh chat to myself um and uh or the presenter and um we should be able to see it but if you do have a specific question uh there should be a menu kind of a three dot ellipses menu on the bottom right hand side next to the chat that will open a q a and if you have a specific question uh we asked that you posted in there and at the end I will read it to the presenter for uh for the Q a session at the very end with that I I&amp;#39;d like to go ahead and introduce today&amp;#39;s presenter who uh I just uh passed the presentation over to to you uh so you should be able to start sharing your screen um but today&amp;#39;s presentation is is on the system security engineering cyber guidebook and it is being presented by Katie whatmore who is a systems engineer at the Cyber resiliency office for weapon systems at Wright-Patterson Air Force Base Ohio responsibilities of our current duty position include leading system security engineering team of diverse Engineers computer scientists and acquisition security Specialists to provide SSC guidance to the Department of the Air Force she&amp;#39;s responsible for the content within the daf SSE cyber guide book as well as the technical content in Associated training so with that I can see your slides Katie and if you want if you would like you can take it away all right so hopefully you can can you still see my slide I had to switch back to unmute myself I could I could I could say it all right so uh good afternoon everybody thank you for joining um during that intro video it was really interesting hearing a bunch of the comments about collaboration and uh eliminating redundancies and things like that um because that&amp;#39;s exactly what we have tried to do uh in developing the system security engineering cyber Guidebook so um hopefully as I share with you about that today uh that will shine through and um hopefully you&amp;#39;ll be able to see how you can use the information we have in the guidebook uh in your day-to-day job uh the other thing I want to mention is uh if you were able to attend the webinar last month um you were able to hear about the Cyber survivability endorsement implementation guide and the 10 cyber survivability attributes uh what&amp;#39;s really cool is that uh this this briefing builds off of that um the requirements from the CSA csas are decomposed and actually translated into system level requirements within the SS ECG so we&amp;#39;ll get to that but just wanted to kind of put big picture if you were here last month that&amp;#39;s how those things kind of tie in together so moving forward if you have never heard of the crows the Cyber resiliency office for weapon systems uh we&amp;#39;ve been around now for a little bit of time um started back for during the the Cyber campaign plan um and ultimately we&amp;#39;re focused on how do we get uh you know how do we get or improve weapon system cyber security so from there we established our mission vision and goals which are are still the same today um ultimately we want to increase the Cyber resiliency for both the air and the space force by baking in and being able to bolt on uh mitigated uh vulner or mitigations for vulnerabilities um and we want to do all of that by trying to change the culture of the Air Force and the space force by not thinking of cyber is something as an after the fact uh problem that they have to address rather as addressing it as part of just overall systems engineering right it&amp;#39;s another discipline that falls underneath systems engineering so if you have any any questions about the crows as a whole uh I can certainly try to answer those at an end at the end but that just gives you some high level uh overview of of what it is that we&amp;#39;re trying to do as an organization so change the culture uh and and get things addressed as part of systems engineering so why did we create a guidebook um the reason we we did this is because as we started to pull apart the problem we found uh just thousands and thousands of pages worth of policy and guidance that people in the program office are expected to do uh are you know um required to do statutory regulatory requirements Etc and so what you see here on this slide is a summary uh that&amp;#39;s not all inclusive but a summary of the the big players um that my team has gone through where we have uh tried to consolidate and deconflict um streamline the Redundant information and pull it all together in a best practices guide book which includes a process Katie can you uh can you hear me it looks like your audio cut out all right apologies everybody uh it looks like we lost audio from what was that can you hear me yeah can we get I can hear you now we lost you for uh about 30 seconds there okay um all right so not sure where you lost me but um bottom line well you cut out again might be a problem with your microphone is it still not working I can hear you now but it it cut out again just a minute ago just a second ago hmm I&amp;#39;m not getting any errors I mean I can hear you okay now maybe try to push it so I will just go on to the next slide so the system security engineering cyber guide book we just published version five in uh February of this year version five unfortunately is still listed as distro D um and so if you want a copy of that you can request it um but we&amp;#39;re not able to publish it publicly yet um because it&amp;#39;s still going through the the public affairs review so hopefully we get that approval for version five we did have a distro a approval so you can uh probably very easily find the the version 4 guidebook out there um if you do have access to the the Air Force Portal you can go to the crows Air Force Portal page and version five is on that page that is CAC enabled um so anyways what is the guidebook uh the guidebook is uh it&amp;#39;s it&amp;#39;s still pretty large so if you open it for the first time it is uh approximately 500 pages or so um but that that&amp;#39;s better than 20 000 plus pages of policy and guidance right um so how do how do you use this 500 pages of information um it&amp;#39;s not meant to be a cover to cover read uh the first 50 pages or so is the main body of the document that&amp;#39;s where we have the executive summary that&amp;#39;s where there is the workflow process itself that includes a detailed work breakdown structure which we&amp;#39;ll get to um and then from there the the bulk of the document our supplemental appendices and I&amp;#39;ll talk more about these appendices as we move forward but the idea is that given where you are at in the acquisition life cycle you may be at a point where you need guidance on writing requirements in which case you would go to appendix a you may need guidance on how to do um you know how to how to decompose your requirements more clearly from you know your CBD to uh your your actual system level requirements right so how do we compose that capability and maintain traceability and that&amp;#39;s where maybe appendix C might come into play um and so we&amp;#39;ll talk about that as we move forward but again it&amp;#39;s not meant to be a cover to cover read it is meant to uh go where you were at within your acquisition program and find out where you can jump in and start making the best use of these uh recommendations and best practices so this is just a slide that highlights some of the collaboration and endorsements that we have through various organizations um the SSC cyber guidebook was not put together just by the crows we have had partnership with um all of the centers across the Air Force as well as space force as well as navair uh their cyber warfare Department we have also worked very closely with industry through ndia the system security engineering subcommittee um and then just uh what was it well I guess it&amp;#39;s been a couple years now um I guess this memo was resigned out in 2019 um but we we got the memo uh coming from the four uh air force center commanders saying that you know they encourage the use of the sscg to make sure that that the RFP language is appropriate appropriately addresses system security engineering so here is a snapshot of the workflow process itself um and at a very high level the next couple of slides I&amp;#39;ll walk through just kind of big chunks of it so what you&amp;#39;ll see over here on the left this is where the bulk of the heavy lifting comes in within the SS ECG um and that&amp;#39;s because if you get your requirements on contract and you get your requirements right then the rest of the things kind of fall into place because you have the requirements there so we spend a lot of work uh providing guidance on how to make sure that you understand your system you understand the scope you understand the boundary um and you can start applying for system security engineering requirements to the appropriate areas of your system so that you&amp;#39;re optimizing Your Design solution right because we all know that there&amp;#39;s a trade space there um between performance schedule budgeting um and then there&amp;#39;s also you know size weight uh you know all those different constraints that we have to work within and so um this helps this this area of the guidance helps provide a way to to basically have um informed decision on on the trade space and how to make sure that we&amp;#39;re addressing the most important parts of our system so as you go through this process uh as I mentioned there&amp;#39;s a work breakdown structure so if you were all the way over here on the left and you were at the very first step the very first step in this process says form a system security working group okay so how do I do that well you can go and look at the work breakdown structure and there&amp;#39;s a a table within the ssecg uh and you can see the the detailed information that we have in there we have sub steps to those boxes uh so um you can see the sub steps in there there&amp;#39;s a description of things that you can do uh so for this uh for example there&amp;#39;s recommended uh Personnel to include in your working group if possible there&amp;#39;s artifacts that this step might inform so as you&amp;#39;re forming your sswg that&amp;#39;s going to help populate some of your program protection plan um and then there&amp;#39;s also additional references there so if you want to go and try to read through the policies that relate to this particular step uh those are right there for you to take a look at as well the other big thing with uh this upfront section um appendix a primarily applies to all of this upfront work um as well as some of the the systems engineering work that we&amp;#39;ll talk about in a little bit but appendix a addresses these these areas seen here uh the biggest thing to to note is that there is tailorable uh statement of work language there is tailorable system requirements uh language as well that ties back to or has been decomposed from the 10 cyber survivability attributes um and then there&amp;#39;s also a bunch of guidance on how to make sure our overall systems engineering type of documentation actually has system security engineering integrated throughout it um so for example when you&amp;#39;re looking at appendix a and you go and you&amp;#39;re you&amp;#39;re in section two and you&amp;#39;re looking at the the cell requirements you&amp;#39;re going to see sample language along with that sample language you will see uh seadrolls called out so for that paragraph a that you see on the right there you see cedral one sedral 10 called out at the very end of appendix a there is an attachment that has a sedral table in it so it has the corresponding seed Rolls by name for these paragraphs it has the corresponding data item descriptions that can be used to put that cedral on contract as recommended delivery schedules Etc um and here is a snapshot of that Seadrill table so um you can see that if you were in paragraph 2.3.2 a it called out Sidra one Sidra 1 is the program protection implementation plan uh and so you can go and look up a data item description listed here and as you&amp;#39;re you&amp;#39;re filling out um or you&amp;#39;re getting all of the contractual documents prepared for your request for proposal you can make sure you have all of that documented appropriately um so I think there are approximately right now um maybe 40 seadrolls or so caught out in the table again it&amp;#39;s tailorable so uh you can choose which ones are going to bring the biggest value to your program but they&amp;#39;re at least all presented for the system requirements there is uh an attachment within appendix a and there&amp;#39;s an embedded Excel sheet within that Excel sheet there are multiple tabs at the bottom which you can see kind of highlighted here in red the very first tab is called the the system requirements worksheet which is uh the tab that has very high level requirements um I think there&amp;#39;s like maybe I don&amp;#39;t know there&amp;#39;s maybe like 20 or so on that first tab um I forget the actual number off the top of my head um but they&amp;#39;re higher level requirements and then what you see after that are additional tabs that have that focus on each individual CSA so for example if you know that you need to address csa1 you could click on csa1 and there are the parent requirements that are listed on the system requirements worksheet but then there are also decomposed requirements that take it a little bit further down a little bit more detail and so you can look at those as well um again these are tailorable so as you as you look at them as you read through them uh a lot of times you&amp;#39;re probably going to need to add additional information um to them to make them applicable to your weapon system uh but it at least gets you thinking um kind of in the right direction and get those first steps taken um one thing worth noting is that as you are working through the soc CG process all of the areas highlighted here in in are shaded in that gray grayish blue color these are the areas of your program protection plan that the ssecg process is going to help you populate so it&amp;#39;s either going to um so for like section five threats and vulnerabilities and counter measures there are very specific sections within the ssecg that call out uh getting threat information Intel information and using that to understand your vulnerabilities so that you can do risk assessments and when you do risk assessments then that leads to coming up with mitigations and mitigations or just countermeasures right um so that&amp;#39;s just one example so all of these sections within the PPP are uh populated by by following this process so moving forward if you look at the right side of the workflow this is really where we get into I think where most of us spend our day-to-day and that&amp;#39;s just living living the systems engineering acquisition life cycle so whether it&amp;#39;s going from one systems engineering tech review to another whether it&amp;#39;s um you know going from Milestone to Milestone um if you&amp;#39;re doing any kind of the Adaptive acquisition framework um that&amp;#39;s where all that falls in and gone through all of that in order to get to your verification validation and then ultimately into Fielding um so that that&amp;#39;s what happens um I guess let me go back that&amp;#39;s what happens in that area um I don&amp;#39;t have uh slides on the details there but what I will say is that uh within appendix a there is information on uh entrance criteria that should be included in your RFP as far as the systems engineering technical reviews go and what this does is it helps ensure that as you&amp;#39;re approaching these technical reviews which are essentially you know decision points um you know to proceed on and continued development um whether or not you&amp;#39;ve actually addressed the the system security engineering concerns uh adequately so um by putting that in there that makes sure that uh the program will address those instead of waiting until it&amp;#39;s too far down the line um and and more costly one thing you&amp;#39;ll see is that this process is very heavy on risk assessments um and that is by Design so um you want to do risk assessments early often throughout the life cycle so that as the design is maturing as maybe the threat or Intel information uh changes because we all know that cyber is a very Dynamic environment to be working in um we&amp;#39;re staying up to date and we&amp;#39;re saying as informed in our decision making as possible um ultimately trying to reduce the risk um and and what that means is going to be dependent upon your program right like what an acceptable level of risk is is going to be dependent on the program dependent on the mission uh Etc so I added this slide in kind of at the last minute um a lot of people when I I talk about the ssecg process uh bring up RMF um and the purpose of this slide is at a very high level um to show you that by doing the steps within the ssccg just like for the program protection plan you are going to be generating the data needed to uh develop your authority to operate package your ATO package so what that means is that if you are doing this process along the way when the time comes to actually submit your ATO package it&amp;#39;s not going to be scrambling and trying to pull together documents and make sure that you have everything documented appropriately because you will have gone through and done the analyzes done the risk assessments everything will have been documented along the way and so at that point in time it&amp;#39;s really just going to be compiling the data in whatever format you&amp;#39;re authorizing official needs to see it in um another thing I want to talk about is appendix C and D within the SSC cyber guide book um these two appendices are in my opinion really really important and actually are going to kind of lead into the the next month&amp;#39;s uh webinar which is going to be provided by Miss Sarah standard and focus on Cyber tne um but appendix C and D are focused on the the functional threat analysis which the main purpose here is to decompose the system starting all the way up at the mission um and and there&amp;#39;s been a lot of discussion on what is the mission is it you know Big Air Force Mission or is it platform Mission and and that&amp;#39;s really at the program level that&amp;#39;s for you to decide where you want to um start your your breakdown but being able to look at that mission Trace that mission to the capabilities within your CDD which then should be traced to the csas that that uh are in the cscig um from there you&amp;#39;re going to want to decompose those capabilities into actual system requirements and from your system requirements right you&amp;#39;re going to have different levels of fidelity as your design matures and you&amp;#39;re going to go from uh you know functional requirements to actually allocated system requirements Etc but if you follow the process outlined in appendix C you are going to have that traceability from whatever the lowest level you are currently at all the way back up to the mission you know it&amp;#39;s going to be a bi-directional traceability and that&amp;#39;s really important because uh one it ensures you know that we&amp;#39;re not implementing uh cyber counter measures just because it&amp;#39;s a good idea we&amp;#39;re we&amp;#39;re implementing them because they have impact to our overall mission um and so uh the work done in appendix C also leads into having the information needed for your attack path analysis so that moves into appendix d um appendix D takes the information that was developed in the functional thread analysis and it starts to look at how the system could be attacked right um how how entry could be gained into the system where there&amp;#39;s potential vulnerabilities Etc um now appendix C and D are pretty important because uh as the as the test Community has mandated the use of mission-based cyber risk assessments appendix C and D fulfill uh the intent of a mission risk cyber-based assessment and mbcra so um if you are following the guidebook and you&amp;#39;re doing these things then guess what by the time you get to DT you&amp;#39;re going to have the information needed about your system so that the developmental testers are going to be able to move forward with the tests that that have been planned for your system as opposed to trying to go back and ReDiscover the the information that they need um so with that um that that is a I said through that brief um I&amp;#39;m hoping to have some questions and discussions um so with that I will pause and see if there are any questions so far yes yes uh so there are several questions in the chat and uh uh so I&amp;#39;ll go through them and it looks like some of your colleagues have been answering some of the questions uh and one thing I will point out is that Catherine holder posted that if anybody would like the uh ssecg version 5 sent to them they can email her and her email address she posted in the chat but it&amp;#39;s Catherine k-a-t-h-r-y-n dot holder h-o-l-d-e-r dot for the number four at us.af dot mil says catherine.holder.4 us.af dot mil uh you can send her a request for a copy of version five and as long as you&amp;#39;re able to receive it she will send it to you via DOD safe [Music] um so a few of the other questions that came in that I I don&amp;#39;t think have been answered in the chat uh uh first one is simply is the Army using this ssecg um so good question um we so let&amp;#39;s see am I I am still presenting um so the uh this is sorry this will be a little bit of a detour answer so back in 2018 the government audit agency basically came out with a report that said none of the services are addressing cyber security for weapon systems within their requirements documents and so there was a go do uh out of that GAO report for all of the services to basically start addressing that what we&amp;#39;ve done in the ssecg is the Air Force&amp;#39;s response to that initial GAO report in 2021 they did a follow-on report and you can read some of the excerpts here um but basically what came out was that uh still to date the crows and the Air Force are really the only service that has provided this level of specific guidance and they actually recommended that all of the sister services do something similar um what I can say is since 2021 and and even prior to we have shared our guidebook with the army with the Navy um and the Navy is standing up some very similar processes within uh their their service I believe the Army is as well um but but what I will say is that even though the ssecg uh has been developed by the department of the Air Force uh there may be some I guess what I&amp;#39;ll call Air Force isms in there right like some Air Force specific things but for the most part um it is written at a high enough level that it could be applicable to any of the services um so you know some of the stuff that was derived from Air Force instructions may or may not be applicable to the Army um but as far as the the tailorable requirements and things like that go uh the Army can certainly um you know take it and and borrow what they want from the ssecg as they move forward all right thank you uh the next question there was some people discussing this in the chat so but I&amp;#39;m not 100 sure if the question itself was answered so uh the question is do you offer a list of known vulnerabilities for a set of Technologies often used in Solutions wow that is an excellent question um so I I do not think at this time we have a list like that that exists what I what I do know is that uh part of our organization part of crows we have um a team that looks at uh I guess kind of just generic uh vulnerabilities that could apply like um to multiple weapon systems right and from there we go we go out and we research mitigations and so we do have a document um called the mitigations handbook that is on the classified side and if you&amp;#39;re interested in that again as you reach out to Kate for the ssecg uh throw that request in there as well and then Kate we can um we can compile a list of names that would like to see uh that document the mitigations handbook and we can get that over to uh the team to get that supplied to them um that&amp;#39;s that&amp;#39;s where we&amp;#39;re at today and I know Joe typed in um about the the vulnerabilities database um but as far as crows goes we don&amp;#39;t have something that we maintain for that okay great thank you um let&amp;#39;s see another question uh who do you see being the Billet assigned to do these tasks the issm a dedicated SSE uh the PPS I&amp;#39;m sorry I I&amp;#39;m not sure of all the acronyms so I I hope they&amp;#39;re familiar to you sure um so that&amp;#39;s an excellent question um and again uh coming from um the at least for the Department of the Air Force part of crows is has actually provided that manpower to our program offices through what we call our cyber focused teams our cfts So within each program office we have positioned a cyber focused team lead as well as other cyber focused team members to be that cyber Smee to be able to support programs as they navigate through uh their their cyber terrain for lack of better words um now that being said not everybody is going to have a cyber Focus team that&amp;#39;s readily available right sometimes smaller programs may not have the help that they need um and likewise maybe larger programs are like hey we got this under control we&amp;#39;re doing it by ourselves um in which case then ISM could be somebody that does this it could be uh if you if your program has a system security engineer actually billed it for the program um they are somebody that could be doing it uh but I think in in standard engineering fashion I&amp;#39;ll give you the it depends answer um so hopefully that helps and if you need more uh information on the Crow&amp;#39;s cyber Focus teams um again please feel free to reach out to me and I will help get you the information that you need based on either what programs you support or anything like that all right great and another question uh do you have an overall mapping from RMF to the guidebook uh I work in an area that doesn&amp;#39;t use the same procurement processes and we&amp;#39;d like to see how we can apply portions of the guidebook to our processes um yes give me just a minute I am going to share a different screen um this is the one I want to share okay so um this is the slide that I had up earlier um and what I want to point out is that within the ssecg appendix f i I&amp;#39;m sorry I did not talk about appendix F and it&amp;#39;s one of my favorites because um appendix f is the relationship to other processes so appendix F will discuss how by doing the ssecg you&amp;#39;re going to meet uh test and evaluation needs by doing the sscg you&amp;#39;re going to meet these RMF needs and we actually have the discussion on um really how and why those things uh you know are in alignment or complementary of one another so here what I did was I I really just kind of tried to break down that section of appendix F that talks about RMF and the ssccg and pull it out into some slide pictures so uh this is the slide that you saw before within appendix F we also have this slide which is just the RMF process right this as a refresher is just the sscg process and then what we have a very very explicit detail this is obviously an eye chart um but this is a table that we have that&amp;#39;s that&amp;#39;s much more readable in the guidebook itself that goes through every one of those boxes on the the slide two that I showed you for RMF and traces them to um a step within our work breakdown structure in the sscg what I point out on this slide is that there are only these these two steps or these sorry these three steps um that do not have a direct Chase trace to the ssccg um but I think that uh some of that p7 I think um actually that we might need to look at that one a little bit more closely um because I do believe we have some stuff in there for uh continuous monitoring um but so hopefully if you take a look at that section that that might help you with that traceability question all right great um another couple questions um is there anyone from the space that you are working with um yes so we do have um I do not have names off the top of my head um but we do have Representatives um that we work with out at space we are in the process of trying to hire a cyber focused team members to directly support the space force um we have a let&amp;#39;s see I believe uh Kate is actually miss holder is actually meeting with SSC the space systems command a couple of folks tomorrow to give them kind of the same rundown of of what the guidebook is and how the crows can can help them out so um if there are more specific questions on how space can get help from crows please reach out to me directly and um we can have that follow-on conversation wonderful uh another question are you seeing any work in the leverage or sorry are you seeing any work to leverage and BSE slash D bottle-based systems engineering slash digital engineering to support FTA and attack path analysis absolutely um so the crows has been funding the development of two separate tools that will directly uh impact that area so one is the Assurance tool and the other one is the CSA Tool uh the CSA tool is is very near and dear to my heart because I&amp;#39;ve been working with that development team for a couple of years now um and and the tool has really started to to grow into something that&amp;#39;s going to be very beneficial um that tool starts by um actually taking all of the the CSA language all of the requirements that are in the ssecg um nist controls uh basically they spent a lot of time pulling in all of the the backbone um information needed to build a model uh from an SSC perspective of your system um so that you can have that requirements traceability so the CSA tool will provide uh basically the the SSE inputs to your request for proposal package um if you would like a demonstration on the CSA Tool uh I can get with the program manager of of that and and we can schedule um some kind of demonstration they&amp;#39;re they&amp;#39;re always willing to give demonstrations of the tool um but from there uh my so we actually have the the CSA and the Assurant team um are doing a workshop this week uh to work on integration stuff so from there uh we are in the process of making sure that the CSA tool and the Assurance tool can talk to one another because ideally the model built in uh CSA tool will be able to be exported into assurance and then the Assurant tool will able be able to run an attack path analysis to be able to help identify those potential vulnerabilities within the system um we are working to have that communication of Assurant and CSA bi-directional so that say we run an analysis in Assurant um that Assurant can then uh export its findings back out to CSA and CSA can you know make whatever requirements modifications if necessary um and and that we can then export it back run the analysis again see if we&amp;#39;ve done some mitigation so um that is right now uh our biggest focus in the mbsc uh de Arena as far as it it relates to cyber great um next question and still got a few more coming in so um our atos and cras transferable between all defense branches or our risk assessments environment dependent um I don&amp;#39;t know if I am qualified to answer that question um that would be honestly I think that would be up to the authorizing officials so like if you were to do say you&amp;#39;re working I guess a joint program right um if you were to do like the processes within the ssecg would the Navy accept that risk assessment um I would I would tend to believe if you can show the The Sound Engineering and due diligence behind the assessment that yes it would be accepted um but I don&amp;#39;t know that uh for fact so that would be something that you would have to probably follow up with your AOS on all right uh this question I you may have addressed it another answer but uh I&amp;#39;ll ask it anyway do you address how to define measurable requirements in the requirements the decomposition to an extent so uh recall I did say that these um requirements are uh tailorable so um that&amp;#39;s really where the measurable part comes in so um like if you&amp;#39;re gonna say there&amp;#39;s a requirement for um restoring back to a known baseline or or like so one you detect in an anomaly you have the the requirement in there to detect anomalies okay great um there&amp;#39;s probably some kind of time requirement that you would want associated with that right and so that&amp;#39;s where your program uh specifics are going to come in and and that&amp;#39;s where I believe uh Miss standards brief next month is kind of going to pick up from where this briefing is leaving off foreign okay great uh next question is simply do you use EMASS yes EMASS is a uh called out in the ssecg um and I know that that uh our cyber Focus teams are aware of how to use EMASS Etc okay and then uh the next kind of two-part question comes from somebody who is the person that asked the previous question on uh mapping from RMF to the guidebook uh yes how about mapping how the nist controls are accounted for I see how some are accounted for but not others and can you share the more detailed slides with the RMF mapping uh yes I can share those slides um and I will uh what I&amp;#39;ll probably do is send those to Phil and let Phil figure out how to send those out um if that&amp;#39;s all right um that&amp;#39;ll work yep okay so um let&amp;#39;s see uh mapping back to the news controls yes um so what we did when we wrote These system requirements um those requirements were written it&amp;#39;s been it&amp;#39;s been quite a few years now because we&amp;#39;ve spent the last couple of years developing other content within the sscg so when those requirements were first written we were using nist uh 800-53 version 4. I know version 5 is out there now um but what we did was we used the uh aircraft overlay for the nist controls we looked at um the requirements that were on or the controls that were called out on that aircraft overlay and then we pulled those requirements or we looked at those controls within this and we translated those requirements into or we translated those controls into actual requirements it is important to note that those controls are always supposed to be translated into requirements language unfortunately uh I think we&amp;#39;ve gotten in bad practice of not doing that um but within the Excel sheet if you scroll over to the right um you&amp;#39;ll see the mapping to what Mist control that satisfies now going back to that CSA tool that I was just talking about if you&amp;#39;re using that tool the mapping is already done in there for you so if you select a control it&amp;#39;s going to pop out the requirement that&amp;#39;s corresponding to it if you select a requirement it&amp;#39;s going to pop out and show you what control that correlates to okay um the next question simply does your guide apply to an industrial control systems um so it was developed specifically for weapon systems that being said uh I don&amp;#39;t think there&amp;#39;s anything that precludes it from not being used for those kind of systems again it&amp;#39;s all tailorable okay great uh I think I got all the questions that are in there uh right now um I&amp;#39;ll just point out and get to give people an extra minute if there is a last minute question uh the slides a few people asked about where the slides are available if you go to the csiac.org website uh click on webinars find today&amp;#39;s webinar the slides are there and then when the uh when the webinar goes up on YouTube should be there by the end of this week uh you can also get the YouTube link from that very same uh website or just go to the csiac YouTube channel um uh supersonic uh there&amp;#39;s one more question superset Lynn wallet oh did I miss a question up here okay so there was one more question I I must uh missed this question would you say that you haven&amp;#39;t accumulate how you have accumulated and documented the superset of activities that a program should do during the system life cycle was that your intent can you ask that again uh the way reads is would you say that you have accumulated and documented the superset of activities that a program should do during the system life cycle was that your intent um it&amp;#39;s a super set I would say it&amp;#39;s a comprehensive uh set of activities that um if you were going through the most rigorous you know standard waterfall approach development cycle that you should do that being said if you&amp;#39;re going through uh a devsecops or you&amp;#39;re going through some kind of accelerated acquisition Etc uh there are ways to tailor the process uh to go faster um but at the same time we have documented um I guess what what we would recommend as a a bare minimum of things to do dependent upon which pathway you&amp;#39;re going um so I hope that helps answer yeah uh yes and then uh one last question will this be used for a new or an existing program or both it can be used for all of the above um and that&amp;#39;s why what&amp;#39;s uh what&amp;#39;s interesting about when you look at um the workflow process itself you will see that it&amp;#39;s not aligned to milestones and the reason we did that is because regardless of if you&amp;#39;re a brand new system you&amp;#39;re um an upgrade to a system you&amp;#39;re like a 1067 where you&amp;#39;re you know bolting something on uh you still need to go through all of those upfront steps of understanding if it&amp;#39;s a brand new system obviously you have a lot to to understand and uncover there if you&amp;#39;re bolting something on you still need to understand what is your system what is your system boundary how does this impact you know if I bolt this on here what does that do to the rest of the system and so you still have to go through all of that um analysis and understanding of your system you still have to go through putting stuff on contract uh and and you still have to go through you know doing whatever kind of reviews to get to decision points and so that&amp;#39;s why um we kind of set set the process up in the way that we did all right great well thank you so much Katie that that looks like it&amp;#39;s the last of the questions uh and I thank you for the wonderful brief um I&amp;#39;ll I&amp;#39;ll send you the the chat history just so you can see the number of people that said what an outstanding brief you you provided uh this was great uh great with the question question and answer portion so thank you so much and thank you to everybody that joined us today I&amp;#39;ll go ahead and close it out here I&amp;#39;ve already told people how to get to the slides into the YouTube video so again enjoy the rest of your day and enjoy the rest of your week thank you so much all right thank you

Transcript for:Cybersecurity and Information Systems Webinar

Transcript for:
Cybersecurity and Information Systems Webinar