In cybersecurity, we’ve all heard the term “shift left,” and there is a good reason why.
As humans, we know we have a better chance of curing a disease if we catch it early.
“Shift left” brings that concept to technology.
If we implement security as early in the development process as possible, we make it more likely that we deploy secure products, reducing vulnerabilities and increasing system resilience. As a byproduct, shifting left also makes it more likely that a product will not only be secure from the start, but also remain secure over time. Security processes that are embedded into the development process from the beginning will also become integral to the product lifecycle, rather than an afterthought.
If we shift left, we can also more easily shift right when needed.
For teams deploying IT infrastructure on US Department of Defense networks, any effort to shift left won’t happen without the Risk Management Framework (RMF). In a step-by-step progression, the RMF lays out the roadmap that leads organizations to obtain an Authorization to Operate (ATO), granting official permission to operate in a federal environment.
The RMF is critical, yet a map can’t get you where you’re going on its own. A person needs to follow it, and they need to take the right steps along the way. To be successful, the RMF requires security and engineering teams to work together. But in practice, this process too often breaks down into an endless back-and-forth between the two sides that grinds everything to a crawl. Instead of shifting left, security becomes a drag on the whole process, turning ATOs into a dreaded process that takes months and is viewed as a box-checking exercise.
To shift all the way left, we must go beyond RMF to create a holistic process of security control management that integrates security, engineering, and compliance, while taking advantage of automation tools and workflows such as DevSecOps and CI/CD. Through security control management, teams can create policies that are tailored to their deployment, continuously enforced, automatically remediated, and easily validated. Best of all, this process is repeated in a cycle that keeps systems secure over time.
If we get this right, security can become an enabling force that drives a system to rapid deployment and continuous improvement, rather than a dreaded albatross that leaves projects delayed, over budget, and out of compliance.
In this article, we’ll break down today’s RMF realities, and the security control management solutions that make key improvements.
Let’s take a look at RMF vs. Reality:
The requirement: You can’t take a cookie-cutter approach to security. Every deployment is different, and that means the security controls required for each deployment will vary, as well. Before you can secure a system, you have to identify its specific attributes, and choose the controls that can secure it. NIST SP 800-53 provides a list of controls in numerous categories, and those must be evaluated for a particular environment.
RMF Steps:
The reality: To select the right security controls, teams must consider the types of data, the people who access it, and where the system is deployed. This is more complicated than selecting from a list. Security teams have to map the industry-wide regulations, to the needs of their organization, environment, and team. You must also consider the technical implementation.
The SCM Solution: Tailoring. Create a profile that is customized to a deployment. This lays out the benchmarks for the specific controls that are required, and how they will be technically implemented. Beyond a static checklist, this tailored policy is the living source of truth about a system that can be dynamically updated over time.
The requirement: Security produces a list of controls that are needed. Then, security hands the list off to engineering to implement them into the system as part of the build.
RMF Step:
The reality: Security teams provide engineers with spreadsheets containing guidance on what needs to be done, but they say nothing about how engineers without security experience are supposed to accomplish these tasks, and they aren’t in a language that engineers can fit into a workflow. So engineers try the best they can, and even find standardized implementation guides to help, but these don’t speak exactly to their system. This leads engineers to invent new processes and workarounds to satisfy security requirements. It’s an incredibly hard and arduous set of tasks. Engineers spend their time solving bureaucratic problems, instead of real issues.
The Solution: Again, it’s the policy. The policy created during the initial steps delivers information as engineering artifacts. These can be integrated into engineering tasks, and into workflows such as DevSecOps and CI/CD. This creates a common language for security and engineering. In turn, a configuration management engine can provide regular enforcement on a customized schedule. Infrastructure can be built directly from the policy, and that policy can be enforced over time. As a result, the process of hardening the system is automated.
The requirement: With controls implemented, engineering hands the system and documentation back to security. Then, security must perform a check to make sure that the right controls are in place, and that they are working to secure the system.
RMF Steps:
The Reality: After engineering completes implementation, security scans the system. The scan results are delivered back to engineering. Then, engineers must review the scan results, and determine whether they are 1) correct and 2) how to fix them. Scanners produce many false positives and negatives, so the first step takes time, as does documentation. Then, they must essentially return to the work of the implementation step to fix the issues. This can lead to multiple back-and-forths, as engineering takes one approach, security determines whether it is correct, and the two sides talk past each other.
The Solution: Security takes the documentation provided by engineering and a scan is completed. When drift is discovered, systems can be automatically remediated, turning them into self-healing environments. In turn, scans provide security teams with documentation that demonstrates compliance.
The requirement: Once security completes the scan, results must be provided to senior officials in order to accredit the system.
RMF Step:
The Reality: Officials must run their own process that includes a judgement call to assess whether the system is operating within an acceptable level of risk. It is not black and white. This requires documentation from companies to prove systems are in compliance and that they have followed appropriate steps to get there. Companies typically complete this documentation with the assistance of a Governance, Risk and Compliance tool, which collects evidence and provides documentation.
The Solution: GRC integration. Scan results can be integrated with GRC tools, providing for seamless documentation.
The requirement: Obtaining an ATO doesn’t mean the process is over. Teams must run ongoing checks to determine if systems remain in compliance and under a tolerable threshold of risk over time. If systems fall out of compliance, they must be fixed.
RMF Step:
The reality: The process of monitoring is largely manual. Security must track whether there are updates to controls, and continue to run scans. Then, they must provide any results and required fixes to engineering teams, triggering the same back and forth as the Implementation and Assess step.
The Solution: Shift right. When systems are mission critical, you can’t afford to rebuild, and you can’t have downtime. Security control management provides always-on, automated monitoring, enforcement, and remediation. Security returns once again to the scannable policy and scans the systems. When drift is discovered in results, engineering artifacts are created to provide automated remediation through appropriate workflows. Security is integrated throughout the infrastructure lifecycle.
Today, RMF processes take a one-size-fits-all approach that leaves teams siloed and makes ATOs difficult to obtain. With security control management, the RMF becomes an ongoing cycle that customizes a secure deployment for any environment from the start, fully aligns every part of the team, and reduces errors and paperwork along the way. That’s how we shift left, and right, while raising the bar for security along the way.
Contact us to begin implementing security control management solutions with Sicura today.
In cybersecurity, we’ve all heard the term “shift left,” and there is a good reason why.
As humans, we know we have a better chance of curing a disease if we catch it early.
“Shift left” brings that concept to technology.
If we implement security as early in the development process as possible, we make it more likely that we deploy secure products, reducing vulnerabilities and increasing system resilience. As a byproduct, shifting left also makes it more likely that a product will not only be secure from the start, but also remain secure over time. Security processes that are embedded into the development process from the beginning will also become integral to the product lifecycle, rather than an afterthought.
If we shift left, we can also more easily shift right when needed.
For teams deploying IT infrastructure on US Department of Defense networks, any effort to shift left won’t happen without the Risk Management Framework (RMF). In a step-by-step progression, the RMF lays out the roadmap that leads organizations to obtain an Authorization to Operate (ATO), granting official permission to operate in a federal environment.
The RMF is critical, yet a map can’t get you where you’re going on its own. A person needs to follow it, and they need to take the right steps along the way. To be successful, the RMF requires security and engineering teams to work together. But in practice, this process too often breaks down into an endless back-and-forth between the two sides that grinds everything to a crawl. Instead of shifting left, security becomes a drag on the whole process, turning ATOs into a dreaded process that takes months and is viewed as a box-checking exercise.
To shift all the way left, we must go beyond RMF to create a holistic process of security control management that integrates security, engineering, and compliance, while taking advantage of automation tools and workflows such as DevSecOps and CI/CD. Through security control management, teams can create policies that are tailored to their deployment, continuously enforced, automatically remediated, and easily validated. Best of all, this process is repeated in a cycle that keeps systems secure over time.
If we get this right, security can become an enabling force that drives a system to rapid deployment and continuous improvement, rather than a dreaded albatross that leaves projects delayed, over budget, and out of compliance.
In this article, we’ll break down today’s RMF realities, and the security control management solutions that make key improvements.
Let’s take a look at RMF vs. Reality:
The requirement: You can’t take a cookie-cutter approach to security. Every deployment is different, and that means the security controls required for each deployment will vary, as well. Before you can secure a system, you have to identify its specific attributes, and choose the controls that can secure it. NIST SP 800-53 provides a list of controls in numerous categories, and those must be evaluated for a particular environment.
RMF Steps:
The reality: To select the right security controls, teams must consider the types of data, the people who access it, and where the system is deployed. This is more complicated than selecting from a list. Security teams have to map the industry-wide regulations, to the needs of their organization, environment, and team. You must also consider the technical implementation.
The SCM Solution: Tailoring. Create a profile that is customized to a deployment. This lays out the benchmarks for the specific controls that are required, and how they will be technically implemented. Beyond a static checklist, this tailored policy is the living source of truth about a system that can be dynamically updated over time.
The requirement: Security produces a list of controls that are needed. Then, security hands the list off to engineering to implement them into the system as part of the build.
RMF Step:
The reality: Security teams provide engineers with spreadsheets containing guidance on what needs to be done, but they say nothing about how engineers without security experience are supposed to accomplish these tasks, and they aren’t in a language that engineers can fit into a workflow. So engineers try the best they can, and even find standardized implementation guides to help, but these don’t speak exactly to their system. This leads engineers to invent new processes and workarounds to satisfy security requirements. It’s an incredibly hard and arduous set of tasks. Engineers spend their time solving bureaucratic problems, instead of real issues.
The Solution: Again, it’s the policy. The policy created during the initial steps delivers information as engineering artifacts. These can be integrated into engineering tasks, and into workflows such as DevSecOps and CI/CD. This creates a common language for security and engineering. In turn, a configuration management engine can provide regular enforcement on a customized schedule. Infrastructure can be built directly from the policy, and that policy can be enforced over time. As a result, the process of hardening the system is automated.
The requirement: With controls implemented, engineering hands the system and documentation back to security. Then, security must perform a check to make sure that the right controls are in place, and that they are working to secure the system.
RMF Steps:
The Reality: After engineering completes implementation, security scans the system. The scan results are delivered back to engineering. Then, engineers must review the scan results, and determine whether they are 1) correct and 2) how to fix them. Scanners produce many false positives and negatives, so the first step takes time, as does documentation. Then, they must essentially return to the work of the implementation step to fix the issues. This can lead to multiple back-and-forths, as engineering takes one approach, security determines whether it is correct, and the two sides talk past each other.
The Solution: Security takes the documentation provided by engineering and a scan is completed. When drift is discovered, systems can be automatically remediated, turning them into self-healing environments. In turn, scans provide security teams with documentation that demonstrates compliance.
The requirement: Once security completes the scan, results must be provided to senior officials in order to accredit the system.
RMF Step:
The Reality: Officials must run their own process that includes a judgement call to assess whether the system is operating within an acceptable level of risk. It is not black and white. This requires documentation from companies to prove systems are in compliance and that they have followed appropriate steps to get there. Companies typically complete this documentation with the assistance of a Governance, Risk and Compliance tool, which collects evidence and provides documentation.
The Solution: GRC integration. Scan results can be integrated with GRC tools, providing for seamless documentation.
The requirement: Obtaining an ATO doesn’t mean the process is over. Teams must run ongoing checks to determine if systems remain in compliance and under a tolerable threshold of risk over time. If systems fall out of compliance, they must be fixed.
RMF Step:
The reality: The process of monitoring is largely manual. Security must track whether there are updates to controls, and continue to run scans. Then, they must provide any results and required fixes to engineering teams, triggering the same back and forth as the Implementation and Assess step.
The Solution: Shift right. When systems are mission critical, you can’t afford to rebuild, and you can’t have downtime. Security control management provides always-on, automated monitoring, enforcement, and remediation. Security returns once again to the scannable policy and scans the systems. When drift is discovered in results, engineering artifacts are created to provide automated remediation through appropriate workflows. Security is integrated throughout the infrastructure lifecycle.
Today, RMF processes take a one-size-fits-all approach that leaves teams siloed and makes ATOs difficult to obtain. With security control management, the RMF becomes an ongoing cycle that customizes a secure deployment for any environment from the start, fully aligns every part of the team, and reduces errors and paperwork along the way. That’s how we shift left, and right, while raising the bar for security along the way.
Contact us to begin implementing security control management solutions with Sicura today.
Ready to maintain secure and compliant infrastructure focused on cost, automation, and consistency?