Risk management framework analysis system

Abstract

Information technology project proposal assessments determine applicable controls for compliance with a risk management framework (RMF). The disclosed technology may include a dynamic interface that prompts users for project-related information. Navigation by the user may be provided by the dynamic interface based on user inputs. Prompts may include, for example, project-related information, project controls, or the like. In some embodiments, the project proposal assessment may include a costing mechanism to assist users to estimate project costs accurately and quickly per project control. The project proposal assessment resolves the perennial problem of rapidly and rigorously projecting costs (e.g., RMF compliance costs) during a bidding process. Additionally, or alternatively, project proposal assessment ensures compliance with an RMF's security standards and guidelines to adequately protect critical data.

Description

RISK MANAGEMENT FRAMEWORK ANALYSIS SYSTEMCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to and the benefit of U.S. Provisional Application No. 63 / 676,143 filed July 26, 2024, titled “RISK MANAGEMENT FRAMEWORK ANALYSIS SYSTEM”, which is incorporated herein by reference in its entirety.FIELD OF THE INVENTION

[0002] The present disclosure relates to information security and network compliance and, more specifically, information security standard compliance for information systems using a risk management framework assessment platform.BACKGROUND

[0003] Cybersecurity is critical for protecting data, preserving privacy, preventing identity theft, maintaining trust, safeguarding critical infrastructure, defending against cybercrime, and ensuring national security in an increasingly digital world. According to IBM in 2023, the average cost of a cyber security’ breach is $9.48M, and Cybercrime Magazine estimates the total annual cost is $10.5T. Cyber-attacks on private companies, typically healthcare, financial and technology industries, are profoundly serious. And cyber-attacks on the United States Department of Defense (DoD) are even more serious. According to DefenseScoop, the DoD spent $13.5B on cyber security and $58.5B for IT in 2024 alone. Despite the United States’ best efforts, in 2022 there were 34 successful attacks according to the KonBriefing. More recently, on October 16, 2023, the Cybersecurity' & Infrastructure Security’ Agency released a major successful attack named Atlassian Data Breach. These successful DoD cyber-attacks can range from stealing personal information about government employees to being life-threatening.

[0004] To help prevent successful cyber-attacks, in 2002 the US government published the Federal Information Security' Management Act (FISMA). This act “requires each federal agency to develop, document, and implement an agency -wide program to provide information security for the information and information systems that support the operations and assets of the agency”. It also “assigns specific responsibilities to federal agencies, the National Institute of Standards and Technology (NIST) and the Office of Management and Budget (0MB) in order to strengthen information security systems. In particular, FISMA requires the head of each agency to implement policies and procedures to cost-effectively reduce information technology security risks to an acceptable level.” The NIST agency specifically, “is responsible for developing standards, guidelines, and associated methods and techniques for providing adequate informationsecurity for all agency operations and assets, excluding national security systems.” With the authority from FISMA, NIST developed the “NIST Risk Management Framework to provide a flexible, holistic, and repeatable 7-step process to manage security and privacy risk and links to a suite of NIST standards and guidelines to support implementation of risk management programs to meet the requirements of the Federal Information Security' Modernization Act (FISMA).”

[0005] The crux of the problem is one of the seven steps of the framework that helps organizations select the set ofNIST 800-53 controls to protect the system. NIST 800-53 ‘Security and Privacy Controls for Information Systems and Organizations’ is comprised of 1,189 controls that are grouped into 20 unique and non-overlapping control families. It is an intimidating task for anyone to build a working knowledge of all 1.189 controls. NIST 800-53 provides a comprehensive framework for implementing security controls, managing risks, and ensuring compliance with regulatory requirements, ultimately contributing to the overall resilience of information systems and the protection of sensitive information.

[0006] Due to the complexity of information guidance provided by a publication like NIST SOO- 53. problems arise when attempting to project costs (e.g.. RMF compliance costs) during a bidding process that requires a short turnaround time.SUMMARY

[0007] In some embodiments, the instant disclosure may comprise an apparatus comprising a memory storing computer readable instructions storing, and at least one processor configured to execute one or more computer executable instructions thereby causing the at least one processor to display, via at least one dynamic user interface, one or more fields associated with data corresponding to a project. The at least one processor can be further configured to execute the one or more computer executable instructions thereby causing the at least one processor to receive, via the at least one dynamic user interface, information related to the data corresponding to the project. The at least one processor can be further configured to execute the one or more computer executable instructions thereby causing the at least one processor send at least one query to at least one privacy and security framework compliance device, the at least one query comprising a request for at least one privacy and security compliance document that is potentially relevant to the project. The at least one processor can be further configured to execute the one or more computer executable instructions thereby causing the at least one processor display at least one prompt, via the at least one dynamic user interface, requesting additional data pertaining to the project based on one or more controls of the privacy and security framework compliancedocument. The at least one processor can be further configured to execute the one or more computer executable instructions thereby causing the at least one processor determine that the at least one privacy and security document is relevant to the project. The at least one processor can be further configured to execute the one or more computer executable instructions thereby causing the at least one processor display, via the at least one dynamic user interface, the at least one privacy and security compliance document.

[0008] Yet in other embodiments, the instant disclosure may comprise anon-transitory computer readable medium comprising computer readable code executable by one or more processors to display, via at least one dynamic user interface, one or more fields associated with data corresponding to a project. The non-transitory computer readable medium may further comprise computer readable code executable by the one or more processors to receive, via the at least one dynamic user interface, information related to the data corresponding to the project. The non- transitory computer readable medium may further comprise computer readable code executable by the one or more processors to send at least one query to at least one privacy and security framework compliance device, the at least one query comprising a request for at least one privacy and security compliance document that is potentially relevant to the project. The non-transitory computer readable medium may further comprise computer readable code executable by the one or more processors to display at least one prompt, via the at least one dynamic user interface, requesting additional data pertaining to the project based on one or more controls of the privacy and security framework compliance document. The non-transitory computer readable medium may further comprise computer readable code executable by the one or more processors to determine that the at least one privacy and security document is relevant to the project. The non- transitory computer readable medium may further comprise computer readable code executable by the one or more processors to display, via the at least one dynamic user interface, the at least one privacy and security compliance document.

[0009] Yet still in other embodiments, the instant disclosure may comprise a method for risk management comprising displaying, via at least one dynamic user interface, one or more fields associated with data corresponding to a project. The method may further comprise receiving, via the at least one dynamic user interface, information related to the data corresponding to the project. The method may' further comprise sending at least one query7to at least one privacy and security7framework compliance device, the at least one query' comprising a request for at least one privacy and security compliance document that is potentially relevant to the project. The method may further comprise displaying at least one prompt, via the at least one dynamic user interface, requesting additional data pertaining to the project based on one or more controls ofthe privacy and security framework compliance document. The method may further comprise determining that the at least one privacy and security document is relevant to the project. The method may further comprise displaying, via the at least one dynamic user interface, the at least one privacy and security compliance document.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] For a detailed description of various examples, reference will now be made to the accompanying drawings in which:

[0011] FIG. 1 shows, in block diagram form, a simplified network diagram in accordance with one or more embodiments.

[0012] FIG. 2 depicts an exemplary client computing device that may be used in accordance with an exemplar}’ embodiment of the present disclosure.

[0013] FIG. 3 depicts example sponsor statement categories in accordance with one or more embodiments.

[0014] FIG. 4 depicts example sponsor needs statements in accordance with one or more embodiments.

[0015] FIG. 5 depicts example sponsor driver statements in accordance with one or more embodiments.

[0016] FIG. 6 depicts example sponsor constraint statements in accordance with one or more embodiments.

[0017] FIG. 7 depicts example architecture requirement categories in accordance with one or more embodiments.

[0018] FIG. 8 depicts example business requirements in accordance with one or more embodiments.

[0019] FIG. 9 depicts example functional requirements in accordance with one or more embodiments.

[0020] FIG. 10 depicts example usability' and interface requirements in accordance with one or more embodiments.

[0021] FIG. 11 depicts example requirements to sponsor statements mapping in accordance with one or more embodiments.

[0022] FIG. 12 depicts example requirements to sponsor statements mapping in accordance with one or more embodiments.

[0023] FIG. 13 depicts example business requirements to system level requirements in accordance with one or more embodiments.

[0024] FIG. 14 depicts example system level user requirements in accordance with one or more embodiments.

[0025] FIG. 15 depicts example requirements to sponsor statements mapping in accordance with one or more embodiments.

