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.

What is IEC 62443?

IEC 62443 is a globally recognized set of standards developed by the International Electrotechnical Commission (IEC) that provides a framework for securing industrial automation and control systems.

The IEC 62443 standards encompass all layers of an organization’s industrial control system (ICS), from the operator level to the enterprise level and everything in between. This includes components such as programmable logic controllers (PLCs), network devices, and SCADA software, as well as the human-machine interfaces (HMIs) that operators use to interact with these systems.

The standards are not specific to any industry and can be applied in any sector where ICS is used, including manufacturing, energy, water treatment, and transportation. They are intended to be flexible enough to adapt to varying levels of risk and different types of threats, making them suitable for a wide range of industrial environments.

In essence, IEC 62443 provides a comprehensive approach to cybersecurity, addressing not only technical aspects but also organizational and procedural matters. It covers everything from risk assessment and system design to incident response and recovery, providing a roadmap for organizations to establish a robust and resilient cybersecurity posture in their industrial operations.

History of IEC 62443

The history of IEC 62443 dates back to 2022, with the formation of a dedicated committee by the International Society of Automation (ISA). This committee, known as ISA99, was tasked with establishing standards and guidelines to ensure the security of industrial automation and control systems.

The ISA99 committee brought together diverse cybersecurity experts from various sectors, including manufacturing, utilities, and technology vendors. It recognized the growing threat of cyber-attacks on industrial systems and the need for a comprehensive standard that could be applied across different industries and organizations.

The initial work of the ISA99 committee culminated in creating a series of standards named ISA-99, which laid out the foundation for securing industrial automation and control systems. These standards addressed various aspects of cybersecurity, including defining key concepts and models, establishing a cybersecurity management system, and providing guidelines for system design, implementation, operation, and maintenance.

Recognizing the universal applicability and importance of these standards, the International Electrotechnical Commission (IEC) adopted them as IEC 62443 in 2010. The IEC is a leading global organization that publishes international standards for all electrical, electronic, and related technologies.

Since then, IEC 62443 has been continually updated and expanded to keep up with the evolving cyber threat landscape and technological advancements in industrial automation. Today, it stands as one of the most comprehensive and widely recognized standards for industrial cybersecurity worldwide.

The development and evolution of IEC 62443 represents a significant collaborative effort by numerous stakeholders worldwide. It reflects the global commitment to ensuring the security of our industrial systems and infrastructure against increasingly sophisticated cyber threats.

The ISA99 Committee

The ISA99 Committee is a vital part of the history and ongoing development of the IEC 62443 standards. Formed by the International Society of Automation (ISA), the committee was established with the specific goal of creating a robust set of standards to help secure industrial automation and control systems from cyber threats.

The ISA99 Committee consists of a diverse group of experts drawn from different sectors across the globe. The members include representatives from manufacturing companies, utilities, system integrators, security solution providers, and technology vendors. The team also comprises consultants, academics, and government officials, all bringing unique perspectives and expertise to the table.

The committee’s primary task was to develop detailed guidelines and best practices for implementing secure industrial automation and control systems. However, their work didn’t stop at merely crafting the standards. They also promoted these standards within the industry and provided education and resources to help organizations understand and implement them effectively. The ISA99 concerns itself with automation and control systems whose compromise could result in any or all of the following situations:

• Endangerment of public or employee safety
• Environmental protection
• Loss of public confidence
• Violation of regulatory requirements
• Loss of proprietary or confidential information
• Economic loss
• Impact on entity, local, state, or national security

Since its inception, the ISA99 Committee has made significant contributions to the field of industrial cybersecurity. The standards they developed under the ISA-99 series served as the basis for the IEC 62443 standards, which are now recognized globally. Despite this achievement, the committee continues to work towards refining and expanding these standards to address the evolving cyber threat landscape and technological advancements in industrial automation. For more information on the ISA99 committee, check out the ISA99 section on the ISA page.

Reasons for Developing IEC 62443

The development of the IEC 62443 series of standards was driven by several key factors, all of which underscored the critical need for robust cybersecurity measures in industrial automation and control systems (IACS). Here are some of the primary reasons:

