I’ve been talking about this challenge my whole career. The current state of best practice is to comply with broad cyber security standards and frameworks that may, but in practice, often do not adequately address software security. In 2021, when president Biden issued an executive order citing software security, I was excited to see a significant first step. The release of the NIST Secure Software Development Framework (SSDF), which finally meant an industry-wide standard around secure software, was a significant related development. The EO applies to software manufacturers who sell to the US federal government. Shifting liability to manufacturers is much broader reaching.

The ramifications of adopting security in the software process are huge and will be costly. Software liability has been so thorny because producing 100% secure software is practically impossible. Thankfully, the strategy introduces the concept of a safe harbor, where organizations can shield themselves from liability by following established best practices, such as those in the SSDF. In doing so, they are following the pattern already established by other standards like the Payment Card Industry (PCI) Software Security Framework (SSF), where organizations can attest to their security by following a Secure Software Lifecycle approach. 

The impending changes will force companies to move away from a testing-only strategy and incorporate more robust security throughout the development process. It will also necessitate audit trails where they don’t usually exist, such as in software design. Security-by-design was the topic of focus by Cybersecurity and Infrastructure Security Agency (CISA) Director Jen Easterly in a recent address at Carnegie Mellon University.

Inevitably, some people will look at this proposed strategy and wait to react. After all, proposing and passing legislation through congress is likely years away. This approach would be a mistake. From our experience, the act of changing software processes across a company to integrate security in every phase can take years since it involves process, behavior, and skill changes. Now that the possibility of software liability has been opened, governments worldwide will take notice, and other countries will pass liability laws even if the US does not. Retrofitting old code into the new process will be onerous; the right time to start planning is right now.

Next Steps

If you’re looking to start with the NIST SSDF, take a look at our whitepaper.

The post White House National Cybersecurity Strategy Takes on Industry’s Third Rail: Liability Shift from Users to Software Manufacturers appeared first on Security Compass.

U.S. federal government agencies are under more pressure than ever before to modernize their IT systems and consistently deliver better services at lower costs. They also must comply with increasingly stringent cybersecurity requirements to obtain Authority to Operate (ATO). Rapidly developing and deploying secure software in a way that meets ATO requirements, especially within environments where software project volume, complexity, and delivery pace are high and security expertise is in short supply. This  makes attaining ATO or maintaining continuous ATO (cATO) extremely difficult. A key part of this is protecting Controlled Unclassified Information.

Protecting Controlled Unclassified Information

To fulfill contracts, it is necessary for the DoD to share sensitive information with its contractors, including classified and Controlled Unclassified Information (CUI). CUI is  defined as  “any information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that is required to be protected under law, regulation, or Government-wide policy.” CUI is much more common than most organizations realize. Even if a company is only a 3rd party supplier to a government contractor, flow-down terms and specifications can be considered CUI. This can include:

• Personally Identifiable Information (PII)
• Sensitive Personally Identifiable Information (SPII)
• Proprietary Business Information (PBI) or currently known within EPA as Confidential Business Information (CBI)
• Unclassified Controlled Technical Information (UCTI)
• Sensitive but Unclassified (SBU)
• For Official Use Only (FOUO)
• Law Enforcement Sensitive (LES)

Cybersecurity Maturity Model Certification (CMMC)

To ensure that DIB contractors establish and maintain effective cybersecurity practices for CUI, the DoD published the Cybersecurity Maturity Model Certification (CMMC) program in 2020. CMMC is a framework that allows the DoD to measure the maturity of an organization’s cybersecurity practices. Rather than build redundant standards, the DoD modeled CMMC on several existing cybersecurity standards, including NIST 800-53, NIST 800-171, The Defense Federal Acquisition Regulation Supplement (DFARS), and International Traffic in Arms Regulations (ITAR).

CMMC 2.0

After receiving agency and contractor feedback about the original standards, the DoD announced CMMC 2.0 in a November 2021 update to streamline requirements. CMMC 2.0 reduced CMMC 1.0’s five tiers of maturity to three: Foundational, Advanced, and Expert. The level of compliance required by an organization varies with the form and caliber of CUI that they work with. A comparison of requirements for CMMC and CMMC 2.0 appears below.

As shown, CMMC 2.0 uses three progressively sophisticated levels, depending on the type of information being managed:

• CMMC Level 1 (Foundational): Level 1. covers only Federal Contract Information (FCI), information that requires protection but is not critical to national security. It is expected to cover most federal contracts and does not include Commercial Off the Shelf software. Level 1 includes 17 security practices derived from FAR Clause 52.204-21: Basic Safeguarding of Covered Contractor Information Systems. Organizations subject to Level 1 controls must provide annual self-assessments and attestations.