[0026] FIG. 16 depicts example architectural level requirements in accordance with one or more embodiments.

[0027] FIG. 17 depicts example system level business requirements and architectural requirements relationship in accordance with one or more embodiments.

[0028] FIG. 18 depicts example list of control families in accordance with one or more embodiments.

[0029] FIG. 19 depicts example elements of a control in accordance with one or more embodiments.

[0030] FIG. 20 depicts an example taxonomy of a control family: awareness and training in accordance with one or more embodiments.

[0031] FIG. 21 depicts an example taxonomy of a control family: supply chain risk management in accordance with one or more embodiments.

[0032] FIG. 22 depicts an example system interaction use case in accordance with one or more embodiments.

[0033] FIG. 23 depicts an example system processes use case in accordance with one or more embodiments.

[0034] FIG. 24 depicts example functional decomposition in accordance with one or more embodiments.

[0035] FIG. 25 depicts an example ATAM package diagram in accordance with one or more embodiments.

[0036] FIG. 26 depicts example business drivers in accordance with one or more embodiments.

[0037] FIGs. 27A-27C depict example approaches and quality attributes in accordance with one or more embodiments.

[0038] FIG. 28 depicts an example utility tree in accordance with one or more embodiments.

[0039] FIG. 29 depicts example scenarios in accordance with one or more embodiments.

[0040] FIG. 30 depicts another example utility tree in accordance with one or more embodiments.

[0041] FIG. 31 depicts an example user architecture view in accordance with one or more embodiments.

[0042] FIGs. 32A-C depicts an example architecture view of a sponsor in accordance with one or more embodiments.

[0043] FIGs. 33A-C depicts an example architecture view of a code developer in accordance wi th one or more embodiments.

[0044] FIG. 34 depicts the architecture from the system interface perspective in accordance with one or more embodiments.

[0045] FIG. 35 depicts an example white box model in accordance with one or more embodiments.

[0046] FIG. 36 sho s an example high-level architecture for a Supply Chain Risk Management (SR) control family questionnaire in accordance with one or more embodiments.

[0047] FIG. 37 show s an example low -level architecture for SR- 1 questionnaire in accordance with one or more embodiments.

[0048] FIG. 38 depicts an example landing page process in accordance with one or more embodiments.

[0049] FIG. 39 depicts an example summary page diagram in accordance with one or more embodiments.

[0050] FIGs. 40A-40Z depict example screenshots of a graphical user interface in accordance with one or more embodiments.

[0051] FIG. 41 depicts an example flow diagram in accordance with one or more embodiments.DETAILED DESCRIPTION

[0052] The following description relates to technical improvements to information security and network compliance. Described herein are, inter aha, systems and methods for assessing project proposals to determine applicable controls for compliance with a risk management framework (RMF). The disclosed technology may include a dynamic interface that prompts users for proj ectrelated information. Navigation by the user may be provided by the dynamic interface based on user inputs. Prompts may include, for example, project-related information, project controls, or the like. In some embodiments, the project proposal assessment may include a costing mechanism to assist users to estimate project costs accurately and quickly per project control. The project proposal assessment resolves the perennial problem of rapidly and rigorously projecting costs (e.g., RMF compliance costs) during a bidding process. Additionally, or alternatively, project proposal assessment ensures compliance with RMF security standards and guidelines to adequately protect critical data.

[0053] In some embodiments of the disclosed technology, a more efficient way to assess project proposals to determine applicable controls is provided. Through a series of questions or prompts, the disclosed systems and methods may assist project researchers in navigating the complex and vast number of controls. Additionally the disclosed systems and methods may only select the controls that will apply to the project proposal being formulated. Additionally, the disclosed systems and methods may provide a costing mechanism to assist project researchers in accurately and quickly estimating costs per control. The disclosed systems and methods attempt to resolve resource constraints experienced by project researchers, specifically the overallocation of cybersecurity subject matter experts. Additionally, or alternatively, the disclosed the disclosed systems and methods aims to resolve the perennial problem of rapidly and rigorously projecting costs during the bidding process, which can be a short turnaround time.

[0054] In some embodiments of the disclosed the disclosed systems and methods, controls may be provided by a security and privacy framework, such as NIST 800-53, or the like. As an illustrative example, NIST 800-53 ‘Security and Privacy Controls for Information Systems and Organizations’" is comprised of 1,189 controls that are grouped into 20 unique and nonoverlapping control families. It may be an intimidating task for anyone to build a working knowledge of all 1,189 controls. Security’ and privacy frameworks, like NIST 800-53, provide a comprehensive framework for implementing security controls, managing risks, and ensuring compliance with regulatory requirements, contributing to the overall resilience of information systems and the protection of sensitive information.

[0055] The complex and large range of a security and privacy framework’s controls poses a significant challenge for users, such as IT project managers, as they navigate and determine the standards that can and should be met for a specific project. The complexity of this problem stems from various factors, including the sheer volume and diversity of standards applicable to different projects, the intricate nature of the standards themselves, and the dynamic landscape of technological advancements. The complexity’ of this problem may be further compounded by the occasional presence of a single line item in a contract mandating security and privacy framework compliance for a project. In such cases, a user may be tasked with meeting stringent compliance requirements without necessarily possessing an in-depth understanding of all the intricacies involved. This lack of expertise can be particularly challenging, as achieving security and privacy framework compliance necessitates a nuanced understanding of the Risk Management Framework (RMF) and its application to specific project contexts. Without a dedicated RMF expert who comprehends all the intricacies of security and privacy framework compliance, a user faces the daunting task of deciphering and implementing the relevant security controls, riskassessments, and documentation requirements outlined in the standard. The absence of such expertise not only hampers a user's ability to effectively navigate the standards landscape but also increases the risk of non-compliance and potential project setbacks. To solve this problem, the disclosed systems and methods may reduce the complexity and difficulty of scoping, planning, and budgeting for adherence to RMF standards in contracting and programmatic efforts. The disclosed systems and methods may evolve when newer versions of a security and privacy framework are released and may seamlessly integrate with future systems as the users’ needs change.

[0056] In some embodiments of the disclosed systems and methods, the systems may consist of two interconnected elements. The initial component may be a versatile RMF analysis tool architecture designed specifically for a security and privacy framework’s standards, such as the NIST 800-53’s standards. This architecture will be utilized in creating the second component of the system - an RMF analysis tool. The purpose of this tool is to methodically identify specific project risks by pinpointing the pertinent standards of the security7and privacy framework. Both the architecture and the tool may be represented as an open-sourced application. In some embodiments, the disclosed systems and methods may have an intuitive interface where a user inputs relevant project information and intended RMF compliance. As output, the disclosed technology7may report back compliance information and manning estimates for additional compliance in an easy-to-understand and use format. This architecture may, in some embodiments, have the potential to be used to develop additional tools for other standards. The disclosed systems and methods may use or be integrated with commercially available engineering applications, such as MagicDraw or the like.

[0057] In one non-limiting example, a hard constraint for the disclosed systems may include compliance with security7and privacy framework’s standards, such as NIST 800-53. In some embodiments, the Federal Information Security7Management Act of 2002 Subsection 3544 Federal Agency responsibilities may need to be taken into consideration for the disclosed system and framework. The NIST 800-53 document states "(2) ensure that senior agency officials provide information security7for the information and information systems that support the operations and assets under their control, including through-"and “(A) assessing the risk and magnitude of the harm that could result from the unauthorized access, use, disclosure, disruption, modification, or destruction of such information or information systems.”

[0058] In some embodiments of the disclosed system a software analysis tool may include a nonproprietary, readily accessible, user-friendly, and capable of generating outputs that are universally compatible.

[0059] In some embodiments, the software analysis tool may be able to help guide research and development and proper contract quoting. Additionally, the software analysis tool may help build requirements and address legal compliance by referencing security and privacy framework’s standards, such as NIST 800-53, to ensure that the project is addressing all aspects of its intended implementation. The software analysis tool may aid in risk mitigation. If a project analyzed using the disclosed software analysis tool in the early stages of development, it may ensure compliance and with that has the potential to make it harder for bad actors to interfere with information systems that are built according to the project being analyzed by the software analysis tool. Further, the software analysis tool reduces complexity, as it will have the capability' to address compliance with the standards for the proposed program as opposed to manually checking compliance. The software analysis tool may help save time, and ensure that any systems or devices developed during the project are in compliance with relevant NIST standards.Exemplary Computer System for Data Compression