1. Expanding Use of IACS Across Various Sectors: Originally designed for the industrial process sector, IACS has found wide-ranging applications in diverse industries, including power and energy supply and distribution, transport, and others. Given that these technologies form the backbone of critical infrastructure, securing them became an urgent necessity.
2. Inadequacy of IT Standards for IACS: Traditional IT standards were found to be ill-suited for IACS and other operational technology (OT) environments, primarily due to differences in performance, availability requirements, and equipment lifetimes. More importantly, while cyber-attacks on IT systems mainly have economic implications, attacks on critical infrastructure can lead to severe environmental damage, public health crises, and loss of life.
3. Rising Cyber Threat Landscape: With the increasing sophistication of cyber threats, it became clear that industry-specific standards based on best practices were needed to mitigate the effects of successful cyber-attacks, bolster security throughout the lifecycle of IACS, and reduce associated costs.
4. Need for a Holistic Approach: Recognizing that not all risks are technology-based, the developers of IEC 62443 aimed to create a standard that addresses the entire ecosystem surrounding IACS. This includes not only the technology itself but also the work processes, countermeasures, and most importantly, the people involved. The staff responsible for an IACS must have the necessary training, knowledge, and skills to ensure security.
5. Risk-Based Approach: IEC 62443 adopts a risk-based approach to cybersecurity, acknowledging that it is neither efficient nor sustainable to protect all assets equally. Instead, organizations are encouraged to identify their most valuable assets, assess their vulnerabilities, and then erect a defense-in-depth architecture that ensures business continuity.

In summary, the primary motivation behind the development of IEC 62443 was to create a comprehensive, adaptable, and effective framework for securing IACS against the growing threat of cyber-attacks. Given the crucial role these systems play in numerous industries and critical infrastructure, the importance of such a standard cannot be overstated.

Fundamental Concepts of IEC 62443

IEC 62443, a series of standards developed to secure industrial automation and control systems (IACS), outlines several security requirements. These requirements are designed for various stakeholder groups, including operators, service providers, and component/system manufacturers. Here are the key security requirements as per the IEC 62443 standards:

1. Risk-Based Approach: IEC 62443 promotes a risk-based approach to cybersecurity. This means identifying the most valuable assets, assessing their vulnerabilities, and then implementing protective measures accordingly. The standard discourages trying to protect all assets equally, highlighting it as neither efficient nor sustainable. Part 3-2 of the guidelines addresses cybersecurity risks in Industrial Automation and Control Systems (IACS), emphasizing the use of zones and conduits and maintaining a flexible approach towards risk assessment methodologies, which should align with an organization’s overall strategy. Zones are defined as groupings of assets based on various criteria like risk or function, while conduits are logical groupings of communication channels connecting these zones. Effective partitioning into zones and conduits is crucial for reducing cybersecurity risks and limiting the impact of cyber-attacks. Additionally, Part 3-2 mandates documenting security countermeasures and requirements in a Cybersecurity Requirements Specification (CRS), which integrates into IACS documentation and includes detailed system descriptions and countermeasures. Furthermore, Part 4-1 introduces requirements for the security development lifecycle of control systems, with a strong focus on threat modeling to identify and mitigate security vulnerabilities throughout the product’s lifecycle.
2. Defense in Depth: The standard recommends a multi-layered defense strategy, known as ‘defense in depth’. This strategy involves implementing multiple levels of security controls throughout the system to provide redundancy, ensuring that if one measure fails or a vulnerability is exploited, other protective layers remain intact.
3. Maturity and Security Levels: IEC 62443 describes four levels of maturity for processes (based on the Capability Maturity Model Integration (CMMI) framework) and five Security Levels (SL) for evaluating technical requirements (IEC 62443-3-3 and IEC 62443-4-2). While Security Levels measure the effectiveness of the Technical Requirements, Maturity Levels measure the people, policies, and procedures. Security levels indicate resistance against different classes of attackers and should be evaluated per technical requirement, while maturity levels indicate that all process-related requirements that apply to a particular maturity level have been practiced during product development and integration.
4. Certification to Standards: IEC 62443 encourages certification of processes, systems, and products used in industrial automation environments as per the standard. Several global testing, inspection, and certification (TIC) companies offer product and process certifications based on IEC 62443.