• CMMC Level 2 (Advanced) is a requirement for companies with CUI. Level 2 certification requires compliance with the practices detailed in NIST SP 800-171: Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations. It requires triennial third-party assessments for prioritized acquisitions and annual self-assessments for non-prioritized acquisitions.

• CMMC Level 3 (Expert) covers organizations in the highest priority programs with CUI. CMMC Level 3 will require compliance with controls detailed in NIST SP 800-171 as well as a subset of security practices from NIST SP 800-172: Enhanced Security Requirements for Protecting Controlled Unclassified Information: A Supplement to NIST Special Publication 800-171. Level 3 certification will require triennial assessments by the DoD.

CMMC 2.0 Timeline

CMMC 2.0 will not be a contractual requirement until the Office of Management and Budget (OMB) completes rulemaking. While CMMC has experienced some delays, and more may be coming. Last summer the National Law Review anticipated the OMB would issue interim final rules by March 2023. This would mean, CMMC requirements could begin appearing in solicitations as early as 60 days later.

How to Prepare for CMMC

There are several steps organizations can take to prepare for CMC requirements in DoD solicitations. These include:

• Understand your CMMC certification level: Work with your partners to understand the classification of the data you access. While Level 1 controls are required of all organizations, you may need time to comply with the practices in in NIST SP 800-171 and NIST SP 800-172.
• Operationalize compliance: Most organizations audit compliance requirements manually using spreadsheets and shared documents. These are difficult to track for those responsible for complying with the 100+ standards required in a Level 2 or 3 requirement. Providing a centralized platform simplifies communicating, tracking, and auditing controls.
• Threat modeling can help: Threat modeling anticipates threats and assigns actionable controls to development, security, and operational personnel. An automated platform can also map regulatory requirements for CMMC like NIST SP 800-171, NIST SP 800-172, and others to appropriate controls and provide a single resource for all stakeholders to track compliance.

Next Steps

The CMMC is an important program that has made significant progress in protecting government and defense contractors from cyber threats. While there have been challenges and obstacles along the way, the future of the CMMC looks bright and it is likely to continue to play a crucial role in promoting good cybersecurity practices in the government and defense sectors.

To learn more about how SD Elements can provide your organization with a proactive approach to identifying, tracking, and auditing requirements under CMMC and achieving ATO and cATO, check out our resources here.

The post The Current State of CMMC appeared first on Security Compass.

Threat modeling is an exercise in which teams name potential weaknesses that could enter an application through the design and coding phases of development. Once these are enumerated, teams can assign risk mitigation controls to development, security, and operations for implementation during the normal course of development and deployment. By doing so, testing focus shifts to one verification of the controls versus first-pass vulnerability identification. The result is more secure software and fewer issues found late in the development process that slow down new releases.

Manual Threat Modeling? Not in Today’s Environment

NIST’s guidance recommends that threat modeling be conducted “multiple times during development, especially when developing new capabilities, to capture new threats and improve modeling” [emphasis in original]. Unfortunately, in our opinion, this recommendation is unachievable using the referred to threat modeling methods.

NISTIR 8397 references 12 threat modeling methods in a publication from Carnegie Mellon University’s Software Engineering Institute. All are manual. We’ve discussed at length the challenges of manual threat modeling. Briefly, it requires senior engineering and security resources to diagram an application’s architecture and data flow, generate attack trees and generate trust boundaries. When an application changes through “new capabilities,” so does the threat model. Each pass at the threat model can require days of work and discussion, limiting its use to only the organization’s most critical applications. Consequently, manual threat modeling does not scale and inconsistent due to the biases and preferences of the participants. Auditing a team’s progress implementing controls is particularly challenging, as test cases may vary by a team’s preferences and the lack of integrations with automated testing tools and issue trackers.

Authority to Operate and Threat Modeling

U.S. federal government agencies – like most customers – need rapid delivery and security. Manual threat modeling supports only the latter. Software suppliers to the government must also meet ATO requirements or maintaining continuous ATO (cATO). This includes providing evidence they comply with NIST’s Risk Management Framework and thousands of security controls that can vary by deployment environment. Adding or trying to incorporate manual, resource-intensive traditional threat modeling approaches is a difficult approach for even the best funded DevSecOps teams. Tracking thousands of controls and validating their implementation using manual methods across a portfolio of applications is impossible.

