The Imperative of Security by Design

Security by Design transcends the traditional approach of treating security as a peripheral or a final-stage checklist item. It is about proactively identifying and addressing potential security vulnerabilities from the outset of the development process. This preemptive approach not only enhances the security posture of the final product but also optimizes development time and reduces costs associated with post-deployment fixes.

Unveiling the 3E Framework

The 3E Framework, conceptualized by Security Compass, is a comprehensive strategy comprising three fundamental steps: Educate, Embed, and Empower. This framework is designed to foster a culture where security is an integral part of the development process, not an afterthought.

1. Educate: Cultivating a Security-Minded Culture

The first pillar, Educate, underscores the importance of building a deep-seated awareness and understanding of security principles among all stakeholders involved in the development process. It involves extensive training, workshops, and continuous learning initiatives to keep the team updated on the latest security trends, threats, and best practices. Education shifts the perception of security from being a hindrance to an enabler of innovation and reliability in software development.

2. Embed: Integrating Security Expertise into Teams

Embedding security expertise directly within development teams is crucial for translating knowledge into action. The Security Champions program exemplifies this approach by designating and training selected team members to spearhead security practices within their respective teams. These champions serve as the nexus between security and development, ensuring that security considerations are woven into the development lifecycle at every stage.

Empower: Enabling Proactive Security Practices

With a well-educated workforce and embedded security experts, the final step is to empower teams to apply these principles actively. This entails integrating security requirements from the project’s inception, conducting thorough threat modeling, and ensuring continuous security testing throughout the development process. Empowerment leads to the creation of software that is secure by design, meeting both customer expectations and regulatory requirements.

Addressing Implementation Challenges

Implementing the 3E Framework is not without its challenges. Key among these is the friction between security and development teams, often stemming from differing priorities and pressures. Security requirements can also be complex and overwhelming, creating bottlenecks in manual processes that fail to scale with the demands of modern software development. Moreover, verifying security requirements often relies on cumbersome, error-prone manual methods.

To overcome these challenges, fostering a culture of collaboration is essential, leveraging automated tools to streamline security practices and integrating security considerations seamlessly into existing workflows. By doing so, organizations can bridge the gap between security and development, ensuring a harmonious and efficient process that upholds security standards without compromising development speed or innovation.

The Road Ahead

The journey towards mastering Security by Design through the 3E Framework is ongoing. It requires a commitment to continuous improvement, adaptation based on feedback, and celebrating successes along the way. By educating, embedding, and empowering, organizations can build a resilient, secure foundation for their software, ultimately fostering trust and confidence among users and stakeholders.

Security Compass remains dedicated to guiding organizations through this transformative journey, offering expertise, tools, and support to make Security by Design both attainable and effective. Embracing the 3E Framework is not just about enhancing security; it’s about securing a future where technology drives progress, free from the constraints of cyber threats.

Pathway to Secure by Design: How We Can Support Your Journey

To delve deeper into mastering Security by Design with the 3E Framework and overcoming the challenges within your organization, Security Compass is here to assist. Our team of experts can guide you through each step of the process, from education to empowerment, ensuring that security is seamlessly integrated into your development lifecycle. Contact us to learn how we can help your organization become secure by design. Together, we can build a secure future for your software today.

FAQ: Security by Design and the 3E Framework

What is Security by Design?
Security by Design is a proactive approach to software development where potential security vulnerabilities are identified and addressed from the beginning, making security an integral part of the entire development process rather than an afterthought.

Why is Security by Design important?
Security by Design is critical for mitigating risk and ensuring resilience against the increasingly sophisticated and evolving digital threats, optimizing development time, and reducing costs associated with post-deployment fixes.

What is the 3E Framework by Security Compass?
The 3E Framework is a comprehensive strategy designed by Security Compass, comprising three fundamental steps: Educate, Embed, and Empower, aimed at seamlessly integrating security into the software development lifecycle.

The post Mastering the 3E Framework: Elevating Your Security by Design Practices appeared first on Security Compass.

Organizations that produce software – or products that include software – are under increasing pressure to ensure that software is secure. Whether that pressure is from concern about the “software supply chain” or regulatory bodies, organizations that cannot provide evidence of good software security practices face competitive and legal hurdles.

Enterprise software developers have felt this pressure for years. More recently, concern about software-driven products has risen. This is largely due to the ubiquitous nature of the Internet of Things (IoT). According to a report by Zscaler, the global number of IoT devices was 16.7 billion in 2023 and is expected to grow to over 29 billion by 2027. These devices include printers, routers, displays, payment terminals, and web cameras in business settings. In consumer markets, regulators are focused on data collection and usage of personal information collected by televisions, smart watches, mobile applications, and digital home assistants, among other applications and devices.

Security by Design has long been a goal of forward-thinking teams. That phrase is quickly transforming into Security by Decree as regulators worldwide demand more accountability from software providers. Two of those initiatives are The EU Cyber Resilience Act (CRA) and the US Cyber Trust Mark.

This blog will provide readers with:

• Background on government initiatives to educate consumers on important issues.
• An overview of the CRA And US Cyber Trust Mark.
• An understanding of how these initiatives will affect software development processes.
• Steps they can take to prepare for compliance with the programs.

Security by Decree

Software consumers have never had reliable information on security when making purchase decisions. A customer with sufficient buying power may require security audits, but consumers have been forced to rely on the product manufacturer’s goodwill.

Similar issues have been successfully addressed previously. The US Food and Drug Administration (FDA) requires nutritional labeling on food products sold in the US. The U.S. Environmental Protection Agency’s (EPA) EnergyStar labels allow consumers to compare energy efficiency on dozens of categories of devices and appliances. Unlike nutritional labeling, the EnergyStar program is voluntary and relies on consumer pressure to convince manufacturers to participate.

Comparable programs are coming for organizations that produce software to address privacy and security concerns. In 2022, the EU Commission proposed The Cyber Resilience Act that introduced security requirements for organizations producing “products with digital elements.” The following year, the US government announced the US Cyber Trust Mark, a certification and labeling program to inform consumers of cybersecurity processes, controls, and vulnerabilities products.

What is the EU Cyber Resilience Act?

The CRA was proposed in 2022 and is expected to pass in early 2024. Its goals are to ensure that “products with digital elements” (PDE) are delivered to customers with fewer vulnerabilities, require manufacturers to monitor and help customers manage the security of PDE throughout the product’s lifecycle, and inform consumers during the buying process of PDE about the security measures taken by manufacturers. Once the CRA passes, manufacturers will have 36 months to comply.

The CRA has four objectives (emphasis added):

1. Ensure that manufacturers improve the security of products with digital elements from the design and development phase and throughout the whole life cycle.
2. Ensure a coherent cybersecurity framework, facilitating compliance for hardware and software producers.
3. Enhance the transparency of product security properties with digital elements.
4. Enable businesses and consumers to use products with digital elements securely.

Which Products Are Covered by the Cyber Resilience Act?

The CRA details three classes of PDE:

1. 1. Class I
   2. Class II
   3. Unclassified of Default

The Default category is expected to cover 90 percent of all PDE, with Class I and Class II “critical” products comprising the remaining 10 percent.