[0060] FIG. 1 depicts an exemplary risk management framework (RFM) computing sy stem 100. RMF computing system may include a RMF computing device 102. RMF computing device 102 may include a database server 104 that may be communicatively coupled to a database 106 that stores data. In one embodiment, database 106 may be a local storage device. In another embodiment, database 106 may be a remote storage device, such as cloud storage, or the like. RMF computing device 102 may be in communication with a plurality of user device(s) 108. A user device 108 may be associated, for example, with a project manager creating a project proposal for a government agency. Further, RMF computing device 102 may be in communication with a plurality of compliance device(s) 110 and third-party device(s) 112. In some embodiments, compliance device(s) 110 may be associated with, for example, a remote server that provides security and privacy framework’s standards, such as NIST 800-53. Additionally, compliance device(s) 110 may provide updates or new' releases to security and privacy framew ork standards to RMF computing device 102. In some embodiments, security and privacy framew ork standards may be stored on database 106 by RMF computing device 102. In some embodiments, risk management services may be performed by RMF computing device 102, user device(s) 108, compliance device(s) 110. or a combination thereof.

[0061] In the exemplary embodiment, user device(s) 108 may be computers that include a web browser or a software application, which enable user device(s) 108 to access remote computer devices, such as RMF computing device 102, using the Internet or another network. More specifically, user device(s) 108 may be communicatively coupled to RMF computing device 102 through many interfaces including, but not limited to, at least one of the Internet, a network, alocal area network (LAN), a wide area network (WAN), a cellular phone connection, a cable modem, or the like. User device(s) 108 may be any device capable of accessing the Internet including, but not limited to, a desktop computer, a laptop computer, a personal digital assistant (PDA), a cellular phone, a smartphone, a tablet, wearable electronics, smart watch, or other webbased connectable equipment or mobile devices. RMF computing device 102 may receive project proposal information, IT system information, computer system architecture data, or the like, from user device(s) 108. Further, RMF computing device 102 may securely store the data collected from user device(s) 108 on database 106.

[0062] In some embodiments, user device(s) 108 may act on behalf of a government agency or private organization that has projects subject to risk management assessments. For example, RMF computing device 102 may receive data from user device(s) 108 that is to be processed and analyzed (e.g., project proposal input data) in accordance with network security and privacy controls. Data may be received, for example, via one or more graphical user interfaces. Input data requested may be based on network security7and privacy control data, prior user inputs received, or a combination thereof. RMF computing device 102 may analyze and process the data received, may use compliance device(s) 110 and / or third-party device(s) 112 to analyze and process the data, or RMF computing device 102, compliance device(s) 1 10, and / or third-party device(s) 112 may work together to analyze and process the data (e.g., balance load).

[0063] In the exemplary embodiment, compliance device(s) 110 or third-party device(s) 112 may be computers that include a web browser or a software application, which enable compliance device(s) 1 10 to access remote computer devices, such as RMF computing device 102, using the Internet or another network. More specifically, compliance device(s) 110 may be communicatively coupled to RMF computing device 102 through many interfaces including, but not limited to, at least one of the Internet, a network, a local area network (LAN), a wide area network (WAN), a cellular phone connection, a cable modem, or the like. Compliance device(s) 110 or third-party' device(s) 112 may7be any device capable of accessing the Internet including, but not limited to, a desktop computer, a laptop computer, a personal digital assistant (PDA), a cellular phone, a smartphone, a tablet, wearable electronics, smart watch, or other web-based connectable equipment or mobile devices.Exemplary Electronic Computing Device

[0064] FIG. 2 depicts an exemplary7configuration of a client computing device 200, in accordance w ith at least one embodiment of the present disclosure. Client computing device 200 may be operated by a user (not shown). Client computing device 200 may include, but is not limited to, devices 108, 110, and 112 (shown in FIG. 1). Client computing device 200 mayinclude a processor 204 for executing instructions. In some embodiments, executable instructions may be stored in memory 208. Processor 204 may include one or more processing units (e.g., multi-core configuration). Memory 208 may be any device allowing information, such as executable instructions or transaction data, to be stored and retrieved. Further, memory 208 may include one or more computer readable media.

[0065] Client computing device 200 may also include at least one input / output component 202 for presenting information to a user. Input / output component 202 may be any component capable of conveying information to the user. In some embodiments, input / output component may include an output adapter (e.g., video adapter, audio adapter). Input / output component 202 may be coupled to processor 204 and couplable to an output device, such as a display device (e.g., LCD. LED) and an audio output device (e.g., speakers, headphones).

[0066] In some embodiments, input / output component 202 may be configured to present a graphical user interface (e.g., web browser, client application) to the user. In some embodiments, input / output component 202 may include an input device for receiving input from the user. The input device may include, for example, a keyboard, a pointing device, a mouse, a stylus, a touch sensitive panel (e.g., touch pad, touchscreen), a gyroscope, an accelerometer, a position detector (e.g., GPS sensor), a biometric input device, a camera lens, or an audio input device. A single input device, such as a touchscreen, may function as both an input device and an output device.

[0067] Client computing device 200 may include a network interface 206. Network interface 206 may include, for example, a wired or wireless network adapter. Further, network interface 206 may include a wireless data transceiver for use with a mobile telecommunications network.

[0068] Stored in memory 208 are, for example, computer readable instructions for providing a user interface via input / output component 202. Additionally, or alternatively, the computer readable instructions may be stored in memory 208 for receiving and processing input from the user interface via input / output component 202. The user interface may include, among other possibilities, a web browser, or a client application. Web browsers enable users to display and interact with media and other information typically embedded within a web page or a w ebsite. A client application may enable users to interact with other computing devices, such as other client computing devices or server computing devices, over a network via network interface 206.Example Architecture

[0069] The requirements process has an extensive list of inputs and process activities. This is important because requirements form a substantial part of the system foundation and can be associated with the use case analysis. They can also represent a significant risk to the project, system, and architecture if not done correctly with the correct key parties.

[0070] In the infancy of requirements generation, data gathering, sponsor interviews, and elicitation procedures play a major role. The key to all of this is to gather stakeholder needs. These differ from stakeholder requirements as they are in the language of the customer rather than the language of engineers. These stakeholder needs can then be transformed into stakeholder requirements. Following this analysis, creators are able to easily trace the sponsor needs statements to requirements which generated the ability to ensure that the requirements reflect the customer's wants and desires. At this point in the process, however, the requirements are vague with the intention of refinement later in the process.

[0071] Referring to FIG. 3, sponsor statements 300 may include the overall categories for the sponsor statements are shown. This represents the first stage in elicitation where the identification and distinction between needs, drivers, and constraints are shown. Needs statements can be thought of as the "‘how” part of the system. They are statements primarily dealing with how the system will operate. Next, drivers are shown. This can be thought of as the ‘‘why” in that these statements describe reasons for completing or starting this w ork. Then, lastly, there are general constraints. Though these may not be immediately considered cut-and-dry requirements, they can be used to inform architectural requirements and, in some cases, result in them directly.

[0072] Next, as shown in FIG. 4, a decomposition 400 of the sponsor need statements shown in FIG. 3 may be illustrated. These needs may be either taken directly from the document provided by the sponsor in the form of a charter or w ere inferred from sponsor meetings and interviews.

[0073] FIG. 5 illustrates a decomposition 500 of the sponsor driver statements shown in FIG. 3 is illustrated. The decomposition 500 may help identify the reason for the project and proposed system. For this system, there have been two primary drivers identified, namely Complexity of RMF and Contract Risk Exposure.

[0074] As shown in FIG. 6, a decomposition 600 of the general constraints shown in FIG. 3 is illustrated. The decomposition 600 shows the general constraints of the system from both the sponsor's and the developers’ views regarding system delivery, applicable legislation, and the business environment. The general constraints can include, time and scope of a project. The general constraints can further include applicable legislation relevant to the project. The general constraints can further include a competitive landscape of the project. The general constraints can further include SME and User Knowledge that is relevant to the project. The general constraints can further include software resources that are relevant to the project.

[0075] Once sponsor needs statements are documented and agreed upon, the next step is the system requirements definition process. This process is the method by which sponsor statementsare transformed into the initial set of requirements. This is also commonly referred to as requirements derivation.