To reduce cybersecurity risk at scale, software producers targeting U.S. federal, state, and local government agencies need a different approach to modeling software weaknesses and providing evidence that appropriate controls are in place. To meet the demands of today’s customers it must tightly integrate with product workflows and help product teams deliver secure products at high velocity.

A Better Approach

Organizations producing software for U.S. government agencies need a threat modeling solution that enables them to scale threat modeling for DevSecOps, achieve ATO, and release secure products faster. Like most DevSecOps initiatives, this requires automation.

Automated threat modeling enables teams to quickly identify threats in an application’s programming languages, frameworks, and deployment environments. Threats are then translated into actionable tasks (mitigation controls) and assigned to development, security, and operations for implementation. If a component of the application’s technical stack is added or changed, the threat model and mitigation controls can be updated independent of the rest of the model.

How SD Elements Can Help U.S. Government Agencies with Software Threat Modeling

SD Elements is a secure coding and threat modeling platform that allows organizations to rapidly develop secure, compliant software and interconnected components. Instead of requiring scarce senior security and development resources to spend days modeling an application, SD Elements produces a threat model from a survey of the application’s technical stack. It translates threats into specific, consistent security controls; actionable tasks, including code samples and test plans that mitigate threats. Integrations with Automated Security Testing (AST) tools allow teams to validate that security controls are properly implemented.

SD Elements allows the ultimate shift-left approach to software security. Using SD Elements helps teams anticipate weaknesses in applications and their deployment environments that could be exploited by attackers and build mitigation controls as part of the normal development process. By automating the process, SD Elements reduces threat modeling time by 80 percent or more, allowing teams to scale threat modeling across their software portfolios.

Unlike manual threat modeling methods, SD Elements provides teams with a centralized platform for identifying threats and tracking controls. Its extensive content library is continuously updates by Security Compass’s team of security experts and includes U.S. federal government standards and regulations including the NIST Risk Management Framework (RMF), NIST SP 800-53R5, FedRAMP, Committee on National Security Systems Instruction (CNSSI), and others. Using this built-in application security expertise ensures consistent controls across all programming languages and deployment platforms, on premise or in the cloud.

SD Elements provides a single pane of glass for near real-time reporting on the status of threats and mitigations across an application or portfolio. To reduce workflow disruptions, it integrates with the development tools used every day by teams. It assigns tasks and tracks progress through issue trackers like Jira, Archer, and ServiceNow. It validates the effectiveness of controls through integrations with security testing tools like Checkmarx, Synopsys, Veracode, and others.

Next Steps

If you are a U.S. federal, state, and local government agency that develops software, or are a contractor that develops software for these agencies, learn more about how SD Elements can help you automate and scale your organization’s threat modeling process while maintaining ATO by downloading our recent white paper, Speeding Secure Software Development and Attaining Authority to Operate Faster and at Scale in the U.S. Government Agencies.

The post Understanding Threat Modeling and Executive Order 14028 appeared first on Security Compass.

The software development and IT organizations within U.S. federal government agencies face conflicting challenges. They must defend  systems against constant attacks by criminals, hacktivists, and hostile nation states; however, they are also under pressure to modernize their systems and consistently deliver better services at lower costs.

To help ensure more secure software and systems, the Federal Information Security Modernization Act requires federal agencies to have systems in place to assess and monitor security and privacy risks. Becoming certified to provide software – either through internal government development teams or third parties – requires an Authority to Operate (ATO).

As a prerequisite to achieving ATO, teams must demonstrate compliance with the NIST Risk Management Framework and thousands of security controls depending on the deployment environment. Recent research by Security Compass found more than a third of U.S. federal government agencies reported that it took four or more months to achieve ATO, and 72 percent reported the process lasted greater than two months. This process must be repeated when significant changes are made to systems and at least every three years.

Process and Technical Challenges to Achieving ATO

Although the ATO process is designed to improve the security of government systems and software, it also presents challenges for teams attempting to deliver new, secure systems that can improve missions and reduce costs for government agencies.

• With potentially thousands of requirements, ensuring that all are covered consistently is challenging. Translating those into security policies and specific mitigation controls is even more difficult, requiring effort from scarce security resources.
• Once controls are identified, they must be communicated to development and operations teams for implementation, then tracked for completion. This process is still largely manual. Our research found more than six in 10 organizations use spreadsheets to track security requirements (and almost a third didn’t know how the controls were tracked).
• Manual processes also slow down reporting. ATO achievement requires teams to provide evidence of processes and control implementation. Using shared spreadsheets can be unreliable and make it difficult for program managers and assessors to identify gaps.