Critical products include PDE, which is “designed to run with elevated privileges or manage privileges,” perform security functions or “a function critical to trust,” or are intended to be used in a critical environment. The Act also considers the potential results of a security failure and “the extent to which the use of products with digital elements has already caused material or non-material loss or disruption.”

Class I products include identity management solutions, browsers, password managers, anti-malware solutions, network management and configuration software, industrial automation and control systems, microprocessors / microcontrollers, and Industrial IoT devices. Class II PDE includes operating systems, hypervisors, public critical infrastructure, security solutions, smartcards/readers, routers, and modems.

While the reader should check the Act’s details in determining specific coverage, at the time of writing, the CRA did not apply to products covered by other legislation, including medical devices, motor vehicles, and military hardware. Software-as-a-service offerings are also exempt, except for some remote data processing solutions.

Security Requirements of the Cyber Resilience Act

Briefly, the CRA requires organizations to ensure cybersecurity is considered in the PDE’s planning, design, development, production, testing, and maintenance. This includes:

• A cybersecurity risk assessment
• Compliance with essential cybersecurity requirements and vulnerability handling requirements
• Documentation of all cybersecurity risks
• A Software Bill of Materials (SBOM) listing all open-source components
• A conformity assessment
• Continuous monitoring and reporting of new and actively exploited vulnerabilities for the life of the product

Risk Assessment

The CRA recognizes the need for security by design and default. Its “Essential Cybersecurity Requirements” are detailed in Annex I of the Act. It requires organizations to apply controls based on “an assessment of the cybersecurity risks associated with a product with digital elements” and use that “during the planning, design, development, production, delivery, and maintenance phases of the product with digital elements to minimize cybersecurity risks.”

Essential Cybersecurity Requirements

The “essential cybersecurity requirements” list outcomes, not specific controls to apply based on the security assessment. These include a requirement to deliver software with a secure by default configuration, a limited attack surface, minimization of data collected, ensure protection against unauthorized access, and protect the confidentiality and integrity of data.

Vulnerability Management

Item 2 in Annex I covers Vulnerability Management. This requires organizations to “identify and document vulnerabilities and components contained in the product.” It further requires organizations to disclose vulnerabilities once a security update is available publicly and ensure that patches and security updates are distributed “in a timely manner” for the entire expected lifecycle of the PDE.

Assessment Requirements of the Cyber Resilience Act

For Default products, manufacturers can perform self-assessments and provide an EU declaration of conformity that their products satisfy all Essential Cybersecurity and Vulnerability Management requirements.

Conformity assessment procedures for critical Class I and Class II products can require the application of a security standard and/or a third-party assessment “of the adequacy of the technical design and development of the product through examination of the technical documentation and supporting evidence.”

Penalties for Non-compliance with the Cyber Resilience Act

The CRA includes penalties for organizations that fail to comply with the essential security requirements in Annex I. These include fines of up to €15 million or up to 2.5 percent of the organization’s global annual turnover, whichever is higher.

What is the US Cyber Trust Mark?

In 2021, Executive Order (EO) 14028 directed the US National Institute of Standards and Technology (NIST) to a consumer labeling program “to educate the public on the security capabilities of Internet-of-Things (IoT) devices and software development practices.” This resulted in the creation of the US Cyber Trust Mark.

The US Cyber Trust Mark will be a shield logo and QR code that manufacturers can apply to products meeting established cybersecurity criteria. It is designed to provide easy guidance to help select less vulnerable products to cyber-attacks. For organizations manufacturing such products, the Cyber Trust Mark will provide competitive differentiation as a brand that values its customers’ security.

What Are the Security Requirements for the US Cyber Trust Mark?

In response to EO 14028, in February 2022, NIST published “Recommended Criteria for Cybersecurity Labeling for Consumer Internet of Things (IoT) Products.” The criteria build on the NIST IR 8259 series that provides IoT manufacturers with foundational activities for building and supporting more secure products.

THE NIST IR 9259 series defines both technical and non-technical IoT product capabilities and developer activities. NIST IR 8259A: Core Device Cybersecurity Capability Baseline provides “a set of device capabilities generally needed to support common cybersecurity controls that protect an organization’s devices as well as device data, systems, and ecosystems.” It delivers guidance on building cybersecurity features into IoT devices from the initial stages of development and throughout a product’s lifecycle.

NIST IR 8259B: IoT Non-Technical Supporting Capability Core Baseline provides guidance on activities that organizations should undertake to support customers’ security efforts. This includes documentation, support, and education.

Will Compliance with the US Cyber Trust Mark Standards be Mandatory?

No. The Cyber Trust Mark is a voluntary labeling program. The White House press release highlighted consumer-grade routers in addition to “smart refrigerators, smart microwaves, smart televisions, smart climate control systems, smart fitness trackers, and more.”

When Will the US Cyber Trust Mark Start?

The program currently exists as a Notice of Proposed Rulemaking (NPRM) at the Federal Communications Commission. Final rules will be published after input from key stakeholders. It is expected to be operational in late 2024.

How To Prepare

We have written about the importance of a Security by Design approach to software development. We are not alone. The US Cybersecurity and Infrastructure Security Agency (CISA) partnered with more than a dozen government agencies worldwide to endorse this approach.

What is Security by Design?

Security by Design is the philosophy of ensuring that systems are built securely from the very beginning of the development process, rather than solely relying on testing to identify vulnerabilities. Critically, security by design activities in the software development lifecycle’s planning, analysis, and design phases, before coding begins. This differentiates Security by Design from traditional application security activities that rely solely on testing tools to apply security later in the development lifecycle. These pre-coding activities include:

• Threat modeling to identify inherent threats to applications based on the application’s programming language, frameworks, and deployment environment.
• Developing and maintaining approved security countermeasures and controls to mitigate threats to an application and putting in place controls to ensure these countermeasures are properly implemented.
• Identifying non-functional security requirements such as those called out in the EU Cyber Resilience Act, such as configuring software to have secure settings by default and checking components used by development for known vulnerabilities.
• Mapping security controls to regulatory standards applicable to any application.
• Training developers, QA, and other members of each project in secure development.

Practicing security by design means security is a product quality and it becomes easier to meet the requirements set out by the Cyber Resilience Act and to align with the US Cyber Trust mark.

How Security Compass Can Help

Security Compass is The Security by Design Company. We have worked since 2004 to help teams build more secure software. Our solutions enable organizations to shift left and build secure applications by design, integrated directly with existing DevSecOps tools and workflows.

SD Elements

SD Elements, our developer-centric threat modeling platform, helps organizations accelerate software time to market and reduce cyber risks by automating threat modeling, secure development, and compliance. Threat modeling with SD Elements provides a proven 80 percent reduction in threat modeling time and a 92 percent reduction in vulnerabilities.

Content Library of Secure Development Practices

SD Element’s content library is curated by a team of security professionals tracking dozens of regulatory standards and frameworks. This includes an expansive collection of threats, countermeasures, and security and compliance best practices designed specifically to address the needs of developers.

Application Security Training

Our ISC2 accredited Software Security Practitioner Suites provides role-based courses enabling developers to learn foundational elements of software security and language-specific secure coding skills ranging from full-stack application development to mobile to operational security and general awareness. Our training includes Secure Product Development Practices referenced in CISA’s Secure by Design document.