[0076] For this part of the requirements analysis, another set of categories is developed to assist in the definition of an architectural requirements 700. For this, FIG. 7 shows architectural business requirements, functional requirements, usability requirements, and interface requirements. Though these may not be clearly traceable to the sponsor statement categories, they provide the beginning of a software architecture framework. This differs from typical product architectures in that functionality may be closely tied to features, and useability is more geared towards user interface. Additionally, at this early stage in the process, the emphasis is on keeping these as high-level and unrestrictive as possible. This is done to preserve the solution space and avoid over-constraining the system unnecessarily. As a result, the focus is primarily on functionality and business needs which formed the basis for many of the needs statements.

[0077] Starting with the non-functional architectural requirements, namely business requirements 800, FIG. 8 outlines the transformation of needs to requirements. These requirements are aimed at formalizing the sponsor needs statements that are related to drivers into requirements. These will shape the solution space by ensuring that the basic needs are met. The business requirements 800 can comprise labor hours, costing, architecture to software, and competitive advantage.

[0078] Functional architectural requirements 900 are display ed in FIG. 9 and formally communicate what minimal feature development must occur and be modeled. The functional architectural requirements 900 can comprise system applicability', accurate reflection, architecture modularity, and extensibility. Finally, the user interface (useability) and interface requirements 900 are listed in FIG. 10. The user interface (useability ) component of the user interface (useability) and interface requirements 900 can comprise average user data, and the interface requirements of the user interface (useability) and interface requirements 900 can comprise a print button that can be used to export relevant project data and a user input interface that specifies different user interfaces that may be used to input information to the system. These show high-level needs for how users may interact with the system. It is worth noting that at the architectural level, these requirements may not be immediately' measurable. They are written in such a way to be further derived into system level requirements that will be measurable, specific, and verifiable. The architectural requirements are noted by LR ' in their ID, whereas system level requirements are “sys.’"

[0079] With these architectural requirements in place, the next step is to show that they adequately map back to the original sponsor statements. This is shown in FIG. 11. As seen in ascreenshot 1100, each sponsor statement is satisfied by at least one requirement and each requirement satisfies at least one sponsor statement. Performing Verification and Validation at the architectural level is difficult as many requirements written at this high of level are not directly measurable. In ensuing sections, system level requirements that can be derived directly from architectural requirements will be discussed. These system level requirements are easily- validated and thusly will ensure that the architectural requirements are met as they are hierarchically structured.

[0080] Now that the statements are connected to requirements, the initial set of requirements can begin to inform the solution space. As these are high-level requirements within a living document, this process is not complete. Through modeling, and derivation these will be revised, and further defined both as architectural level and system level requirements. This process will require further stakeholder input, as well as modeling and understanding of the system. This is why further derivation - beyond converting sponsor statements to general architectural requirements - was avoided this early in the process as over-constraint is a serious risk. In summary, a balance can be observed here between solution space definition and constraint. System Level Requirements

[0081] In review of system level requirements as opposed to architecture level requirements, one key difference is more granularity around what specifically is required. This specificity manifests itself often in numerical and measurable callouts in requirements. Care should be taken to ensure that over constraint does not occur and that requirements that prescribe how are avoided. These often go hand in hand but can be avoided with vigilance and deliberation.

[0082] Unsurprisingly, the system requirements may be guided by the architectural requirements. They are different in their level of specificity but paint a similar picture. As a result, the system level requirements fall into the same four categories as the architectural requirements do: Business, functional, interface, and useability. The reasoning behind this hierarchy is the same, but the voice changes. The Architectural requirements were in the voice of the Architect. To a degree, the system level requirements can be the thought of as the voice of the design engineer. The risk here is that as requirements are derived from customer, to architect, to designer, there is a risk of information loss and distortion. To avoid this, repetitive reviews have been conducted with the customer / sponsor and a mapping exercise was performed to ensure there is a relationship between the system level and the architectural level. There is also a focus throughout this section on the relationship between architectural requirements and the system level requirements. Screenshot 1200 in FIG. 12 shows this the general overview of the system level requirements.

[0083] Beginning with business requirements 1300 shown in FIG. 13, there the connection between the requirement to the architecture of the system links the accuracy of project cost, in dollars and labor hours through software. This provides a software aimed to give the sponsor a competitive advantage through, expansion upon at the system level by specifying both costing and labor hour estimation accuracies in sys.bus.l and sys.bus.3. Then, the system also needs to be able to take input to achieve this which is shown in sys.bus.5. Additionally, for costing, the output must be in a human readable format ensuring that budgets can easily be made.

[0084] In terms of architecture to software, the system level requirements around the modeling artifacts being utilizable by the sponsor to develop software are delineated in sys.bus.9 and sys.bus.9.1. This is critical to the sponsor as the MBSE tool is commonly used and will be leveraged by the developers.

[0085] Lastly, there are two requirements (sys.bus.11 and sys.bus.12) that are important business requirements but are not directly derived. They will play into the costing requirement, but not so much as to be derived from it. These requirements relate to the specific steps within RMF that the application will assist the sponsor with. The reason they could be loosely tied to costing is because RMF is much less a process and more of an operating model for risk mitigation. This is due to the overall guidance it provides. As a result, the tool will only be able to assist with costing of control development rather than implementation of the overall framew ork. This distinction primarily deals with overhead costs of management, trainings, and other checks and balances outside simply ensuring the correct families are selected. This scoping leaves developers with the select step of security and privacy framework’s standards, such as the NIST 800-37 which is documented in NIST 800-53a.

[0086] Moving from the business need to usability needs makes natural sense in terms of sponsor priority. The application first needs to have a business purpose, then it needs to be usable. This section, however, has little in terms of architectural requirements. This simplicity is broken out in FIG. 14 for the system level requirements. The system level requirements can be the lowest level requirement of usability requirements 1400.

[0087] Between architectural level and system level requirements there was a shift from '‘framework” to “application.” This is intentional due to sys.use. l which calls out the use of a softw are application. At the architectural level, this would have been over constrained, but when taken with the application needs at the system level, the use of a software application is clear and thus required. With this established, the following requirements will be discussed with the knowledge that the aim for this model will be to support the development of a software application that will be hosted on a developer’s server that will display and collect information.

[0088] To ensure that the system is easily used, the information displayed in text - such as the control families - must be legible. This is called out in sys.use.2 that establishing a threshold and maximum for text size within the application. The guidelines within NIST are very extensive in text and ensuring that this is first readable is important. The next requirement to ensure that it gets read is spelled out in sys.use.4 where the system must be able to render the necessary information in a reasonable time. For example, users must see some kind of action within a prescribed amount of seconds (e.g., 3-5 seconds). Following this latency requirement, the user must be able to get into the application and use it with minimal training. This requirement may be further refined. Additionally, ‘user experience’ and ‘look and feel’ elements may be customized based on vendor-specific preferences. Such as company branding, color scheme preferences, or the like.

[0089] Lastly, the need for previous project recall is called out in sys.use.5. This requirement deals with the user needing to be able to log in, start a session, and complete some tasks then log out without the risk of data loss. This general theme will be seen throughout many of the requirement categories and in effect ensures that the application can support the tight time demands that users have operating in the corporate environment where they may only be able to complete parts of a review at a time.

[0090] Functionally, this system may be quite complex both at the architecture level and the system level. FIG. 14 shows this relationship along with some other relationships between the system level requirements.

[0091] Overrides are a central idea that are important to the sponsor in terms of accuracy in the results of the outputs. The overrides may be captured in in system functions sys.fun.3, sys.fun.3. 1 , sys.fun.4, sys.fun.9, and sys.fun. 10 as shown in FIG. 15. The system functions may be associated with different sub requirements expressed as functional requirements that are in turn associated with architecture level requirements 1500. All these requirements deal with the ability to store overrides to decisions, as well as user inputs as to why they were overridden. Additionally, it is important to be able to track the changes to a project over time, which is also captured in a similar requirement.

[0092] In terms of accuracy, but with respect to the information provided to the user, requirements sys.fun. 1 and sys.fun.6 demonstrate the need for the correct control statements (e.g. , NIST SP 800 53a statements) to be shown. These statements are hierarchical and contain information related to what teams must do to comply with RMF. This is critical for system / application success. The user and team must have the correct information displayed at the correct time.

[0093] Lastly, the information within a framework (e.g., NIST) may be quite involved. For successful use, the system must provide the detail needed to make the right decisions. But there must also be a limit to this so that the user can consume the information. This is where sys.fun.7 tells developers and modelers to provide the right details and the right amounts helping to ensure extensibility.