Achieving ATO at Scale and Speed

Delivering secure software is a requirement for ATO. Delivering it faster is a requirement of all agencies. Doing both is possible by implementing some best practices into the Secure Software Development Life Cycle (SDLC).

“Companies like Netflix and Google are releasing secure software hundreds of times a day. The public sector, at all levels, can achieve similar results by using a DevSecOps approach and shifting left while maintaining the quality and security needed for ATO.”

Rohit Sethi
CEO, Security Compass

Shift Left
Waiting for security scanning tools to identify weaknesses late in the development lifecycle and the required remediation process slows down releases. “Shifting left” – or moving security into the earliest phases of the SDLC – accelerates development and reduces developer/security friction.

Shifting left requires organizations to anticipate weaknesses in their systems during the Requirements phase of the SDLC — prior to writing code. This allows mitigation controls to be identified and assigned to development and operations as part of the normal development process. The result is faster release cycles with fewer vulnerabilities (and less rework).

Automate
ATO certification requires additional steps in the development and deployment process. Manual practices delay progress. Automation of requirements gathering, assigning remediation controls, and validating completion of tasks reduces manpower requirements and the resulting delays. It also enables organizations to scale their processes across more applications.

Automation of requirements should include the specific obligations of regulatory frameworks in scope for the system or application. For ATO, this includes the NIST Risk Management Framework and supporting standards like NIST 800-53 (Security and Privacy Controls for Information Systems and Organizations) and NIST 800-218 (Secure Software Development Framework).

Integrate
Enabling secure and rapid development requires integration with the tools developers use every day. Rather than maintaining requirements and mitigation controls in spreadsheets, they should be assigned as deliverables in popular issue tracking tools like Jira, Archer, and ServiceNow. Required mitigations can be mapped to results from scanning tools like Veracode, Synopsys, Checkmarx, and Nessus to understand quickly which controls are validated and which remain open.

Centralize Documentation
Authority to Operate requires documentation that appropriate processes are in place and followed. Discrete spreadsheets for each project are difficult to manage, easy to ignore, and subject to untraceable changes. A centralized, controlled, and auditable environment for recording all activity regarding a project’s weaknesses, controls, and mitigation efforts simplifies certification.

Improving software security and reducing ATO effort is possible when you adopt proactive security activities. By anticipating weaknesses in software and systems based on the programming language, frameworks, and deployment environment, and assigning mitigation controls as part of the normal development process, teams can reduce rework later in the SDLC. Providing all users with a centralized and audited platform simplifies tracking open issues and provides the evidence required to satisfy ATO requirements.

Next Steps

To learn more about accelerating your ATO program, read The 2021 State of Secure Development & ATO in U.S. Government Agencies and contact us today.

The post Expert Advice on How to Attain Authority to Operate (ATO) Faster appeared first on Security Compass.

The post Introduction to U.S. Cybersecurity Compliance Requirements appeared first on Security Compass.

The post Achieving Rapid or Continuous ATO (cATO) appeared first on Security Compass.

Cybersecurity training programs for developers help build a culture of security in your organization as well as raise awareness about secure coding best practices. However, due to tight delivery deadlines for mission success, security training programs are usually conducted annually by federal government agencies.

The lack of cybersecurity training among developers can lead to vulnerabilities in applications, which in turn extends the time taken to ensure compliance with regulations, such as the NIST 800-53 Standard Revision 5.

Moreover, traditional training methods aren’t as effective in long-term knowledge retention. That’s why we offer just-in-time training (JITT) to developers so that they can learn and retain security best practices while they code.

Just-in-time security training for developers

SD Elements empowers you to go beyond “shift-left” testing by integrating security and compliance natively from the start through guidance and training materials at each step of the coding process. The intuitiveness of our platform ensures that developers have access to knowledge just when they need it.

For instance, if you’re required to comply with a policy from NIST 800-53 such as AC-6: Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks, you will receive training modules explaining the concept of least privilege in a language you can understand.

SD Elements will also return the following guidance to you so that you can complete the task at hand:

• Restrict access to tables and schemas that are needed.
• Restrict access to actions that are needed (such as select, update, and delete).
• Remove access to stored procedures that the application does not need.

Along with learning while coding, you can build or modify software quickly through easy-to-understand guidance and ensure compliance with regulations.​ A lot of coding is also done by searching code samples on the web. Unfortunately, these code samples often do not follow secure coding practices. Our JITT modules also provide secure code samples that you can use to build secure applications.

Did you know that every federal project in SD Elements includes access to our just-in-time training (JITT) modules?