Just-in-Time Training Modules

SD Elements delivers contextual learning directly to developers’ workstations to maximize retention. Brief Just in Time Training (JITT) modules are mapped to security requirements and countermeasures and delivered to developers through their existing workflow.

Enhance Your Cybersecurity Strategy: Partner with Security Compass for Compliance and Innovation

The importance of integrating robust security measures is clear in navigating the complexities of the EU Cyber Resilience Act and the US Cyber Trust Mark. As the landscape of cybersecurity evolves, staying ahead of regulatory requirements is not just necessary but a strategic advantage.

Ready to boost your organization’s cybersecurity and confidently tackle these regulations?
Security Compass is here to guide you. Our expertise and innovative solutions like SD Elements help integrate security into the software development lifecycle. We focus on embedding security deeply into your software, ensuring resilience and protecting your reputation.

• Embark on a Product Tour: Uncover how SD Elements can tailor solutions to your distinct challenges.
• Book a Demo: See how SD Elements can transform your software security approach.

Partner with Security Compass and turn regulatory challenges into opportunities for growth. Contact us and book your demo to start your journey towards a secure digital future.

The post Security by Design and by Decree appeared first on Security Compass.

The latest 2023.4 release from Security Compass streamlines the process of Security by Design, offering application security and software development teams a more straightforward and efficient approach. Key enhancements in SD Elements 2023.4 encompass:

• Enhanced Trend Reporting
• Integration with Checkmarx One SAST
• The ability to use Custom Icons
• Refreshed and Updated Security Content

Trend Reporting

SD Elements now includes Trend Reporting within its Advanced Reporting functionality. This new feature provides valuable insights into the evolving security posture of your organization, showcasing how SD Elements contributes to continuous security improvements over time.

In the dashboard below, you can see the number of compliant and non-compliant projects this bank has and how it is trending towards GDPR compliance over time.

Integration with Checkmarx One SAST

SD Elements now integrates with Checkmarx One SAST. This new integration allows you to import SAST scan results from Checkmarx One into SD Elements. The following guide will show you how to set up the integration and the results it will yield within SD Elements.

Custom Icons

SD Elements users with customizable content permissions are able to select icons (from a list of available icons) for custom components or for alternate icons for any components that you have already created. Custom icons bring secure by design connected components in line with the visual language specific to your organization.

Below is a sample of the custom icons that will be available when you generate a threat model diagram.

CWE Top 25 2023 Compliance Report and Content

Common Weakness Enumeration recently released their top 25 Most Dangerous Software Weaknesses list (CWE Top 25). This list highlights the currently most common and impactful software weaknesses. With the 2023.4 release, SD Elements has added a compliance report for CWE Top 25 2023 with relevant mappings to the countermeasures. The CWE Top 25 2023 report is now available under Project Reports → Compliance Reports.

¹ CWE Top 25 Most Dangerous Software Weaknesses

Learn More

Security Compass enables you to deliver secure & compliant software by design.

By taking a proactive approach to threat modeling and secure development, SD Elements improves software security at scale, reduces operational costs, and helps organizations achieve compliance. Application Security Training from Security Compass takes developers from good to great with accredited role-based security eLearning.

Leading organizations across industries are using Security Compass’ developer-centric technologies and expertise to adopt a “security by design” approach and scale their AppSec efforts beyond what was possible with traditional “find and fix” methodologies.

For existing SD Elements customers, please contact your Customer Success Manager for further insights and support.

New to SD Elements? Request a demo to explore how our solutions can transform your software security landscape.

The post SD Elements 2023.4 Release Update appeared first on Security Compass.

Secure Software Development Life Cycle (Secure SDLC)

Secure Development is centered around the Secure Software Development Life Cycle (Secure SDLC), which is a sequence of phases that software goes through during development. The five main phases are Planning, Design, Implementation, Verification and Maintenance. By incorporating security practices into every phase of the Secure SDLC, organizations can significantly reduce the security risks associated with the software they launch into the market. Instead of a bolt-on, where security issues are discovered in production during maintenance or in staging during verification, it’s imperative that organizations shift left by incorporating security-by-design in earlier phases. By avoiding reengineering and rework, security issues are significantly cheaper to mitigate earlier in the Secure SDLC. SD Elements will help you introduce security by design to each phase of the Secure SDLC.

Planning Phase: Setting Security Goals & Objectives

Planning commences the Secure SDLC, where key stakeholders define the security requirements using relevant security policies. Security goals and objectives must be clearly captured through security requirements, which must also align with the organization’s overall security goals and objectives. Stakeholders must clearly articulate, ‘What are we working on?’, during the planning phase. SD Elements empowers stakeholders to answer survey questions to capture and communicate decisions from the Planning phase. SD Elements also identifies relevant security activities and security requirements that should be completed during the Planning phase. Using SD Elements during the Planning phase allows organizations to plan the secure-by-design products that customers can unbox in the near future.

Design Phase: Identifying Security Controls & Architecting the Product

During the Design phase, security controls and architectural components are identified to ensure security requirements identified in the Planning phase will be met during the upcoming Implementation phase. Threats, weaknesses, and risks lurk behind every decision made during the Design phase, forcing stakeholders to consider ‘What can go wrong?’ with their design. Enumerating threats is not enough; stakeholders must also architect & design mitigations, referred to as countermeasures. This can be done manually, one threat at a time, or it could be automated using SD Elements. SD Elements uses the survey completed during the Planning phase to identify threats and weaknesses and allows stakeholders to visualize their design using diagrams. By incorporating these security controls and architecture decisions seamlessly into the product, the product will be secure by design from the onset. Customers prefer to unbox a secure-by-design product over a product that bolts on security prior to launch.

Implementation Phase: Writing Secure Code, Static Analysis & SCA

In the Implementation phase, software developers write secure code using the security requirements in the Planning phase and the security controls & architectural components added in the Design phase. Within a Secure SDLC, developers consider ‘What are we going to do about it?’ by implementing relevant countermeasures. Developers also use best practices to avoid introducing common security issues. Static Analysis (SAST) and Software Composition Analysis (SCA) help developers identify and mitigate security issues during the Implementation phase. These are often three separate activities in the Implementation phase. A Secure SDLC using SD Elements can use SAST and SCA information to mark countermeasures as complete, allowing developers to focus on countermeasures that need their attention. SD Elements also provides helpful code snippets, configuration guidance, and Just-in-Time Training to give developers clear, concise, and actionable guidance during the Implementation phase. Lastly, using SD Elements allows relevant countermeasures to be synchronized with JIRA, GitHub, GitLab, Azure DevOps, and other issue trackers, allowing developers to complete the Implementation phase using a familiar tool. Securely completing the Implementation phase is crucial to shipping a secure-by-design product.

Verification Phase: Performing Code Reviews & Dynamic Analysis

Very close to launch, the Verification phase validates that security requirements are implemented correctly without inadvertently introducing additional security issues. Developers work closely with security teams to verify, ‘Did we do a good enough job’ within the Verification phase of the Secure SDLC. Manual code reviews, automated test cases, and Dynamic Analysis (DAST) help teams verify security controls were introduced properly. SD Elements provides testing countermeasures to help security teams manually verify the implementation of countermeasures. DAST scan information can be integrated with SD Elements to resurface any countermeasures that require additional attention from developers. To ship a secure-by-design product, secure-by-default configurations must be verified through the Verification phase.