In summary, the IEC 62443 standards provide a comprehensive set of security requirements for IACS, focusing on a risk-based approach, defense-in-depth strategy, secure product development, and certification. These requirements are designed to ensure robust cybersecurity measures are in place throughout the lifecycle of IACS, thereby protecting critical infrastructure from potential cyber threats.

IEC 62443 Document Structure

The IEC 62443 series of standards is organized into four main parts, each focusing on different aspects of industrial automation and control systems (IACS) security:

1. General: This part addresses topics common to the entire series, laying the foundational concepts and models. It sets the stage for the more specific guidelines and requirements presented in subsequent parts​.
2. Policies and Procedures: This segment delves into the methods and processes associated with IACS security. It includes documents like 62443-2-1, which outlines the requirements for defining and implementing an effective IACS cybersecurity management system, and 62443-2-4, which details requirements for IACS service providers across various topics such as assurance, architecture, wireless, security engineering systems, and more​.
3. System: This part focuses on system-level requirements. It includes standards like 62443-3-2, which deals with security risk assessment and system design, and 62443-3-3, which specifies system security requirements and security levels. This part is crucial for understanding the broader system implications of security in IACS environments​.
4. Components and Requirements: The final part provides detailed requirements for IACS products. This includes standards like 62443-4-1, which defines secure product development processes, and 62443-4-2, which sets out technical security requirements for IACS components. This part also includes common component security constraints (CCSC) that components must meet to be compliant with these standards​.

Foundational Requirements of IEC 62443

Foundational Requirements serve as the basis for the Technical Requirements (62443-3-3 and 62443-4-2) throughout the ISA/IEC 62443 documents. The foundational requirements of IEC 62443 include:

• FR 1 – Identification & authentication control: This requirement ensures that access to devices and information is restricted to authenticated and authorized entities, crucial for safe and intended operation of the plant or facility.
• FR 2 – Use control: UC ensures that only authorized entities can use IACS devices and information for essential tasks. It emphasizes the principle of “least privilege,” granting minimal access necessary for task completion.
• FR 3 – System integrity: SI safeguards against unauthorized data alterations in communication channels, ensuring the authenticity and accuracy of data, such as process values displayed on an operator’s screen.
• FR 4 – Data confidentiality: This requirement mandates the protection of data within the IACS from access by unauthorized external or internal parties.
• FR 5 – Restricted data flow: RDF requires that information is shared only on a “need to know” basis, limiting unnecessary data flows and necessitating careful system architecture design for effective partitioning into Zones and Conduits.
• FR 6 – Timely response to events: TRE requires IACS to have the capability to promptly respond to security violations, including notifying authorities, reporting evidence, and taking corrective action.
• FR 7 – Resource availability: This ensures the design and operation of IACS prevent “denial of service” situations, guaranteeing that safety-related systems, like Safety Instrumented Systems, can operate or bring the plant to a safe state even under a Denial of Service Attack.

These foundational requirements, when effectively implemented, provide a comprehensive approach to securing IACS, making them resilient against potential cyber threats.

Benefits of Implementing IEC 62443

Implementing IEC 62443, a series of standards developed to secure industrial automation and control systems (IACS), can offer numerous benefits to organizations across various sectors. These benefits extend beyond merely protecting systems from cyber threats, offering advantages in terms of risk management, regulatory compliance, and overall system resilience.

1. Improved Security Level for Industrial Automation Systems: IEC 62443 provides a comprehensive set of guidelines that can significantly enhance the security posture of industrial automation systems. It addresses both the technical aspects of these systems, such as components and configuration and the human factors, such as staff training and awareness. By following these guidelines, organizations can protect their systems against a wide range of potential cyber threats, from unintentional errors to sophisticated, targeted attacks.
2. Tolerable Levels of Cybersecurity Risk: One of the critical principles of IEC 62443 is its risk-based approach to cybersecurity. Recognizing that it is neither feasible nor cost-effective to protect all assets equally, the standard guides organizations in identifying their most valuable assets and their associated vulnerabilities. This allows them to focus their resources on areas where the risk is most significant, ensuring that they maintain tolerable levels of cybersecurity risk. This approach enhances the security of the organization’s systems and contributes to more efficient use of resources.
3. Compliance with Regulatory Requirements: With the increasing emphasis on cybersecurity in regulatory frameworks worldwide, compliance has become a critical concern for many organizations. Implementing IEC 62443 can help organizations demonstrate their commitment to cybersecurity, thereby meeting their regulatory obligations. The standard’s status as an internationally recognized guideline may also facilitate compliance with regulations in different jurisdictions.