Our JITT modules assist with completing your security tasks, without having to revisit lengthy training modules, and conduct web research for non-certified security best practices.

The SD Elements library of JITT modules breaks concepts down into bite-sized intuitive exercises, focused on accomplishing specific tasks directly aligned to your compliance requirements. This ensures knowledge is transferred easily and effectively for rapid task completion.

Bridge security training gaps with SD Elements

Training is often an annual requirement for most federal agencies, leaving long periods of time between updates. This often leads to out-of-date training materials which aren’t in alignment with continually evolving compliance standards.

To keep your knowledge up-to-date, our content team regularly updates and adds new JITT modules that align with evolving standards. This not only keeps you updated about new compliance requirements but also saves time in understanding these changes.

As you develop your organizational training plan, JITT modules can serve to fill a strong gap for both developers and assessors.

JITT modules cover both theory and application of the training enabling developers and assessors to gain the knowledge necessary to understand the why and how of implementing a compliance requirement.

How to use JITT with SD Elements

The JITT modules are available to all of our clients in the U.S. federal government space as part of the SD Elements product offering. These modules provide a conceptual foundation needed for completing compliance tasks during coding. In addition, the training materials also describe the security weaknesses and their potential solution.

For instance, at this point, we are working to add 118 new training modules to our JITT library, and these are all mapped to compliance tasks for developers.

Being able to break down compliance into task-based guidance is at the heart of what SD Elements does. Acknowledging the cybersecurity skills gap in the U.S. market and enabling developers to learn security concepts while coding allows you to achieve compliance faster.

If you want to learn how we help federal agencies to achieve Authority to Operate (ATO) faster, please watch this short, 2-minute video.

The post U.S. Federal Government Agencies: SD Elements Embeds Cybersecurity Training Into DevSecOps appeared first on Security Compass.

After years of anticipation, Revision 5 (Rev 5) of National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, “Security and Privacy Controls for Information Systems and Organizations,” is finally here. SP 800-53 Rev 5, a key framework for federal information system security controls, was released on September 23, 2020.

It is a significant update to the standard, designed to protect organizations and systems, including the personal privacy of individuals, well into the 21st century.

Government agencies, contractors, and FedRAMP certified vendors responsible for complying with SP 800-53 Rev. 4 should be working now to review the new standard, identify gaps, and remediate any issues based on the latest revision. According to OMB Circular A-130 (2016), such agencies are expected to be compliant with NIST standards within one year of the publication dates.

What is the NIST SP 800-53 Rev. 5 about?

SP 800-53 Rev. 5 represents a multi-year effort to develop the next generation of security and privacy controls needed to strengthen and support the U.S. federal government.

These next generation controls offer a proactive and systematic approach to ensuring that critical systems, components, and services are sufficiently trustworthy and have the necessary resilience to defend the economic and national security interests of the U.S.

SP 800-53 directly applies to any organization that must comply with FISMA and obtain an ATO certificate, including:

• Federal agencies and departments with applications that process or store federal data.
• Any state agencies or contractors partnered with the federal government.
• Any private sector company that has a contractual relationship with the government, whether to provide services, support a federal program, or receive grant money.
• Cloud Service Providers (CSPs) authorized under a FedRAMP program.
• Non-federal businesses required to comply with Defense Federal Acquisition Regulations (DFARS).

NIST 800-53 has 18 control families with over 900 security controls. Each layer within a software application must be assessed for compliance with these 900 controls. And the process must be repeated when technology changes or new applications are added to a layer.

Demonstrating compliance with 800-53 for FISMA and obtaining ATO can take 9 to 12 months to complete and cost as much as $1 million dollars due to the large number of controls and multiple application layers.

Streamline compliance with SP 800-53

SD Elements can help your organization streamline compliance with the latest version of SP 800-53, demonstrate FISMA compliance, and obtain ATO faster.

Most developers are not application security experts, nor are they experts on the NIST 800-53 standard. SD Elements gives developers what they need to be successful to deliver applications that meet NIST 800-53 security standards. Developers responsible for coding applications required to meet the new NIST 800-53 Rev. 5 standard can start thinking about security upfront, either when they first start coding an application or making updates to existing applications.

SD Elements enables NIST 800-53 compliance and speeds up the ATO process by:

• Generating NIST 800-53 security requirements for baselines (High, Moderate, Low, Privacy).
• Delivering detailed requirements, code samples, and short, relevant training modules relevant for 800-53 Rev. 5 compliance to DevSecOps teams right within issue trackers, like Jira.
• Tracking and monitoring security control status for each application layer.
• Importing results from code scanners to automatically validate security activities.
• Creating NIST 800-53 Rev. 5 reports for compliance management.