Maintenance Phase: Security Monitoring & Patching

Moving onto our final phase, the Maintenance phase, where teams regularly review and update security controls to mitigate new and emerging security issues. Security patches may be required to mitigate certain security issues. In the Secure SDLC, security is continuously monitored, allowing teams to promptly respond when necessary. Subsequent releases or feature enhancements will prompt the team to step through each step of the Secure SDLC again. Software exiting the Maintenance phase will require proper decommissioning, including the secure disposal or archival of data. Using SD Elements, new and emerging security issues identified during the Maintenance phase can be shared with other development teams so they can introduce relevant security controls in earlier phases of their Secure SDLCs.

With me so far?

By introducing security into each phase of the SDLC to create a Secure SDLC, instead of leaving security to be an afterthought, organizations can minimize the security risks associated with their software. A Secure SDLC helps create a culture of security within development teams. SD Elements helps with each phase of the Secure SDLC, allowing organizations to introduce Security by Design at scale across their entire portfolio.

Discover the impact of SD Elements on Secure Development. Ready to explore how SD Elements can transform your Secure SDLC? Reach out to us now. Or, if you’re eager to experience Security by Design with SD Elements, view our instant product tour.

The post What is Secure Development? appeared first on Security Compass.

In May 2023, attackers exploited a SQL injection vulnerability in MOVEIt – a widely used file transfer service. Organizations across the public and private sectors were impacted, with highly sensitive PII, including health information about newborn babies. The ongoing proliferation of software vulnerabilities like this has led to more people calling for a security by design approach.

At Security Compass, we strongly believe in security by design. Empowering teams to build secure software by design is our company’s mission. The costly legacy “find and fix” method for securing software is insufficient to make a material improvement in cybersecurity. Security by Design is not just about preventing threats; it’s about instilling confidence in every stakeholder, from the boardroom to the end user. We support software manufacturers to integrate security across the development process, right from the requirements stage, which in turn enables them to take ownership of security outcomes for their customers.

Benefits of Security by Design

Integrating security by design with the appropriate people, process, and technology is not only good for risk management – it bolsters the bottom line. With over a decade of experience in implementing our solutions, we’ve helped companies around the world achieve secure-by-design outcomes:

• A leading building supply company reduced cost and time to market for security requirements by 30%, and increased collaboration between security and development
• A large bank reduced risk, improved visibility and cut the time to assess risk by over 90%
• A Smart Home Products brand successfully embedded a Security Champion in every development team
• A global consultancy lowered their threat modeling process time from over 230 hours to 60 hours
• Several federal government organizations reduced their time for compliance activities from months to days

These outcomes ultimately yield faster time to market, more revenue and lower risk.

Navigating Regulatory Changes in Software Security

Governments and industry standards boards are taking notice. In 2023, the governments of the United States , Canada, Australia, United Kingdom, Germany, Netherlands, New Zealand, Czech Republic, Israel, Singapore, Korea, Norway, and Japan published guidance on security by design. An executive order in the United States mandates secure software practices for vendors who supply software to the federal government. OWASP introduced “insecure design” as a top 10 risk in 2021. States and federal governments are starting to write laws or bolster existing ones for Internet of Things vendors to incorporate security by design. Proposed legislation for hospitals in New York requires security by design practices. Moreover, some countries are considering shifting liability for breaches to software manufacturers with safe harbour provisions for those that incorporate security in the development process. Even if you ignore the business benefits, not incorporating auditable security by design practices is likely to leave any software or hardware manufacturer at risk for regulatory noncompliance and maybe even liability for breaches at customer sites.

Overcoming Common Challenges in Security by Design

While the business benefits and regulatory requirements are compelling, security by design is not a “plug and play” solution. Most people think of security as a quality that you test for: security vulnerabilities are scanned in code or discovered in a penetration test. The idea that you can prevent ever having a vulnerability takes a mindset shift. Over the years, we’ve seen a number of anti-patterns emerge from organizations who pursue security by design without putting in place the appropriate steps to adjust for the mindset shift.

• Inattention to change management: Because the business benefits of security by design seem obvious, many organizations rush into embracing new tools and techniques without considering the impact of changes to software, product and business teams. Fortunately, many organizations have already learned this lesson from other initiatives and have formed change management best practices. Classic techniques like stakeholder analysis, incentive alignment, early involvement of potential detractors, and communicating/learning from the results of pilots can prove effective.
• Moving too fast: One of the most challenging realities of embracing security by design is that it creates new work for teams. For example, development teams who embrace threat modeling and/or defining security requirements have more work to do up-front in the development process, which in turn takes away time from writing code in fixed-length development sprints. This is often at odds with product management/business goals of shipping more capabilities to users within the sprint. If a security team tries to inject 100 new security requirements for a development team to analyze and potentially action at the beginning of a two-week sprint, the effort will almost certainly fail because even reviewing the requirements will leave little time to complete features. Successful implementations often start with a crawl-walk-run approach: begin with work that requires a small investment in time, such as implementing a single, small security requirement. While this approach doesn’t materially improve risk posture right away, it helps build acceptance to the concept of security by design. As development teams become accustomed to taking on security work in planning, they can slowly increase the time investment and reduce more risk. Ideally, teams plan for proactive security work alongside other feature work on a regular basis.
• Begging the question: When organizations haven’t holistically embraced security by design, champions of the initiative often want to prove its benefits with a pilot or limited rollout. Without a mandate, they ask development teams to participate voluntarily. However, when faced with more immediate priorities such as feature work, development teams often drop voluntary work and do not perform tasks such as threat modeling or defining security requirements. The pilot fails to provide proof, and detractors point to the lack of traction as evidence that security by design doesn’t work. In our experience, voluntary efforts from individual developers to implement security by design rarely work. Instead, business and product stakeholders need to embrace the concept of security by design and allocate sufficient time to truly perform security by design activities.

The 3E Framework: A Rollout Strategy for Security by Design

If you are leading security by design at your organization, there’s a good chance you have faced or will face some of these anti-patterns. It can be frustrating to be up against a mountain of change resistance for an initiative that has such obvious business benefits. In periods of constrained budgets, starting an initiative that will require people, process and technology support is especially difficult. Fortunately, we’ve seen enough organizations succeed in rolling out security by design that we’ve identified a common pattern we call the 3E framework: Educate, Embed, Empower.

1. Educate: When it comes to security, ignorance is bliss. Development teams have a false sense of security because of clean penetration tests, or a broad cybersecurity compliance as SOC2 compliance. Training development teams on basic security awareness allows them to better understand the true breadth and complexity of creating secure systems. Successful security by design rollouts often start with this awareness as a precursor to processes that impact development processes, such as threat modeling. In parallel, champions begin the process of soliciting buy-in to security by design from executives by focusing on the business benefits of lower costs, reduced risk, and faster time to market.
2. Embed: For security by design processes and technology to work, they require people to champion them. Security champions are developers who have a strong interest and above-average knowledge of security. They are embedded within development teams and serve as the ideal owners for activities such as threat modeling and defining security requirements. Absent these champions, security by design initiatives often falter with lack of ownership.
3. Empower: Once development teams have been educated, executives have bought into the initiative and security champions are embedded in development teams, the groundwork has been laid for empowering development teams to rollout processes like threat modeling and security requirements. This is when organizations really begin to experience the business benefits and gain an advantage over competitors who are still stuck in costly “scan and fix” approaches to secure software.