[0094] Like functional requirements, the system level interfaces may be quite complex, as would be expected with any application. This application may rely on data inputs, internal transformations through interfaces, then output the transformations. The requirements related to this are shown in FIG. 16. User input is needed, and system exports are needed. These requirements may be a part of an architecture level requirements 1500 sub requirement interface requirement. FIG. 16 shows a different set of sub-requirements compared to those shown in FIG. 15. More specifically, FIG. 15 illustrates a sub-requirement of function requirements and FIG. 16 illustrates a sub-requirement of interface requirements.

[0095] For user inputs, the requirements are all effectively ensuring that the user can input data and that the data is displayed. The callout between response or override may vary, but the ideas are the same. Requirements sys.inf. l, sys.inf.2, sys.inf.3, and sys.inf.7 all deal with this type of interface.

[0096] The other overall architectural requirement is for data export. These requirements are to ensure that as the users input data, they can receive the transformed outputs. The sponsor was also quite specific in terms of what was needed like export data. This allows for specification of file type as a .csv which is universally read and recognized file type for information sharing. This is shown in sys.inf.4 and sys.inf.4.1. going along with the specificity provided, the need for a “print button"’ was specifically called out and thus is also listed as a system level requirement in requirement sys.inf.5.

[0097] After thorough coverage of the major requirements hierarchy and the relationships between the architecture level and the system level, a review is required. This is best accomplished by examining the derived relationships between architecture and system level. This relationship is illustrated in FIG. 17. In this diagram, there is a clear many-to-one relationship between the levels. This is expected and shows that these relationships are complex and that some system level requirements may play a partial role in achieving several architectural level requirements. The same is true going the other way. There are no instances where one architectural level requirement can be documented by one system level requirement. This adds confidence that there is robust documentation of system level requirements and that there is an appropriate level of specificity.Solution Development and Alternatives

[0098] For exemplary purposes, the following description will refer to privacy and security framew orks as the NIST standard. It is understood that other framework standards may be applied without departing from the scope of the disclosed technology.

[0099] Due to the hierarchical and relational taxonomy of the NIST standard, as illustrated in the following figures, each control family may be represented modularly with relations to other families. The 20 control families are divided as shown in FIG. 18. FIG. 18 through FIG. 21 are images taken directly from the NIST SP 800-53 publication.

[0100] FIG. 19 illustrates the elements of each control within the control family. Each of these elements are repetitively applied to each control which allows for a standardization of locating information.

[0101] FIGs. 20 and 21 illustrate the hierarchical nature of each control family. In one example, once the basic project elements are created, such as activity diagrams and sequence diagrams, the execution of subsequent control families will be simply replacing the control family specific information. For example, all control families have the first control referencing the policy and procedures applicable to that particular family.

[0102] This example taxonomy lends itself well to an agile management approach where a control family can be thoroughly reviewed, architected, and modeled on its own. Then, with a baseline, this can be scaled in a stepwise fashion through the remaining control families.

[0103] The RMF analysis tool encompasses two proposed use cases. The initial focus is on the user, specifically the project engineer, and their interaction with the Analysis Tool. The project engineer inputs data into the tool, which may involve responding to displayed questions or selecting appropriate categories. During this process, the project engineer might need to document justifications or rationales for inputs to enhance traceability throughout the project. Subsequently, the Analysis Tool generates results based on the project engineer's inputs and internal processes, determining relevant standards, such as NIST 800-53 standards. The tool may also include an additional feature: providing estimated hours for completing each result. A user- friendly experience may be provided, with a "‘Print” button generating a formatted document containing all the applicable standards and their respective time estimations. Refer to FIG. 22 for an illustration of the System Interaction use case.

[0104] The second use case pertains to the Analysis Tool's internal processes. The tool initiates requests for input from the project engineer, which may occur once or multiple times. Subsequently, the system receives corresponding input from the project engineer. Utilizing an internal database containing a copy of standards, such as NIST 800-53 standards, the system willquery the relevant standards based on the project engineer's input. The determined standards are then presented as results to the project engineer. Refer to FIG. 23 for an illustration of the System Processes use case.

[0105] In both use cases, described above, it is assumed that the project engineer possesses or can readily access comprehensive knowledge of the project and its intended use. The absence of such information introduces the risk of inaccurate data being input into the tool.

[0106] The system's functional decomposition reveals four distinctive elements, as depicted in FIG. 24. The initial component, labeled 'Ask for Input,' aims to extract pertinent information from the project engineer regarding the project itself. Diverse mechanisms may be employed for this purpose, ranging from the simplicity of posing a question with a list of selectable options to a more sophisticated approach, such as providing directions and a platform for the upload of project-related files. This element undergoes further refinement into 'Select Control Family' and 'Determine Input Wording,' where the system chooses a Control Family and subsequently determines the phrasing based on the encapsulated Control Enhancements for inquiring about the project. In one example, there is no intention to establish a connection with the Outside World; thus, all NIST standards and details are enclosed within the system. An internal database may be maintained to reflect the latest version of standards through the Architecture Tradeoff Analysis Method (AT AM) described later in this document.

[0107] The second element, 'Receive Input,' acts as the repository for the input provided by the project engineer. It is important to note that the execution of this element is contingent upon the successful completion of the first element, signifying the project engineer's understanding of the need to input project- related information.

[0108] The third element, 'Determine Standards,' can be further dissected into 'Match Input & NSIT Standard, 'Record Match Result', and "Provide Progress.’ The system, based on the input solicited, undergoes matching with the appropriate NIST standards, which consist of Controls and Control Enhancements, and the outcome of this matching process is recorded. Furthermore, an indicator of progress will be generated or updated, offering valuable feedback to the project engineer. The execution of the 'Determine Standards' function is not possible without first receiving input from the project engineer.

[0109] The iterative cycle of the first three elements continues until all NIST Control Families are correlated with the project engineer's input. Only then does the system proceed to the fourth and final element, 'Provide Results.' This conclusive function can be refined into 'Compile All Match Results' and 'Format Results.' In some embodiments, the project engineer will ‘click the Print button,' to execute this function. This action will prompt the system to compile all identifiedmatching results deemed applicable and format the information into a comprehensible file for the project engineer's convenience.System Architecture

[0110] Due to the hierarchical and relational taxonomy of the NIST standard, each control family may be represented modularly with relations to other families. This taxonomy lends itself well to an agile management approach where a control family can be thoroughly reviewed, architected, and modeled on its own. Then, with a baseline, this can be scaled in a stepwise fashion through the remaining control families. This approach also conveniently addresses scoping concerns given a compressed delivery' timeline. As the team is creating the baseline - and ideally subsequent - architectures, the scope can be dynamically modified to fit well within the required timeline while also allowing for the level of detail required in a solution. This development process will yield optimal results for the sponsor and set future software and development teams up for success when productionizing this architecture. Effectively, the agile lifecycle approach will allow for an optimized compromise between complexity and timeline.

[0111] Currently, government contracts, such as those from the DoD, often include a brief statement committing to NIST SP 800-53 compliance. However, this fails to capture the extensive nature of the over 1,000 requirements outlined in SP 800-53. This lack of specificity can lead to ambiguity' regarding which requirements apply to the awarded project. To address this, utilizing NIST 800-53 Risk Management Framework Subject Matter Experts (SMEs) is a potential solution, but this is not always practical during the bidding process. Additionally, discrepancies can arise when one party employs NIST SP 800-53 SMEs and the other does not, potentially leading to misunderstandings and costly efforts to verify numerous requirements or communicate intended purposes effectively. To resolve these potential issues, an Analysis Tool is in development to aid bidding companies, such as governmental and non-govemmental entities. This tool aims to reduce the risk associated with the absence of NIST SP 800-53 SMEs.

[0112] The RMF analysis tool encompasses two proposed use cases. The initial focus is on the user, specifically the project engineer, and their interaction with the Analy sis Tool. The project engineer inputs data into the tool, which may involve responding to displayed questions or selecting appropriate categories. During this process, the project engineer might need to document justifications or rationales for inputs to enhance traceability throughout the project. Subsequently, the Analysis Tool generates results based on the project engineer's inputs and internal processes, determining relevant NIST 800-53 standards. The tool also includes an additional feature: providing estimated hours for completing each result. The sponsor envisions a user-friendly experience, with a “Print” button generating a formatted document containing allthe applicable standards and their respective time estimations. Refer to FIG. 22 for an illustration of the System Interaction use case.