SD Elements is used today within several Department of Defense and other federal government agencies, including the U.S. Air Force, and the U.S. Navy. For example, a U.S. Department of Defense DevSecOps software factory recently used SD Elements to reduce the time required to achieve ATO from 12 months to two weeks.

Learn more

Information security is at the heart of every software application within the U.S. federal government. Federal agencies, departments, and contractors with applications that process or store federal data must follow the NIST 800-53 Rev. 5 standard in order to comply with FISMA and obtain ATO.

Now is the time to start updating your applications to the latest version of the standard.

Ready to learn how SD Elements can help you obtain ATO faster? Contact us today.

The post NIST 800-53 Revision 5: Preparing for Transition and Ensuring Compliance appeared first on Security Compass.

With the introduction of the Cybersecurity Maturity Model Certification (CMMC) in the U.S. as a means of unifying cybersecurity standards for the Department of Defense, organizations must consider the impact on their DevSecOps operational activities. There are many stakeholders to consider: business, development, operations, security, compliance, and risk. From a governance perspective, how do we integrate this standard with our DevSecOps teams?

A lot of tools and processes traditionally lack a security perspective.

Given the importance of software development in an organization today, the impact of operationalizing CMMC is not trivial. Many organizations rely on manual spreadsheets to keep track of compliance against standards and frameworks like CMMC. This approach is difficult for traceability and makes third party auditing a laborious process.

Ideally, we want to provide a real-time assessment of the residual software security risk across a portfolio of DevSecOps projects while work is being performed. The goal is to utilize security as an enabler to help the business move faster while facilitating collaboration across multiple stakeholders. This type of approach can help business stakeholders make informed decisions. 

In this article, we will explain how Developer-centric Threat Modeling addresses these pressing issues and a missing gap in the DevSecOps tools landscape.

How Developer-centric Threat Modeling ensures security with speed

Historically, DevOps teams were focused almost entirely on speed of delivery. Our tools were focused on increasing levels of automation and the continuous integration and delivery pipelines reinforced the importance of speed. With the introduction of security practices in DevSecOps, the challenge was in trying to integrate a practice based on security controls into a fast-moving delivery pipeline. The result was either security was left until the last minute, or it slowed down the delivery process — none of which was ideal.

Threat modeling can help. Threat modeling exercises anticipate weaknesses in the application’s technology stack, then prescribe security countermeasures to be implanted during the normal development cycle. Traditional threat modeling requires many days or weeks of time from scarce senior resources and is therefore limited to an organization’s most critical applications. 

Developer-centric Threat Modeling (Developer-centric Threat Modeling) solves this problem by automating software threat model generation, translating those threats into actionable countermeasures and security and compliance best practices, and delivering those directly to developers within existing DevOps workflows. It is an ideal set of tools for environments driven by regulations or standards that involve multiple stakeholders.

There are five key parts to Developer-centric Threat Modeling:.

1.     Information Gathering: SD Elements guides users in a systematic way so that projects are onboarded efficiently. It gathers information about your project, such as its technology stack, deployment infrastructure, security testing tools, and compliance requirement.

2.     Threat Modeling: Based on Security Compass’s extensive knowledgebase of security threats and countermeasures, highly visual threat modeling system dependency diagrams can be generated within a fraction of the time and effort typically required by more traditional manual methods .

3.     Expert Assessment: SD Elements analyzes the information and correlates it with regulations, security and compliance requirements, and industry best practices in the knowledge base .

4.     Recommendations: SD Elements makes intelligent decisions on threats, countermeasures, security controls, just-in- time training, and even code samples specific to your technology and industry, delivered these directly to your issue tracking tools. It also rapidly classifies your project into relative risk grouping to help your teams manage projects by potential risk.

5.     Validation and Reporting: SD Elements tracks countermeasures and  controls and can also validate the status of certain tasks automatically by capturing updates from security testing tools. This gives you a near real-time view into the risk status of your projects, and the controls in scope for each, at any time in the project life cycle.

Implementing CMMC through Developer-centric Threat Modeling

Let’s walk through an example of how Developer-centric Threat Modeling can help an organization attempting to achieve CMMC Level 2.

For this example, let us assume we have a standalone Java application with a database. The simplicity of this architecture will allow us to focus on value creation in the compliance and governance process rather than the technology domain.