Conclusion

In summary, the IEC 62443 standard provides a comprehensive and robust framework essential for enhancing the security of industrial automation and control systems. This standard not only addresses technical and human elements but also emphasizes a risk-based approach, aiding organizations in achieving a perfect balance between cybersecurity and operational efficiency. Its global recognition also makes it an invaluable tool for meeting various regulatory requirements. IEC 62443 is more than just a set of guidelines—it’s a strategic asset in empowering organizations to safeguard their critical systems, fulfill regulatory duties, and create a resilient infrastructure capable of withstanding the ever-changing cyber threats.

Elevate your organization’s cybersecurity strategy and ensure compliance with the IEC 62443 standards by choosing SD Elements. Don’t miss the opportunity to see our solutions in action with a live demo. Act now – contact us today and let our expert team show you why SD Elements is an essential tool in your cybersecurity arsenal. Make the first move towards enhanced security and regulatory alignment – reach out to us today.

The post Everything You Need to Know About IEC 62443 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.

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.

Altaz Valani, our Director of Insights Research, recently spoke with Mark Timms. Mark is a Senior Behavioral Scientist at Royal Bank of Canada (RBC). His job is to deliver behavioral science research to help RBC’s over 100,000 employees make smarter decisions about how to use technology. Prior to joining RBC, he served (and continues to serve) as an Infantry Officer in the Canadian Armed Forces, a Communications Advisor for the Government of Canada, a Defence Scientist for the Defence Research and Development Canada, and as Manager of Physical Risk at Scotiabank.

You can listen to the entire interview here. Below are some highlights.

His passion is decision science

Mark talks about the writings of James Clear and the desire of humans to fit in with others. This is true in the workplace as well as at home, and can drive safe or unsafe behavior from a security viewpoint. “People want to avoid behaviors that the humans around them will condemn…” This can present challenges to security teams that focus on explaining the technical aspects of a threat without understanding how users “need to receive information that will help them make smarter decisions with technology.”

Work from Anywhere adds challenges

By now, most people know they shouldn’t click on links in emails from unknown senders. However, Mark contends that overconfidence and distractions can cause people to make mistakes. He provides the example of reading email while driving. More important in today’s environment is the impact of employees working from home.

“The boundaries between “work” and “not work” are fudged because…a lot of the activity happens at the same desk in the same room. Bottom line: our distractibility and perhaps the absence of focus or the blurring of lines between “work” and “not work” contributes to suboptimal decisions.”

Security is not always a technical challenge

Organizations need to balance the technical side of solutions with getting workers to take the correct actions in their normal workday. Shaping human behavior needs to speak to the individual. Traditional cybersecurity messaging focuses on things people are not allowed to do. Instead, organizations need to focus on helping people achieve their goals safely. Organizational policies on communications can also deter progress. In Mark’s words: “Lessons identified have a harder time transforming into lessons learned when the only humans who can actually perceive this issue have to go through all kinds of permission granting loops to share that information with other people.”

Security people are like salespeople

Messaging is critical in convincing users to adopt good security practices. He cites the work of Sandra Matts and Michael Kazinski on “psychological targeting”. In essence, “…tailoring a line of persuasion or a message to convince me to do something”. Where a salesperson might be selling a car, his organization is helping “sell smarter decisions with technology”  including making the better security behavior easier for the user. This includes messaging about “why” it is best not to reuse passwords or respond to phishing messages. They key is “to present the exact same call to action [e.g., don’t reuse passwords’ to two different types of humans in ways that resonate with those types of humans equally.”

The entire interview is available here.

The post The Human Side of Cyber Security – with Mark Timms appeared first on Security Compass.

-Altaz Valani, Director of Insights Research, Security Compass

Read the full article…

The post Value Stream Management Leaders Come Together to Develop Interoperability Standards at OASIS Open appeared first on Security Compass.