[0113] The second use case pertains to the Analysis Tool's internal processes. The tool initiates requests for input from the project engineer, which may occur once or multiple times. Subsequently, the system receives corresponding input from the project engineer. Utilizing an internal database containing a copy of NIST 800-53 standards, the system discerns the relevant standards based on the project engineer's input. The determined standards are then presented as results to the project engineer. Refer to FIG. 23 for an illustration of the System Processes use case.

[0114] In both use cases, described above, it is assumed that the project engineer possesses or can readily access comprehensive knowledge of the project and its intended use. The absence of such information introduces the risk of inaccurate data being input into the tool. Illustrative examples of graphical user interfaces is provided by FIGs. 40A-40Z.

[0115] The system's functional decomposition reveals four distinctive elements, as depicted in FIG. 24. The initial component, labeled 'Ask for Input,' aims to extract pertinent information from the project engineer regarding the project itself. Diverse mechanisms may be employed for this purpose, ranging from the simplicity of posing a question with a list of selectable options to a more sophisticated approach, such as providing directions and a platform for the upload of project-related files. This element undergoes further refinement into 'Select Control Family' and 'Determine Input Wording,' where the system chooses a Control Family and subsequently determines the phrasing based on the encapsulated Control Enhancements for inquiring about the project. Currently, there is no intention to establish a connection with the Outside World; thus, all NIST standards and details are enclosed within the system.

[0116] The second element, 'Receive Input,' acts as the repository for the input provided by the project engineer. It is important to note that the execution of this element is contingent upon the successful completion of the first element, signifying the project engineer's understanding of the need to input project-related information.

[0117] The third element, 'Determine Standards,' can be further dissected into 'Match Input & NSIT Standard, 'Record Match Result, and ‘Provide Progress.’ The system, based on the input solicited, undergoes matching with the appropriate NIST standards, which consist of Controls and Control Enhancements, and the outcome of this matching process is recorded. Furthermore, an indicator of progress will be generated or updated, offering valuable feedback to the project engineer. The execution of the 'Determine Standards' function is not possible without first receiving input from the project engineer. The match between the received input may correspondto the data through a unique naming system that corresponds one to one. A matching process may use exact matching and / or pattern matching of key words or digits. In some instances, the systems disclosed herein may use the same naming system as the that used in the standards so that the input information matches with the information recorded in the standards.

[0118] The iterative cycle of the first three elements continues until all NIST Control Families are correlated with the project engineer's input. Only then does the system proceed to the fourth and final element, 'Provide Results.' This conclusive function can be refined into 'Compile All Match Results' and 'Format Results.' As per the sponsor’s preference, the project engineer will ‘click the Print button,' to execute this function. This action will prompt the system to compile all identified matching results deemed applicable and format the information into a comprehensible file for the project engineer's convenience.

[0119] The approach employed to address risk mitigation for the RMF analysis tool framework involved using the Architecture Tradeoff Analysis Method (AT AM). The package diagram presented in FIG. 25 illustrates the elements considered within this approach. These elements encompass Business Drivers, Architecture Views, Approaches and Quality’ Attributes, The Utility Tree, Scenarios. Scenario Analysis, and Identified Risks.

[0120] The overarching goal of the ATAM methodology is to extract and refine a precise statement of the architecture's driving quality7attribute requirements, which subsequently influences the precise statements of the architecture design decisions. First, the identification of business drivers took place. In this context, a business driver is defined as the project manager's description of the business goals motivating the development effort and serving as the primary architectural drivers. As showor in FIG. 26 below, the ‘Sponsor Driver Statements’ provide the reason for the work to begin and are defined as the ‘Complexity7of the RMF’ and ‘Contract Risk Exposure’. The ‘Complexity of the RMF’ statement encapsulates today’s status where it is difficult to appropriately scope projects needed to be RMF compliant. The ’Contract Risk Exposure’ statement encapsulates the risk all parties are exposed to without a complete RMF review. Another business driver identified is the general constraint of needing to comply with ‘Applicable Legislation’. The final two business drivers are business requirements ‘Costing’ and ‘Competitive Advantage’.

[0121] The business drivers flowed to the Quality7Attributes. FIG. 27A represents the quality attributes and their relation to the planned approaches. The quality’ attributes are as follows: modifiability, extensibility, modularity, usability7, openness, and simplicity. The figure below shows their connection with the approaches. The approaches selected include Object Oriented Programming, Desktop Based Application, Create a standard format for control families, andBuild a Database of Standards. These approaches were selected based on the business drivers to set a foundation for eliciting design decisions. FIGs. 27B and 27C depict the same information as above but in an easy -to-read format.

[0122] In the AT AM process, the fifth step involves constructing the utility tree. This tree, shown in FIG. 28, serves as a tool that enables a quick comprehension of how quality attributes are detailed down to specific sub-factors referred to as attribute concerns. These concerns represent specific factors that the architecture must specifically address.

[0123] For Extensibility, the concern is the inability to include additional control families. This is a posed concern since there is a possibility that what is generated for one control family may not be directly transferrable to another control family for the NIST Standard. For Modularity, the concern is that rework is required to include multiple control families. This is a concern for the inability to directly transfer the code development from one group to another. Usability has tw o concerns, aversion to using the system due to cumbersome structure and significant training required to use the system. This concern arises from the complexity of the NIST SP 800-53 standard having many control families and line items for compliance that could cause the structure to be too complex to navigate thus requiring extensive training. Modifiability also has two concerns, the inability to adjust software code during code development and the inability to adjust to NIST standard revisions. These concerns stem from the control groups’ variance, and that there are multiple revisions of this standard. It could be hard to incorporate these changes if the code is not easily modifiable. For Openness, the potential concern is the licensing cost to use the system. And finally. Simplicity' has three concerns. The first two are from the user’s perspective which is aversion to using the system due to complexity' and confusion on how to use to interact with the RMF analysis tool. The third concern is from the programmer’s perspective which is implementation challenges due to overly complex architecture.

[0124] Scenarios were created as part of the next step. They are shown in FIG. 29. The first scenario identified is RMF NIST 800-53 has a revision. If a revision is made to the standard this could lead to changes within the tool to remain in compliance. The second scenario is when the user requests an output format change. The request to change the output format could modify what inputs are necessary and how the data is processed through the analysis tool. The third is a new user is trained on the tool. The new user can induce a different perspective of how the system operates. The fourth is a new control family is added to the tool. The new control family can update processing times and potential complexity. The fifth scenario is if the user will have to pay for any licensing or fees. If these fees apply this may change who has access to the analysis tool. The sixth scenario is when the user wants to run the tool on a different machine. This needsto be considered to determine what parameters will need to be reset when opening the item on a new device. The scenarios were added to the Utility Tree to create the Final Utility Tree, as shown in FIG. 30.

[0125] The next step is to analyze the scenarios to identify tradeoff points, sensitivity points, and risk themes. The RMF analysis system is comprised of many different views. FIG. 31 shows the architecture from the user's perspective. At this time, it is only expected that the user will be interacting with the system through the previously described system interaction use case.

[0126] FIG. 32 shows the architecture from the code developer’s view. There are currently three different views. The first is the Requirement Matrix 3200 in FIG. 32A linking the sponsor’s statements to engineering requirements. The second is the sequence diagram 3201 in FIG. 32B for certification using previous audit data. The third is an activity diagram 3202 in FIG. 32C detailing the high-level activities necessary to certify’ the RMF analysis tool using a simple product. Both the sequence diagram and the activity diagram will be described further later in this document.

[0127] FIG. 33 shows the architecture from the code developer’s view. There are currently three different views. The first is the previously described system processes use case 3300 in FIG. 33A. The second is the list of all 20 control families 3301 in FIG. 33B. The third is the functional decomposition 3202 in FIG. 33C. The second and third views are important to the code developer as they describe the scope of the program and the high-level capabilities that need to be programmed.

[0128] FIG. 34 shows the architecture from the system interface perspective. Currently, there is only the white box diagram that provides the inputs and outputs of the system. The white box diagram is detailed in the next paragraph. This diagram will be updated if another view is determined to be applicable.

[0129] FIG. 35 illustrates an example of the disclosed system. Four inputs are entering the white box that includes the NIST 800-53 Standards, Project Engineer Response, Project Engineer Justification, and Project Backstop. The Outputs of this sy stem include the Applicable NIST Standards and the Estimated Hours to Complete per Standard. This white box shows the inputs and outputs necessary for the system to work. The Project Engineer’s Response, NIST 800-53 Standards, and Project Backstop are the critical inputs. Without any of this information, the RMF analysis tool cannot operate. Project Engineer Justification is not critical as this input is for convenience and documentation of the rationale for the response. The key interfaces are between the RMF analysis tool and the project engineer. This interface allows for project information to flow from the project engineer to the tool itself. Another key interface is between the RMFanalysis tool and the Project Backstop. This interface allows for the costing information to be incorporated into the RMF analysis tool.