A Developer-centric Threat Modeling tool would correlate the CMMC Level 2 guidance with the architectural constraints of the application to identify areas of risk. In this case, that means the intersection of a Java application with a backend database against CMMC Level 2 compliance requirements. The tool would identify the following policy from CMMC:

AC.2.007: Employ the principle of least privilege, including for specific security functions and privileged accounts.

Notice how this is useful from a compliance and security perspective. People in these teams are used to dealing with policies across the lifecycle (from policy creation to termination). However, handing this over to a developer or operations engineer is not prescriptive enough. There may be different ways to interpret what this means and how it should be implemented. The ambiguity surrounding this is not for lack of trying, it is simply speaking a different language between policymakers and engineers. 

What we need is more concrete guidance that contextualizes the above policy into a language that developers, operations, and engineers can understand and implement. As an example, a Developer-centric Threat Modeling tool would offer the following translation:

•       Restrict access to tables and schemas that are needed.
•       Restrict access to actions that are needed (such as select, update, and delete).
•       Remove access to stored procedures that the application does not need.

Notice how the words being used are contextual. Access control, database schemas, and stored procedures instantiate the high-level guidelines into easy-to-understand instructions (thereby reducing wasted time). This example can be further elaborated to contextualize against a particular database platform. The translation between a high-level security guideline and actionable tasks is a key value proposition of Developer-centric Threat Modeling tools. Speed and scale is achieved by integrating the requirements of various stakeholders and codifying with the Developer-centric Threat Modeling tool.

The work performed by engineers continues as normal, using the tools and frameworks with which they are familiar. This limits the need to slow down and learn an entirely new tool.

Once the engineers have completed their work, test cases need to be created to ensure auditability. Developer-centric Threat Modeling tools provide sample test cases as an accelerator. The benefit of having this guidance upfront is that, by shifting testing to the left, we can start to create test cases much earlier. Additionally, the prescriptive nature of the test cases allows for the traceability of these test cases to the CMMC policy. Here is an example of the prescriptive output:

•       Test #1: Review the source code to determine the account that the application uses to connect to its database at runtime. The test fails if the application uses a database super-user account.
•       Test #2: Review the database permissions for the user. The test fails if the user has more permissions than it requires (such as ability to drop tables, alter the database schema, or execute unnecessary prepared statements).

Once again, the language is relevant to the testing stakeholder. If the test cases pass, that rolls back into AC.2.007 as a successful completion. In this way, each clause in the CMMC standard has auditability and traceability while retaining an emphasis on delivery speed. These test cases can be performed through automation or human-in-the-loop processes. By combining these results, teams can identify areas of weakness and provide evidence of additional training or guidance to build the required capabilities for business assurance.

At the end of a cycle, a CMMC report can be generated from the Developer-centric Threat Modeling tool that shows whether all relevant technical tasks have been completed to comply with CMMC Level 2. In doing so, multiple stakeholders can interact in a way that integrates their processes without requiring extensive process or architectural rework.

The example above illustrates Developer-centric Threat Modeling tools in the context of compliance, development, operations, and testing. But it is not difficult to extend this to include architects (with prescriptive requirements on readable/writeable classes, for example) or database authentication for operations teams. The intent is to demonstrate how CMMC operationalization can occur in a fast-moving delivery pipeline.

Focusing on integration and automation

As stated at the beginning of this article, security and compliance activities often operate in their own silos. That makes integration with fast-moving continuous integration and delivery cycles difficult. Artifacts produced from one team are not easily ingested into downstream systems. That creates unnecessary noise and makes system integration and automation difficult to achieve.

True integration and automation is achieved through harmonization of the underlying metadata across multiple stakeholder systems. This allows organizations to synchronize processes and systems without having to force expensive configuration work into all the systems. 

Integration in a Developer-centric Threat Modeling context does not preclude second and third level integration. For example, developers can still use code scanners as part of their testing and the results can feed into a Developer-centric Threat Modeling tool to prove completion of work.

Conclusion

Achieving CMMC compliance should be considered as an ongoing, sustainable program. This requires the ability of multiple stakeholders to provide their requirements into a fabric that integrates into a DevSecOps workflow. The definition of “complete” is baked into Developer-centric Threat Modeling tools and provides auditability and traceability.

Developer-centric Threat Modeling tools are helpful to bring compliance monitoring to DevSecOps automation. Rather than trying to force development and operations into a security sandbox, Developer-centric Threat Modeling tools integrate security from the beginning. It shifts the conversation from a zero-sum decision around speed or security. Rather, it is the inclusion of both in a way that articulates the residual risk and trade-offs to stay within the guardrails of an organizational risk threshold.