Alongside these steps, successful rollouts often take into consideration:

• Metrics: Tracking KPIs and seeing progress over time helps to illustrate the business benefits. This often involves augmenting reactive metrics like defect density with proactive ones, like compliance against internal policy for security requirements.
• Budget: Any successful security by design program encompasses people, process and technology. Organizations need sufficient budget in all three in order to reap the significant business benefits.

Real-World Success Stories: Implementing Security by Design

One large manufacturer we worked with followed this strategy. They started with a large-scale roll-out of security awareness training for multiple roles across the development teams. They leveraged industry accreditation with ISC2 to embed security champions inside the development teams. They subsequently rolled out security requirements and threat modeling across teams and saw significant reductions in risk; penetration tests started to turn up a few findings in product teams that incorporated all of these steps.

The amount of change required isn’t always appealing to security and development teams who are strapped for time. Acknowledge this with your wider team and encourage empathy across functions as you balance speed to market with sharing the responsibility of designing and building secure applications. The alternative to security by design or the status quo, where customers deploy products with known, preventable vulnerabilities and expose themselves to being exploited in the wild and incurring even more damaging costs like loss of business and loss of customer trust.

Security by Design is not a luxury—it’s a necessity. As the CEO of Security Compass, I firmly believe that when we prioritize security from the start, we’re not just building software; we’re enabling a world where we can trust technology. Let’s shift the paradigm from security as an add-on to security as a default, ensuring that every customer inherently receives the secure products they deserve.

How Security Compass Can Guide You in Security by Design

If you build products with software, you can get started with security by design today. Start by assessing yourself on the 3E framework: are stakeholders educated? Have executives bought into security by design? Our role-based training can help you get started. If you’ve moved past education, have you embedded security expertise by forming champions? Our partnership with ISC2 to offer the Software Security Practitioner accreditation is a great way of validating security expertise for champions. If you are ready to empower development teams, SD Elements helps integrate threat modeling, security requirements, and compliance into the development process.

Contact Security Compass now to learn how SD Elements can help your organization achieve security by design, minimizing risks while maximizing efficiency and compliance.

The post The Case for Security by Design appeared first on Security Compass.

• New AI governance, large language models (LLM), Consumer IoT, Rust, and ISO 27001:2022 security content
• Scheduled user deactivation and reactivation
• SD Elements library and content improvements
• Enhanced Auditing

Developer-centric Security Content

Create an AI Governance framework based on NIST AI RMF

SD Elements has added security content to help your organization create an AI governance framework. This framework is based on the NIST AI Risk Management Framework, which provides guidance on how to govern, map, measure, and manage the usage of AI products.

The survey has a new section: “Artificial Intelligence/Machine Learning.”

When you select “AI governance tasks are in scope” and complete the survey, you will then be provided with weaknesses, countermeasures, and a report based on the NIST AI RMF.

Embed security for the OWASP Top 10 LLM Applications with ease

SD Elements now supports developer-centric recommendations for the OWASP Top Ten Large Language Models Applications.

When you select “Uses Large Language Models (LLM)” and complete the survey, you will then be provided with weaknesses and countermeasures based on the OWASP Top 10 for Large Language Model Applications.

Prevent large-scale, prevalent attacks against your IoT devices

SD Elements will be adding new countermeasures and a report for IoT: ETSI EN 303 645 to ensure your organization is aligned with this globally recognized standard for manufacturing consumer IoT devices.

When selecting a Compliance Report, you now have the option to select EN 303 645, which will generate a list of potential countermeasures and their completion status.

Rust

SD Elements now supports security content for Rust.

ISO 27001: 2013 → ISO 27001: 2022

When selecting a Compliance Report, you now have the option to select ISO 27001:2022, which will generate a list of potential countermeasures and their completion status.

Automate the user lifecycle management process

SD Elements now supports the scheduled auto-deactivation of user identities directly from the SD Elements user interface as well as reactivation of deactivated user identities that are using SSO (SAML, LDAP). To automatically deactivate and reactivate user identities:

Set the parameter and the number of days in which specific users’, or groups’, identity should be deactivated. The ability to either select specific users and/or groups will give you more granular control over your user lifecycle management workflow.

Automatically reactivating users via SSO Login can now be completed in two clicks.

Migrate Activated and Deactivated Library Content

You can now export deactivated content, set content to deactivate or activate upon import, and delete custom content upon import within SD Elements.

Enhanced Auditing

All content updates are now made available in Global Activity Logs, Project Activity Logs, and Countermeasure Activity Logs.

Learn More

Security Compass, the Security by Design company, helps organizations who develop software save time and money and reduce cyber risks through education and by taking an automated, developer-centric approach to software threat modeling, secure development, and compliance. This approach enables software developers and security teams to:

• Understand best practices for embedding product security
• Continuously model threats at scale
• Proactively write code that significantly reduces risks and remediation costs
• Demonstrate compliance with secure software development standards more easily
• Accelerate software time to market

If you are a current SD Elements customer, please reach out to your Customer Success Manager to learn more.

If you are new to SD Elements, request a demo to learn more.

The post SD Elements 2023.3 Release Update appeared first on Security Compass.

Application Security Testing (AST) tools are part of a smart software security initiative (SSI). This category of tools includes Static Application Security Testing (SAST), Software Composition Analysis (SCA), Interactive Application Security Testing (IAST), and Dynamic Application Security Testing (DAST).

AST tools are designed to identify design flaws and coding errors that can result in security vulnerabilities prior to software being released.

Catching errors before deploying into a production environment can help reduce cost and improve quality. The earlier in the development process these vulnerabilities are found, the less impact on development time and cost.

This blog will focus on SAST tool effectiveness and discuss:

• How SAST scanners work
• True positives, false positives, and false negatives
• The gap in effectiveness as perceived by software engineering
• How a Security by Design approach can improve software development costs and outcomes

How Static Analysis Works

Static tools analyze source code or compiled applications to detect security vulnerabilities in the code written by internal developers.

They work by first building an Abstract Syntax Tree; a model of the application’s control flow, data flow, and variables. Once completed, the model can be queried to detect common security issues. Techniques include:

• Data flow analysis: Data flow analysis tracks how values are assigned, used, and propagated across different variables, functions, and modules. This helps identify potential security vulnerabilities related to input validation, data sanitization, and secure data handling.
• Control flow analysis: In control flow analysis, SAST tools examine the program’s structure and identify control flow constructs such as loops, conditionals, function calls, and exception handling. By analyzing these constructs, SAST solutions gain insights into how the program’s execution proceeds from one statement to another and how different program components interact.
• Symbolic analysis: This technique analyzes code by representing program variables and expressions symbolically rather than using concrete values. It focuses on exploring different execution paths and evaluating potential vulnerabilities without executing the code.
• Taint analysis: “Taint” is the concept of marking or flagging data that originates from potentially untrusted or unsafe sources such as users. From a security perspective, tainted data should be validated or “sanitized” before reaching vulnerable functions. By following the propagation of tainted data and applying taint analysis rules, a SAST tool can identify potential security vulnerabilities in the code. For example, it can flag instances where tainted data is used in database queries without proper sanitization or where tainted data is directly embedded in dynamically generated HTML without proper encoding.