[0130] Moving from the viewpoint to the overall system of interest is a NIST SP 800-53 compliant framework that can modularly and flexibly simulate various organization or project risks to effectively assess and address organizational unique risks. This will be a complex multimission system that will have the ability’ to interpret the 20 different control families. The system is complex because of the differences between the control families. And the system will be multimission because it will be capable of assessing many different proposed projects. The scope will start with the feasibility’ of a single control family before implementation of the remaining 19. This framework will consider the controls within that respective control family and provide a compliance assessment.

[0131] The quality attributes were determined while following the SEI Architecture Tradeoff Analysis Method (ATAM). The ranked list, from highest priority to lowest, may include modifiability, extensibility, openness, modularity, usability, and simplicity.

[0132] The highest priority’, Modifiability, needs to be considered as revisions are made to the standard. As stated in the scenario the RMF analysis framework and tool need to be able to adapt or modify when the NIST SP 800-53 is revised. Additionally, it is important in the early implementation stages to make sure that the code of the RMF analysis tool can be modified and not cause unfixable breaks. This can be accomplished through the robustness of the code. The next highest priority, Extensibility’, is important to consider because it allows for the RMF analysis tool to extend to additional control families in the event NIST SP 800-53 adds an additional control family or control. Openness is critical for the RMF analysis tool because the sponsor has stated the need for the tool to be a non-proprietary product that is usable for a range of classified and unclassified project types and would not be limited in work type scope. This is a critical element to consider since it is a user requirement. Modularity will be important for this system since there are twenty control families. The goal will be to build the RMF analysis framework and tool such that the structure of one control family can be copied for the remaining nineteen. The plug-and-play mentality for the different control families will allow for a robust code that could easily be updated and re-implemented as changes to the standard revise. Usability is essential for the system since this framework analysis tool will be processing over a thousand controls and this could be cumbersome to work through. The usability of the system will need to be prioritized so that it can be easily implemented into the w orkforce. The analysis tool should keep the user in mind in the construction of how this will be implemented into the real-world application. Simplicity is to follow usability as these elements appear to go hand in hand toaccomplish a simplistic user interface for the customer to execute the analysis tool and provide meaningful and easy-to-understand results. If the tool is too complicated it would not benefit the user and therefore the results could not be accurate giving the user false information.System Design

[0133] The architectural system design revolves around the user interface questionnaire presented to the user. The questionnaire is intended to ask the user a series of easy-to-understand True or False questions. For example, all questions asked by the analysis tool may come from the assessment statements in NIST 800 -53A Rev 5. The analysis tool uses the responses to determine which controls within a given control family the user needs to comply with and determines an estimated cost assessment for the task. FIG. 36 shows the high-level architecture for the Supply Chain Risk Management (SR) control family questionnaire. When the user begins the questionnaire for a specific control family, the analysis tool presents them with high-level questions for the selected control family. The 19 control families follow the structure displayed for Supply Chain Risk Management (SR) with respective True or False questions in a questionnaire format. The zoomed-out portion of Figure 52 has very similar looking branches within the activity diagram due to the intent to have the same hierarchy flow down for each respective control family. Aside from the first branch, each branch represents a high-level question and system response for 1 control within the SR control family. There are 12 controls within the SR control family. Some of the controls within SR have subsections and / or control enhancements that cannot be covered with the initial high-level question associated with that control. Some cases, pending the answer to the high-level question, direct the user to additional lower-level questions.

[0134] Additional detail is provided below to show- the relation of the user and the analysis tool interaction through the zoomed-in portion of FIG. 36. The first branch shows hile the user is still answering questions in the questionnaire, the analysis tool continuously saves the questionnaire responses if the user has entered any new- responses. The second branch, the analysis tool presents the user with a question for SR-1, the first control within the SR control family. In the SR-1 example, the question is as follows: ‘"Does your organization have a plan for managing supply chain risks associated with the system or system components?7’ From this point, there are 3 total paths that could emerge based on the user’s responses, and each path is detailed out below:

[0135] Path #1 : The user answers no to the question. The analysis tool then asks the user whether the user believes the user’s system / organization needs to comply with SR-1. The user responds by saying SR-1 is needed for their system. Because the user indicates their system is not yetcompliant with the high-level SR-1 question but needs to be, the analysis tool assumes the user needs to take actions for complying with the entirety’ of SR-1, including its subsections and control enhancements. Therefore, the analysis tool asks the user for a labor grade and labor hours associated with all of SR-1, so the tool can utilize that information w hen it comes up with a total cost.

[0136] Path #2: The user answers no to the high-level SR-1 question but indicates their system does not need to comply with SR-1. In this scenario, the analysis tool adds a $0 cost associated with SR-1 and requests the user to write a freeform response as to why the user believes their system does not need to comply with SR-1. The freeform response by the user is important for auditing because the user / organization would at least have some reasoning documented as to why they chose to not comply with a certain control / control enhancement.

[0137] Path #3 The user answers yes to the high-level SR-1 question. The analysis tool then displays the lower-level SR-1 questions to gain a better understanding of which portions of SR- 1 the user is already compliant with vs what is still needed for compliance.

[0138] FIG. 37 shows the low-level architecture for SR-1 questionnaire. The zoomed-out portion of FIG. 37 looks similar to the zoomed-out portion of FIG. 36. This is intentional for the structure of the questionnaire to remain the same regardless of w hich portion of the questionnaire is being presented to the user. Similar to the zoomed-in portion of FIG. 36, the zoomed in portion of FIG. 37 starts off by presenting the user with a Yes or No question that corresponds to a subsection of SR-1. There are also 3 possible paths depending on the user’s responses. Each path is detailed out below:

[0139] Path #1 : The user answers no indicating their system is not currently compliant with SR- la QI. The analysis tool then asks the user whether the user believes the user’s system / organization needs to comply with SR-la QI. The user responds by saying SR-la QI is needed for their system. Because the user indicates their system is not yet compliant with the low-level SR-la QI question but still needs to be, the analysis tool asks the user for a labor grade and labor hours associated with SR-la QI, so the tool can utilize that information when it comes up with a total cost.

[0140] Path #2: The user answers no to the question but indicates their system does not need to comply with SR-la QI. In this scenario, the analysis tool adds a $0 cost associated with SR-la QI and requests the user to write a freeform response as to why the user believes their system does not need to comply with SR-la QI.

[0141] Path #3: The user answers yes to the question. In this scenario, the user is indicating their system is already compliant with a lower-level section of SR-1. This indicates there is noadditional work the user needs to do for this lower-level section aside from their standard operating procedures, so the analysis tool adds a $0 cost to the cost model for SR- la QI.

[0142] In some embodiments of the disclosed technology, guidance to get to the True False questions may be provided. For example, a Landing Page may provide context on how to navigate the tool, refer to FIG. 38.

[0143] First the application will collect meta data about the user, for example the username and confirm credentials. Next the application will prompt the user to enter the project they intend to work in. These pieces of information wi 11 automatically kick off saving the User ID, Project ID, and Load previous responses within that specific project. The next prompt will have the user input the control family he / she wants to work on. Once the control family is selected, the application will automatically determine if that control family is complete or still requires information. In the event the user selects a completed control family, the application will determine if all 20 control families are also complete. If one control family is not completed, the user will be prompted to select another control family.

[0144] When the user selects an incomplete control family, there will be another prompt within the application to have the user select one of three options. Two of the options “True to ah” and “False to all” are colloquially called the Nuclear options. They apply a broad assumption to the entire control family. The “False to all” option will not apply any cost estimates and skip over answering any additional questions. The “True to all” option will have the user enter in the expected labor grade and hours for the control family. This information will be used by the Project Backstop integration / connection later. The third option “Enter Evaluation” will send the user into the True False activity diagrams as shown in FIG. 36: High Level SR Questionnaire and potentially FIG. 37: Low' Level SR-1 Questionnaire. The user w ill be sent to the Summary Page after all control families are completed.

[0145] The summan page as shown in FIG. 39 shows the activities that will occur once all the control families are completed. First the application will summarize the Labor Hours. Then it will connect with Backstop to determine the pay information. This information will then be summarized on a line-item basis. The estimated cost per control, not just at the control family level, is crucial to providing the objective evidence and traceability to the overall projected cost for bidding. Because the sponsor wants this in an easy to consume and read format, the information will be saved as a .csv file and a table will display the results. The application will have the option for the user to export the information to a local drive.