The post Using Developer-centric Threat Modeling to Achieve Both Speed and Security for CMMC appeared first on Security Compass.

Managing rapid application delivery with secure development has long been a major challenge for U.S. federal government agencies. Part of the reason was the constant need to introduce new features and functionality while security wasn’t completely integrated. Or, it was handled by security experts who relied on patchwork once development was complete. However, agencies are starting to learn that the consequences of security breaches can be far-reaching.

Thankfully, the federal government has significantly increased cybersecurity spending to address threats.

• The combined spending for cybersecurity was US$14.9 billion in 2018, of which the Department of Defense (DoD) used over US$8 billion.
• The Department of Homeland Security (DHS) was the second-highest user of funds earmarked for cybersecurity at US$1.8 billion.

As the agencies continue to build or acquire new tools and software, it will be imperative to build a stronger infrastructure and focus on secure software development.

What exposes federal government agencies to cybercrimes?

There are many factors that contribute to the risk an agency faces from cybercriminals. Inadequate security practices, unknown assets, weaknesses in code design, and unpatched vulnerabilities can significantly increase the risk.

As per the DHS, around 90 percent of the cyber crimes are a result of vulnerabilities exposed from a defect in the software code or design.

Detecting and fixing these vulnerabilities at a later stage can be costly and expose other connected applications to security risks. That’s why it is important to increase the overall quality of software by making security a priority from the beginning rather than relying on patchwork.

However, infusing security into the software development process can be time-consuming and delay the deadlines. In addition, the Authority to Operate (ATO) process that allows entities to connect systems to the federal networks can further elongate the software development life cycle.

So, how exactly can a government agency keep up with security while managing tight deadlines?

How you can ensure application security

Now that we know what’s leading to the cyberattacks within the federal government agencies’ networks, let’s discuss some of the challenges these agencies face in secure development.

1. Manual processes: To minimize security vulnerabilities, new solutions and software fixes have to undergo rigorous testing against established internal standards to obtain an ATO. Some of these standards, such as NIST 800-53, contain more than 1,000 controls. Using manual processes to verify against such a large number of controls significantly delays the development.
2. Skills shortage: Security experts are scarce which makes it difficult to support the development process throughout. Usually, agencies prefer to utilize these experts for higher-value vulnerabilities and get help from other resources to verify regular security controls. This can make the development process longer since everyone isn’t experienced enough to complete these tasks.
3. Remediation: Reactive actions like penetration tests and software scans not only delay the delivery deadlines but can also be more expensive to manage. That’s why many agencies are shifting left to include security at the beginning of the development process.

Keeping in mind these challenges, it’s vital for federal agencies to think about security in conjunction with development and automate manual processes through automation tools.

How the DoD is scaling DevSecOps for cybersecurity

In 2019, the DoD initiated a massive effort toward software development that would help its agencies avoid traditional disasters. Established as the DoD Enterprise DevSecOps Initiative, this initiative intends to combine development, security, and operations across the DoD.

The idea behind this initiative is to utilize modern tools and best practices to provide secure and timely software for the warfighters. And, their inspiration came from the wins of Kessel Run — a project started by the U.S. Air Force (USAF) to learn agile software development.

In its reference design document, DoD explains how DevSecOps will “improve customer outcomes and mission value by automating, monitoring, and applying security at all phases of the software lifecycle: plan, develop, build, test, release, deliver, deploy, operate, and monitor. Practicing DevSecOps provides demonstrable quality and security improvements over the traditional software lifecycle.”

As a part of this program, the DoD also aims to push for continuous ATO, which will enable its software factories and service providers to push software updates and solutions immediately to the network without having to go through the security validation every time. But it’s also important to make the ATO process fast which can usually take from 6 months to a year for completion.

How to build secure software

Building security from the beginning is one of the core focuses of DevSecOps and the DoD’s new initiative. However, implementing security measures in the development cycle involves a lot of effort in understanding various regulations and controls which might delay the process.

An easier way to manage some of these tasks would be to automate a significant portion of the manual processes. When security standards are translated into actionable tasks, it will enable developers to not lose focus or spend a lot of time grasping security concepts. This will ensure the secure development of applications while maintaining the speed of the process.

If you develop applications or acquire it from service providers, you can’t ignore the benefits that come with building security into development. Rather than taking reactive actions to fix security flaws later, it’s always better to ensure compliance from the moment you start building.

Download our datasheet to learn how DoD’s software factory automates security processes for continuous ATO.

The post U.S. Federal Government: Scaling DevSecOps for Secure Application Development appeared first on Security Compass.