Based on a series of logical security tests, a scanner will produce a result to indicate whether the test fails (i.e., whether a vulnerability exists in the code).

This may or may not correspond to the truth. The goal of a scanner is to minimize errors of omission (not correctly identifying vulnerabilities) and incorrect alerts. In short, we have four possibilities:

• True Positive: The number of true vulnerabilities correctly identified by the SAST tool. These are instances where the tool correctly detects a security issue that indeed exists in the code.
• False Positive: The number of instances where the SAST tool incorrectly identifies a non-existent vulnerability or reports a false positive. These are cases where the tool flags code segments as vulnerabilities, but upon manual inspection, they are determined to be safe.
• True Negative: The number of non-vulnerable code segments correctly identified as safe by the SAST tool. These are instances where the tool accurately recognizes that the code is secure.
• False Negative: The number of vulnerabilities missed by the SAST tool, where it fails to detect actual security issues. These are cases where the tool overlooks security vulnerabilities that exist in the code.

Why SAST Will Always Generate False Positives and False Negatives

No tool is perfect, including SAST tools. Static analysis of software is difficult. Vendors have spent hundreds of millions of dollars in research to improve results with varying degrees of success. The National Institute of Standards and Technology (NIST) has conducted several studies on the effectiveness of SAST tools. NIST found wide variations in the false positive rates produced by different SAST tools. The fifth study in 2018 found false positive rates between 3 percent and 48 percent for ten SAST tools analyzed.

Note that a three percent false positive rate does not necessarily mean that 97 percent of the results were accurate and useful. That particular tool had a true positive rate for security issues of zero percent! Most of its findings (73 percent) were classified as “insignificant”: findings related to style rules or low priority issues that pose acceptable risk. The remaining findings were a true positive rate for quality issues of 23 percent.

False positives slow down development and can increase friction between security and engineering. Research by GrammaTech found that triaging a single finding — irrespective of category — requires 10 minutes on average. In other words, triaging only 240 issues requires 40 hours — a workweek — of effort.

While everyone wants to address True Positives, pushback is inevitable when these make up barely half of the issues generated by a scanner.

There are several reasons SAST tools will inevitably produce false positives and not detect true positives.  These include technical limitations, design decisions by vendors,  and compiler technology.

The Halting Problem

The halting problem is a fundamental concept in computer science and mathematics, first introduced by Alan Turing in 1936. It refers to the question of whether a general algorithm can determine, for any given program and input, whether the program will eventually halt (terminate) or continue running indefinitely (loop forever).

In a perfect world, we are able to execute a program from the start state through the termination (or Halt) stage. As software becomes more complex, this becomes non-deterministic. The assumption made by scanners, however, is that we can execute code from start to finish predictably.

Some vulnerabilities cannot be identified through automation

Common Weakness Enumeration (CWE) is a community-developed list of software and hardware weakness types that can be present in software applications. SAST tools can help identify many common weaknesses and vulnerabilities in code but are not able to identify all CWE.

SAST tools are designed to detect specific patterns or signatures in the code that are associated with known vulnerabilities. These tools can be effective at finding issues like SQL injection, cross-site scripting, buffer overflows, or insecure cryptographic implementations. However, they may not be able to detect more complex or subtle vulnerabilities that require a deeper understanding of the code’s behavior, logic, or business rules.

These types of issues often require a combination of manual code review, security architecture analysis, or other techniques that involve human expertise and a deeper understanding of the application’s context.

SEI CERT Oracle Coding Standard for Java provides several examples where “Automated detection is infeasible in the general case.” :

Scanners are typically optimized for a certain class of vulnerabilities.

Not all scanners are created to catch the same category of vulnerabilities. Each vendor makes different engineering decisions when attempting to optimize their tool. Some are focused on the syntax level while others perform a detailed model analysis to try and derive data and flow information. Because of this, some organizations have opted to use multiple scanners to try and fill the gaps. Even when using multiple tools, however, issues can be missed.

One study demonstrates the results of detecting a buffer overflow error in C++ code. As one can see, the tools missed between 56.5 percent and 68.3 percent of the test cases. Even when using all three scanners together less more than half of the buffer overflow instances were missed.

Scanners do not understand intent

Because scanners rely on a predefined set of rules, they cannot interpret a developer’s intent. Understanding the intent of the code often requires a more dynamic analysis or a combination of different techniques, such as manual code review, security architecture analysis, or penetration testing. These approaches involve human expertise and can provide a deeper understanding of the application’s behavior, potential attack vectors, and overall security posture.

Compiler optimization can inject security vulnerabilities

Most SAST tools analyze source code during the development phase. Compiling code can introduce security vulnerabilities even though a scanner did not find an issue. One research team identified three classes of security weaknesses introduced by compiler optimizations:

• information leaks through persistent state
• elimination of security-relevant code due to undefined behavior
• introduction of side channels

They produced the following example where a compiler can introduce security vulnerabilities.
crypt(){
key = 0xC0DE; // read key
… // work with the secure key key = 0x0; // scrub
memory
}

Here the developer practiced good security by scrubbing the key from memory.  However, to improve software performance, the compiler may view the last instruction as unnecessary and ignore it, leaving the key available in memory.

Compensating for SAST Limitations

While SAST tools clearly have a useful role in identifying application security errors, they cannot be the only activity used to identify security vulnerabilities. As shown, there are many situations where scanners will miss known vulnerabilities and target non-existing ones. The key to filling this gap is recognizing the limitations of security testing and working proactively to minimize design flaws and coding errors.

Security by Design

While security testing is a best practice, it should not be an organization’s only security activity. Using scanners as a primary way of building security into applications is inefficient, as they simply scanners find vulnerabilities after they have been produced. A Security by Design philosophy ensures that systems are built with security in mind from the very beginning of the development process, well before testing is possible.

Security by Design Starts with Secure Development Requirements

Secure development requirements are measures that must be implemented to ensure the confidentiality, integrity, and availability of software systems. Creating security requirements in the design phase of the SDLC, well before coding begins. This helps development, security, and operations build secure code before testing begins.

Secure development requirements identify threats to an application. While there are some best practices like input validation that are common to all development projects, others will be dependent on the technology stack, and applicable regulatory, customer, or internal requirements for each project. These can include threats inherent to the development language, software frameworks, and common attack patterns as well as threats for specific deployment environments such as AWS, Microsoft Azure, and Google Cloud Platform.

Manually creating secure development requirements can challenge even the most well-resourced teams. Manual processes take time. Few organizations can wait days or weeks to generate secure coding requirements.

SD Elements Automates Secure Development Requirements

SD Elements is a developer-centric platform for automating secure development requirements and building secure and compliant software by design. Based on a brief survey, SD Elements identifies applicable regulatory standards and threats to an applications technology stack and deployment environment. It then translates those threats into actionable security controls and assigns them to development, QA, security, and operations through the teams’ existing systems such as Jira.