[0146] FIG. 41 illustrates a flow diagram 4100 that may be executed betw een RMF computing device 102 and user device(s) 108. The RMF computing device 102 may transmit a request tothe user device(s) 108 for user credentials 4101, and the user device(s) 4103 may respond by providing user credentials 4103. The RMF computing device 102 may then request a project identifier (ID) 4105 from the user device(s) 108. The user device(s) 108 may provide the project ID 4107. The RMF computing device 102 may then load project data 4109 corresponding to the project ID 4107. The RMF computing device 102 may then request a control family 4111 from the user device(s) 108, and the user device(s) 108 may provide a control family selection 4113. An iterative process of prompting a user to answer new. or next, questions while existing questions go unanswered 4117 may occur while the RMF computing device 102 provides next questions 4115 and the user device(s) 108 provide control family selections 4119. As responses are provided by the user device(s) 108 the RMF computing device 102 can save questions responses 4121, and then update a cost model 4123 associated with the project ID. The RMF computing device 102 can render a cost report 4125 on the user device(s) 108 and the user device(s) 108 can request a download 4127 from the computing device 102, and the RMF computing device 102 can convert 4129 the requested download into a report which can be uploaded 4131 to the user device(s) 108.Additional Considerations

[0147] A risk management framework (RMF) is a structured approach used to identify, assess, manage, and monitor risks. An RMF may include, for example, risk identification, risk assessment, risk mitigation, risk monitoring and review, communication and reporting, and documentation. The objective of risk identification is to identify potential risks that could affect the project or organization. RMF may include methods such as brainstorming, checklists, historical data analysis, and expert judgment. An objective of RMF is to evaluate the identified risks to understand their potential impact and likelihood. Methods of RMF may include, for example, qualitative and quantitative analysis, risk matrices, and probability -impact charts. The objective of risk mitigation is to develop strategies to reduce or eliminate the impact of risks. Methods of risk mitigation may include avoidance, reduction, sharing, and acceptance strategies. Risk monitoring and review may include methods to continuously monitor risks and the effectiveness of mitigation strategies. This may be done via regular risk reviews, audits, and performance metrics. The RMF helps organizations proactively manage risks, ensuring they are prepared to handle potential issues effectively.

[0148] NIST Special Publication 800-53 (NIST 800-53) is a comprehensive set of guidelines developed by the National Institute of Standards and Technology (NIST) to help organizations manage and secure their information systems. The NIST 800-53 provides a catalog of security and privacy controls for federal information systems and organizations. Further, it aims to protectagainst a wide range of threats and risks. Initially, NIST 800-53 was designed for U.S. federal agencies, but is applicable to any organization seeking robust security and privacy controls. NIST 800-53 is divided into families of controls, such as access control, incident response, and risk assessment. Each control family address specific aspects of information security and privacy. Updates are applied to NIST 800-53 and released as revisions, currently Revision 5, to address modem security challenges and integrates privacy controls more comprehensively. NIST 800-53 is essential for organizations aiming to establish a strong security posture and ensure compliance wi th federal regulations.

[0149] Reference in this disclosure to “one embodiment” or to “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment, and multiple references to “one embodiment” or to “an embodiment” should not be understood as necessarily all referring to the same embodiment or to different embodiments.

[0150] The above discussion is meant to be illustrative of the principles and various embodiments of the present disclosure. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims

WHAT IS CLAIMED IS:

1. An apparatus comprising: a memory storing computer readable instructions storing; and at least one processor configured to execute one or more computer executable instructions thereby causing the at least one processor to: display, via at least one dynamic user interface, one or more fields associated with data corresponding to a project; receive, via the at least one dynamic user interface, information related to the data corresponding to the project; send at least one query to at least one privacy and security framework compliance device, the at least one query' comprising a request for at least one privacy and security compliance document that is potentially relevant to the project; display at least one prompt, via the at least one dynamic user interface, requesting additional data pertaining to the project based on one or more controls of the privacy and security framework compliance document; and determine that the at least one privacy and security document is relevant to the project; and display, via the at least one dynamic user interface, the at least one privacy and security compliance document.

2. The apparatus of claim 1. wherein the privacy and security’ framework compliance document includes a plurality of control elements.

3. The apparatus of claim 2, wherein the plurality of control elements provide protection for a computer netw ork and critical data stored on the computer netw ork.

4. The apparatus of claim 1, wherein subsequent prompts displayed by the at least one dynamic user interface are based on the additional data pertaining to the project and dependencies of the one or more controls of the privacy and security framework compliance document.

5. The apparatus of claim 1, wherein the at least on processor is further configured to execute the computer readable instructions thereby causing the at least one processor to: output at least one network security plan related to the project.

6. The apparatus of claim 5, wherein output comprises a cost basis of the at least one project proposal for each of the one or more controls.

7. The apparatus of claim 1, wherein the at least one processor is further configured to execute the computer readable instructions thereby causing the at least one processor to: select a control family prior to the display of the one or more fields associated wi th data corresponding to the project; and determine input wording that is used to generate the one or more fields associated with data corresponding to the project, in response to selecting the control family.

8. The apparatus of claim 1, wherein the at least one processor is further configured to execute the computer readable instructions thereby causing the at least one processor to: determine a match between the received information related to the data corresponding to the project and the at least one privacy and security compliance document that is potentially relevant to the project.

9. A non-transitory computer readable medium comprising computer readable code executable by one or more processors to: display, via at least one dynamic user interface, one or more fields associated with data corresponding to a project: receive, via the at least one dynamic user interface, information related to the data corresponding to the project; send at least one query to at least one privacy and security framework compliance device, the at least one query comprising a request for at least one privacy and security compliance document that is potentially relevant to the project; display at least one prompt, via the at least one dynamic user interface, requesting additional data pertaining to the project based on one or more controls of the privacy and security framework compliance document; and determine that the at least one privacy and security document is relevant to the project; and display, via the at least one dynamic user interface, the at least one privacy and security compliance document.

10. The non-transitory computer readable medium of claim 9, wherein the privacy and security framework compliance document includes a plurality of control elements.

11. The non-transitory computer readable of claim 10, wherein the plurality7of control elements provide protection for a computer network and critical data stored on the computer network.

12. The non-transitory computer readable of claim 9, wherein subsequent prompts displayed by the at least one dynamic user interface are based on the additional data pertaining to the project and dependencies of the one or more controls of the privacy and security framework compliance document.

13. The non-transitory computer readable of claim 9, wherein the at least on processor is further configured to execute the computer readable instructions thereby causing the at least one processor to: output at least one network security plan related to the project.

14. The non-transitory computer readable of claim 13, wherein output comprises a cost basis of the at least one project proposal for each of the one or more controls.

15. The non-transitory computer readable of claim 9, wherein the one or more processors are further configured to execute the computer readable code thereby causing the at least one processor to: select a control family prior to the display of the one or more fields associated with data corresponding to the project; and determine input wording that is used to generate the one or more fields associated with data corresponding to the project, in response to selecting the control family.

16. The non-transitory computer readable of claim 9, wherein the at least one processor is further configured to execute the computer readable instructions thereby causing the at least one processor to: determine a match between the received information related to the data corresponding to the project and the at least one privacy and security compliance document that is potentially relevant to the project.

17. A method comprising: displaying, via at least one dynamic user interface, one or more fields associated with data corresponding to a project; receiving, via the at least one dynamic user interface, information related to the data corresponding to the project: sending at least one query to at least one privacy and security framework compliance device, the at least one query comprising a request for at least one privacy and security compliance document that is potentially relevant to the project; displaying at least one prompt, via the at least one dynamic user interface, requesting additional data pertaining to the project based on one or more controls of the privacy and security framework compliance document; anddetermining that the at least one privacy and security document is relevant to the project; and displaying, via the at least one dynamic user interface, the at least one privacy and security compliance document.

18. The method of claim 1, wherein the privacy and security framework compliance document includes a plurality of control elements.

19. The method of claim 18 wherein the plurality of control elements provide protect on for a computer network and critical data stored on the computer network.

20. The method of claim 17, wherein subsequent prompts displayed by the at least one dynamic user interface are based on the additional data pertaining to the project and dependencies of the one or more controls of the privacy and security framework compliance document.

Images