By automating secure development requirements, organizations are able to achieve:

• Scalability: Manually creating secure coding requirements for each new project demands time and effort from scarce security and development resources. SD Elements generates controls and countermeasures in minutes, not weeks.
• Consistency: The output from manual threat models reflects the knowledge and biases of those participating in the exercise. As team members change identified threats and controls will also change. SD Elements provides consistent, pre-approved controls and countermeasures.
• Traceability: While many engineering teams will have secure development policies, few have ways to validate that each policy is followed. This lack of traceability makes it impossible to understand the security posture of an application or portfolio. SD Elements provides a centralized platform and integration with testing tools to allow near real-time information on the status of controls.
• Regulatory compliance: Today’s regulatory environment changes rapidly. Keeping track of overlapping requirements is difficult and the consequences of non-compliance can be damaging to an organization. Security Compass’s content library is curated by a team of security professionals tracking dozens of regulatory standards and frameworks to keep SD Elements up to date.
• Continuous developer training: SD Elements full suite of on-demand, secure development training keeps security top of mind throughout the development lifecycle. Courses are role-based and cover topics from security awareness courses that educate employees on good cyber hygiene practices to in-depth reviews of threats and vulnerabilities specific to an experienced developer’s technology stack.

Compliant and Secure Software by Design

Security testing tools like static analysis are an important part of any secure software program. To build more secure software faster, however, a more proactive strategy is needed.

SD Elements enables teams to identify risks to software and prescribe security controls as part of the normal development process. The result is more secure software with fewer delays.

To learn more about the problem of false negatives, you won’t want to miss our deep dive into code scanners.

The post Safeguarding Software Quality: Tackling False Negatives with Security by Design appeared first on Security Compass.

Expanding Depth and Breadth of Security and Training Content and Integrations

To provide a good customer experience, all organizations must strive for a Security by Default end state  “products that are secure to use out of the box.”  Releasing products with vulnerabilities puts customer data at risk. Threat actors having access to personally identifiable information will do irreparable harm to customers.  The burden of putting strong security measures in place (i.e. strong passwords or multi-factor authentication)  should not fall upon your customers.

To achieve the Security by Default end state, organizations must adopt a Security by Design approach. Security by Design is the philosophy of ensuring that systems are built securely from the very beginning of the development process. However, implementing Security by Design is not a one-size fits all solution, as organizations, departments, and teams all have different needs. The right solution to adopt or optimize your Security by Design approach must address your organization’s current needs, integrate with your existing tech stack, and reduce the number of security requirements your developers have to address.

Security Compass, the Security by Design company, has developed two developer-centric solutions, SD Elements and Application Security Training (formerly eLearning), which allows organizations to embed product security early on in the development process.  Both solutions enable organizations, departments, and teams to release secure code faster through training, automatically identifying and prioritizing software threats, recommending countermeasures, and reducing the risk of insecure design.

With the release of SD  Elements 2023.2, Security Compass is making Security by Design easier than ever for software development teams. New features now available in SD Elements 2023.2 include:

• Improvements to the SD Elements survey
• New and updated security content
• Enhanced user lifecycle management experience
• New and updated Just-In-Time-Training (JITT) modules and Application Security Training courses

Survey Enhancements

The SD Elements survey is the most essential aspect of a threat model. To create a complete threat model, the survey can require collaboration amongst multiple users across teams, depending on the complexity of the system. Prior to the 2023.2 release, it was challenging for users to identify what changes had been made. For the stakeholder who is responsible for submitting the survey, there was no ability to review the changes.

With the 2023.2 release, any changes made in the survey will now be highlighted. When the owner is ready to submit the survey, they will be directed to a confirmation page where they will have the opportunity to review all the changes. This update will reduce the time spent reviewing survey answers.

User Lifecycle Management Enhancements

It is the responsibility of the SD Elements administrator to oversee the user lifecycle management experience. In previous releases, we addressed onboarding by adding the ability ​​to import groups and roles from identity providers into SD Elements. However, this feature only worked via API and not directly within the SD Elements user interface (UI). Reactivating suspended users was also a challenge prior to this release. If an identity provider does not allow for scheduled reactivation, then this must happen manually within SD Elements, which is a labor-intensive process.

With the SD Elements 2023.2 release, SD Elements is enhancing the onboarding experience and automating the reactivation of inactive users.The new onboarding experience allows organizations to leverage SD Element’s current Single Sign-On (SSO) authentication, extending SD Elements SAML configurations via UI to provide the ability to map Identity Provider (IdP) groups to SD Elements group(s) and map IdP roles to SD Elements roles.  With scheduled reactivation, SD Elements administrators can set a date to activate a suspended user’s identity. Once the date arrives, the user will automatically be granted access to SD Elements.

New Security Content

SD Elements 2023.2 now provides the following security content library updates:

• ISO 21434 (Automotive Industry): New developer-centric recommendations and out of the box countermeasures for how to satisfy ISO 21434 requirements
• OWASP IoT Top 10: New and updated developer-centric recommendations for how to address the most common security risks that can make IoT devices vulnerable
• OWASP Privacy Top 10: New ​​OWASP Privacy Top 10 report and developer-centric recommendations and countermeasures based on the OWASP Privacy Top 10 Project

Just-in-Time-Training (JITT) Updates

Just-in-Time Training micromodules have been updated in SD Elements 2023.2 for Defending Node.js and Defending Java. For a complete list of the 800+ JITT micromodules now available within SD Elements, please see Security Compass’ Training Curriculum.  (If you are a current SD Elements customer but do not currently have a JITT subscription and would like to learn more, please contact Customer Success or Book a Demo.)

Application Security Training Courses

The following Security Compass Application Security Training courses are now available:

• Defending Node.js
• Defending Java

To learn more about these courses, as well as the more than 40+ other Application Security Training courses covering application security, operational security, compliance, and general awareness, please visit the Application Security Training page.

Learn More

Security Compass, the Security by Design company, helps organizations who develop software save time and money and reduce cyber risks through education and by taking an automated, developer-centric approach to software threat modeling, secure development, and compliance. This approach enables software developers and security teams to:

• Understand best practices for embedding product security
• Continuously model threats at scale
• Proactively write code that significantly reduces risks and remediation costs
• Demonstrate compliance with secure software development standards more easily
• Accelerate software time to market

If you are a current SD Elements customer, please reach out to your Customer Success Manager to learn more.

If you are new to SD Elements, request a demo to learn more.

The post SD Elements 2023.2 Release Update appeared first on Security Compass.

The US federal government has long been concerned with the security of its software and systems and those of organizations — with good reason. Operation Aurora, in 2009-10, targeted and stole design documents and source code from over 40 technology companies, including Northrop Grumman, Adobe and Cisco. The 2013 APT1 attacks victimized over 140 organizations.

Nation-state attacks on government agencies and critical infrastructure continue to pose a significant threat. More recent examples include:

• A 2020 attack by Russian hackers compromised the code base of SolarWinds’ Orion IT monitoring system, successfully adding a backdoor. A subsequent software update by SolarWinds distributed the compromised application to over 18,000 customers, including the US Departments of Defense, Energy, Commerce, State, Homeland Security, Treasury, and Justice.
• In 2019 researchers identified a backdoor in Chinese-made security cameras that  captured and sent back to China data from a Fortune 500 company. State, local, and federal government organizations also used the camera and were subject to the same backdoor.
• A 2015 breach of the US Government’s Office of Personnel Management (OPM) by Chinese actors exposed highly sensitive questionnaires used for background checks and security clearances on over 20 million people, including fingerprints.

A Brief History of Federal Security Standards and Authority to Operate

The federal government stepped up efforts to improve the security of the software and systems it developed and used in the early 1990’s with the DoD Information Technology Security Certification and Accreditation Process (DITSCAP). DITSCAP provided a structured approach for identifying, assessing, and mitigating security risks for information systems. This coincided with efforts to standardize the “Authority to Operate” (ATO) process. ATO is a formal authorization provided by a designated approving authority (DAA) that allows an information system to operate in a production environment. In short, one must have ATO authorization to provide software and systems to the federal government.

In 2005, the DoD replaced DITSCAP with the DoD Information Assurance Certification and Accreditation Process (DIACAP). Attaining ATO under DIACAP required compliance with guidelines for securing information systems published in NIST SP 800-37: Risk Management Framework for Information Systems and Organizations. In 2010, to address the unique risks introduced by the growth of cloud services, the General Services Administration (GSA), the Department of Homeland Security (DHS), and the National Institute of Standards and Technology (NIST) launched the Federal Risk and Authorization Management Program (FedRAMP). It is mandatory for all federal agencies to use FedRAMP-authorized cloud services.

DIACAP was used until 2014 when it was replaced by the newer NIST Risk Management Framework (RMF) detailed in SP 800-53: Security and Privacy Controls for Information Systems and Organizations. Achieving ATO or FedRAMP now requires compliance with the security controls detailed in SP 800-53 and SP 800-53A.

eMASS, ATO, and FedRAMP

As noted, agencies and vendors must meet the security requirements of the RMF to achieve ATO or FedRAMP accreditation. Rapidly developing and deploying secure software in a way that meets ATO requirements, especially within environments where software project volume, complexity, and delivery pace is high, and security expertise is in short supply, makes attaining ATO or maintaining continuous ATO (cATO) extremely difficult.

Further, tracking evidence of compliance with hundreds of security controls using spreadsheets and documents for a single application is subject to error. Scaling a manual process to thousands of systems and requiring ATO And FedRAMP accreditation is inefficient at best. For agencies and vendors working toward accreditation, manual processes are time consuming and delay accreditation.

To streamline the ATO And FedRAMP process, in 2010 the DoD introduced the Enterprise Mission Assurance Support Service (eMASS). eMASS is a web-based platform providing a centralized and standardized method for managing and tracking security requirements and controls for federal systems across the RMF life cycle. It maps to requirements detailed in SP 800-53, the Federal Information Security Modernization Act (FISMA), and other federal standards.

How SD Elements Helps

The NIST RMF requires organizations to identify risks and assign appropriate controls. Doing so manually is subject to inconsistent assessments of risk and assignment on controls. Tracking the status of each using spreadsheets or shared documents is prone to error and presents auditability challenges.

SD Elements automates this process through a centralized platform, assisting across the RMF to ensure compliance, including:

Select Controls: After completing a short survey of the applications technical stack, deployment environment, and applicable standards, SD Elements produces a complete list of security controls mapped to the RMF, including SP 800-53 and SP 800-53A .

Implement Controls: SD Elements translates the identified controls into actionable tasks and delivered directly to the development, security, and operations personnel responsible for their implementation through their existing workflow tools.

Assess Controls: SD Elements also provides test plans for validating each control and provides on-demand tracking of the status of each control. Finally, SD Elements works with eMASS, allowing exporting of compliance reporting against NIST controls to eMASS.

Next Steps

SD Elements is an important tool for building secure software. By anticipating threats and ensuring development, security, and operations implement NIST-required controls during the development process, it reduces the number of findings ATO and FedRAMP accreditation begins.

Assessors working with SD Elements and eMASS are now able to see a complete picture of how software was built from the beginning of the development lifecycle, enabling more rapid assessment for ATO and FedRAMP.

eMASS and SD Elements are powerful tools that are essential components of any government organization’s cybersecurity strategy. eMASS and SD Elements work together to define, track, and manage good cybersecurity practices. By providing a comprehensive and customizable solution for managing security and compliance, these systems help to improve security, streamline processes, and reduce costs.

You can learn more about how SD Elements supports government customers and accelerates ATO accreditation here.

The post Enterprise Mission Assurance Support Service (eMASS) and Its Link to Security Compass SD Elements appeared first on Security Compass.

The conference aims to educate, embed and empower the audience in the concept of security by design, which involves integrating key security capabilities into the Secure Product Lifecycle, from design to maintenance.

Equilibrium 2023 will bring together DevSecOps leaders and practitioners from various industries to share their experiences and discuss the latest advancements in secure development. The event is perfect for developers, DevOps and DevSecOps professionals, and product security experts who are serious about creating secure software.

At the conference, attendees can expect to learn from the most innovative minds in the industry, with sessions covering cutting-edge topics like security by design, cyber liability implications on software development, the coming impact of artificial intelligence on software security, and the emerging field of product security.

Security by Design

One of the main focuses of the conference is security by design. Attendees will hear how their organization can gain a significant competitive advantage by taking a proactive approach to security and privacy by design. This includes integrating security considerations into every phase of the software development lifecycle, from requirements gathering to design, development, testing, and deployment.

Cyber Liability

Another topic that will be discussed is cyber liability. With the increasing number of cyber-attacks and data breaches, organizations are now starting to add product security-specific clauses to contracts. Attendees will explore cyber liability and its legal and financial consequences for businesses.

Artificial Intelligence (AI)

Artificial Intelligence (AI) is another area that will be covered at the conference. AI has the potential to enhance software security, but it also comes with its risks. Attendees will delve into the role of AI in secure development, assess its potential benefits and associated risks, and discuss strategies to mitigate those risks.

Application Security Training

Application security training is a critical component of secure software development. Attendees will discover how they can empower software developers to build and release secure software without impacting delivery speed. This includes exploring training best practices that can help developers build secure code from the outset.

Product Security

Product security is a field that is rapidly evolving. Leading experts will share best practices based on important lessons learned from their own experiences on the product security front lines.

The Rise of the CPSO

Attendees will also learn how and why the roles of the CISO and CSPO are changing due to rapid changes in the cyber threat and liability landscape.

Equilibrium 2023 Conference will be a virtual event, allowing attendees to participate from anywhere in the world. The conference will feature live sessions, interactive workshops, and networking opportunities. Attendees will have the opportunity to connect with other professionals in the industry and learn from the experts.

This conference is an excellent opportunity for professionals in the software development industry to learn about the latest advancements in secure development. Attendees will have the chance to learn from the most innovative minds in the industry and shape the future of software security. Whether you are a developer, DevOps or DevSecOps professional, or product security expert, this conference is not to be missed.

Register today and be a part of the future of secure software development.

Register Now

The post The 2023 Equilibrium Conference by Security Compass appeared first on Security Compass.