This strategic shift, known as “Security by Design,” not only fortifies applications against potential threats but also delivers significant returns on investment (ROI) by reducing the cost and impact of security vulnerabilities.

The Imperative of Early Security Integration

The concept of “shifting left“—integrating security measures early in the software development lifecycle—has become a cornerstone of robust application security strategies.

This approach challenges the conventional methodology of treating security as a final step or a quality to be tested for after development. By embedding security principles from the very beginning, organizations can anticipate and mitigate risks before they manifest as costly vulnerabilities.

The Cultural Shift Towards Security by Design

Adopting Security by Design necessitates a profound cultural shift within organizations, transcending beyond mere technical adjustments. It requires the commitment and understanding of every stakeholder, from executives to developers.

The journey begins with education, ensuring that all parties comprehend the value and mechanics of proactive security measures. Following this, the organization must embed these principles into its processes, empowering development teams to incorporate security considerations inherently and autonomously.

Demonstrating ROI Through Security by Design

Quantifying the ROI of Security by Design is pivotal in securing executive buy-in and sustaining the initiative. This can be achieved by analyzing the cost savings from averting potential vulnerabilities, the reduction in risk exposure, and the overall enhancement of product quality.

For instance, the integration of security measures from the design phase can significantly reduce the number of high-risk vulnerabilities, translating into direct savings on remediation costs and minimizing the ‘window of risk’ during which applications are vulnerable to attack.

Overcoming Common Challenges

Implementing Security by Design is not without its challenges. Organizations often encounter obstacles such as resistance to change, misconceptions about the feasibility of early security integration, and difficulties in measuring short-term successes.

To overcome these, it’s crucial to address the common “anti-patterns” that can derail security initiatives, such as siloed efforts, lack of proactive metrics, and the failure to recognize security as a shared responsibility.

The Path Forward: A Framework for Success

A structured framework can guide organizations in effectively adopting Security by Design. This includes:

• Baseline Education: Building a foundational understanding of security principles across the organization.
• Embedding Expertise: Integrating security experts and champions within development teams to facilitate knowledge sharing and guidance.
• Empowering Teams: Providing the tools and autonomy necessary for development teams to implement security by design principles effectively.

The Bottom Line: Security as an Investment, Not a Cost

Security by Design is more than a cybersecurity strategy; it’s a business imperative that enhances operational efficiency, reduces risk, and ultimately contributes to the bottom line.

By embedding security into the DNA of application development processes, organizations can not only protect themselves against the ever-evolving landscape of cyber threats but also unlock significant economic value.

Ready to Shift Left with Security by Design?

At Security Compass, we empower organizations to integrate proactive security measures seamlessly into their development processes. Our comprehensive solutions and expert guidance can help your team navigate the cultural and technical shifts necessary to embrace Security by Design.

Don’t wait for vulnerabilities to dictate your security strategy. Contact us today to learn how you can proactively secure your applications and unlock the full ROI of your security investments.

The post Unlocking the ROI of Security by Design in Application Development appeared first on Security Compass.

In 2022, the release of the ISO 27002:2022 document included additions to enable information security professionals to address the latest information security risks. One of the most prominent additions is 8.28 Secure Coding, which provides requirements for protecting sensitive data and other personal information during the Software Development Life Cycle.

This blog will provide a technical introduction to ISO 27001 and discuss:

• Important changes in 27002:2022
• What is secure coding
• What is included in the ISO Secure Coding provision
• A guide to secure coding activities

What is ISO 27001?

ISO 27001 is an international standard that was published as a joint effort by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) in 2005, then revised in 2013 and more recently in 2022 to account for the ever-changing risk landscape.

ISO 27001 specifies requirements for establishing, implementing, maintaining, and continuously improving an information security management system (ISMS). It is important for any organization that handles sensitive information to adapt its strategies based on its size, its needs, and any relevant potential for risk. Most ISO 27001 provisions are based on the information security principles of Confidentiality, Integrity, and Availability (CIA), which define their protection criteria.

Organizations that are confident about their implementation of an ISMS based on ISO 27001 can get certified by an accredited certification body after the completion of a three-stage external audit process that verifies their implementation.

What is ISO 27002?

As counterpart to ISO 27001, ISO 27002 provides best practices and additional information for implementing the ISMS. It got its origin in the early 1990s with corporate security standards provided by Shell to the UK government, which then became the British Standard BS 7799. In 2000, BS 7799 became ISO/IEC 17799 and was renamed in 2007 to ISO/IEC 27002 in order to stay consistent with the other standards in the ISO/IEC 27000 series. Since then ISO/IEC 27002 has seen revisions in 2005, 2013, and most recently in 2022.

ISO 27002 certification isn’t a thing, because it is merely an advisory document meant to be interpreted by the implementing company based on their specific risk requirements. However, ISO 27001 aligns itself with 27002, which means that the provisions in 27002 still must be implemented to get 27001 certification.

Important changes in 27002:20222

ISO 27002:2022 introduced updates to catch up with changes in legislation and technology as well as evolving threats in the industry. Despite these updates, the document’s purpose remains the same as it still provides controls meant to be implemented within the context of an ISMS based on 27001.

Changes in 27002:2022 include:

• There are now 4 themes instead of 14 domains.
• The number of security controls was reduced from 114 to 93
• There are 11 new controls, one of which is 8.28 Secure Coding

What is secure coding?

Secure coding is the practice of preventing security vulnerabilities in written code by writing code that follows strict principles. These principles govern coding techniques, practices, and the decision-making process of developers writing the code.

What is included in the ISO Secure Coding provision?

ISO 27001 8.28 is broken down into sections covering different phases of the SDLC.

General secure coding activities

The ISO standard indicates that the organization should establish organization-wide processes to provide secure coding governance that covers both internally developed code and third-party software components including open source. The organization should also establish a minimum baseline and stay updated on new threats and vulnerabilities.

What to do before coding (planning and precoding)

The ISO 27002 guidance document recommends taking advantage of the planning stage to set standards and expectations for secure coding for both internal and outsourced development. Establishing developer proficiency in secure coding through training and education should be a focal point for organizations.

The guideline further suggests keeping development tools up to date and properly configured to support coding standards enforcement. This entails setting stringent access rights to preserve code privacy and security during its creation. Threat modeling should be an essential part of the application’s architecture and design, potentially encompassing scenarios where the system is attacked or compromised.

What to do while coding

When coding, ISO 27002 suggests using secure, language-specific practices and structured programming techniques for easier comprehension and debugging. The code should be appropriately documented to facilitate collaborative methods like pair programming and peer reviews for detecting and removing code defects and avoiding insecure programming techniques like hard-coded passwords, lack of input validation, and so on. This combined approach bolsters security and improves code quality.

Testing, both during development and post-development, is crucial for removing security-related bugs before the software is deployed. ISO 27002 recommends using Static Application Security Testing (SAST) as needed. Prior to operationalizing software, assessing the attack surface, confirming the application of the principle of least privilege in the code, and validating the code against common errors while documenting their mitigation are all relevant activities to be performed. This ensures robust software security before deployment.

What to do while performing review and maintenance

After deploying the code, ensure that the live environment is checked consistently for vulnerabilities by scanning with a DAST/SAST tool as needed, enabling and regularly reviewing the active logging of errors and security events, and performing penetration tests. Whatever vulnerabilities surface from these exercises should be handled promptly, and updates that fix the vulnerabilities should be securely packaged and deployed. Also, protect the source code from unauthorized access or tampering by using configuration management tools.

When incorporating external tools and libraries, look for trustworthy sources that are trackable and maintainable and have long-term development resources available. Ensure they are securely managed and updated regularly in release cycles. Choose authorized and validated third-party components for critical tasks like authentication and encryption.

When modifying third-party software, consider the risk if its built-in defenses are compromised, and whether vendor consent is required. It might be more appropriate for the vendors to make and release those required changes as updates. Assess the impact of bearing the responsibility of future maintenance on the organization and evaluate the compatibility of the changes with other software components.

How can SD Elements help?

Two primary means through which the practice of secure coding can become ingrained within an organization are security standards and developer education. SD Elements facilitates secure coding throughout the Software Development Life Cycle by gathering data about the specifics of the infrastructure (such as the technical stack, deployment context and regulatory requirements) through a survey and recommending relevant security countermeasures and practices to follow before, during, and after coding.

These countermeasures are largely based on relevant standards and guidelines like ISO/IEC 27001 and 27002, tailored by an internal team of researchers to the specifics of a particular infrastructure. SD Elements can integrate with different DAST/SAST scanners and project management tools to help maximize secure coding productivity.

Security Compass also provides developer education through training courses that cover secure coding practices for specific programming languages and techniques.

The post ISO 27001 and the Evolution of Secure Coding appeared first on Security Compass.

A Short History of the PCI DSS

As eCommerce grew in popularity during the DotCom era, so too did credit card fraud. In the early 21st century credit card companies began issuing security standards for their merchants and payment processors. To simplify compliance, in 2004 Visa, Mastercard, American Express, Discover, and JCB introduced the Payment Card Industry Data Security Standard (PCI DSS). Version 1 of the standard was designed to establish a common set of security requirements for all merchants and service providers that handle credit card information.

The initial versions of the DSS were brief while managing to cover the primary threats faced by organizations at that time. While the wording has changed a little, Version 1.1, introduced in 2006, covered the same six domains still used today. Logging in at just 17 pages (including cover pages and appendices) it helped organizations mitigate threats by deploying firewalls, encrypting data, and developing secure systems.

PCI DSS 4.0

In response to changing threats, in March 2022 the PCI Security Standards Council released PCI DSS v4.0. While the standard maintains the six domains and 12 requirements of the original versions, it now covers over 350 pages of guidance and prescriptive controls. Compared to version 3.2.1, PCI DSS 4.0 includes over 80 evolving requirements, including 60 new requirements. These range from encryption algorithms used to render PAN unreadable on removable electronic media to new requirements exclusively for service providers.

Given the vast changes in 4.0, the Council is allowing organizations and auditors time to prepare for compliance. Many of the new requirements are “future dated” and not required until March 31, 2025. In the meantime, they are considered “best practices’ ‘. Organizations are encouraged to implement these items but are not required to validate the controls. The timeline below from the PCI Security Standards Council provides further color.

Requirement 6: Develop and Maintain Secure Systems and Software

Just as the PCI DSS has changed to address emerging needs, so too have software development processes. Long gone are the days of quarterly releases and minimal security checks. Today’s development teams must meet faster release cycles with more stringent security requirements. The need for developer-centric security has never been greater.  Something about changes to software development over the past years (faster release cycles/more focus on security/shift left)

For this reason  we want to focus on the changes in Requirement 6 that pertain to building more secure software.

Requirement 6.1:  Processes and mechanisms for developing and maintaining secure systems and software are defined and understood.

Beginning a security program requires organizations to establish policies and best practices. Requirement 6.1 is designed to track that and ensure that organizations develop, maintain, and follow secure coding practices for applications they develop and that these practices are integrated into the software development life cycle.

Requirement 6.1.2: Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood.

Effective Date: Immediate for all v4.0 assessments

6.1.2 is new. Similar language is  also present in all requirements. Previous versions of the PCI DSS rarely required documenting which roles had day-to-day responsibility for each activity. It appears the Council has recognized that group accountability is insufficient in ensuring security and that PCI compliance must be part of an organization’s “business-as-usual” processes. It recommends auditors “Examine documentation to verify that descriptions of roles and responsibilities for performing activities in Requirement 6 are documented and assigned.”

Requirement 6.3 Security vulnerabilities are identified and addressed. 

The security efforts of many organizations focus on Requirement 6.3. The requirement is far reaching and is also referenced in across other Requirement 6 sub-requirements as well as Requirement 2.2 (System components are configured and managed securely), Requirement 11.3 (External and internal vulnerabilities are regularly identified, prioritized, and addressed), 11.4 (External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected), and others.

6.3.2 An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management. 

Effective Date: March 31, 2025.  Best practice until effective date. 

Requirement 6.3.2 is a significant change to the DSS. It also is not a surprise to anyone who has been following application security in recent years. According to the 2023 Open Source Security and Risk Analysis report from Synopsys, open source comprises 76 percent of the average commercial application. 84 percent of those code bases included at least one vulnerability in open source components, and 48 percent contained high risk vulnerabilities.

Vulnerabilities in open source are particularly troublesome. Identifying zero-day vulnerabilities in custom applications is difficult. Publicly disclosed vulnerabilities in open source components can be repurposed easily by attackers to identify vulnerable systems. This threat gained a lot of attention after the Equifax breach in 2017. More recently, Executive Order 14028 requires organizations providing software to the US government to include a Software Bill of Materials, or SBOM. Many organizations recognized this threat years ago and began tracking the open source they use. PCI DSS 4.0 makes it a requirement.

6.4 Public-facing web applications are protected against attacks. 

Publicly facing web applications are the perimeter for sensitive information. Adversaries have unfettered access to these applications, and coding errors, design flaws, or misconfigurations can provide easy access to sensitive data.

6.4.2 For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following: 

•      Is installed in front of public-facing web applications and is configured to detect and prevent web-based attacks. 

•      Actively running and up to date as applicable. 

•      Generating audit logs. 

•      Configured to either block web-based attacks or generate an alert that is immediately investigated. 

Effective Date: March 31, 2025.  Best practice until effective date

Requirement 6.4.2 is a reminder that – even in the most diligent development environments – residual risk can remain. An “automated technical solution” like a web application firewall (WAF) is designed to protect web applications from threats such as Denial of Service (DoS), SQL injections, and Cross-site scripting attacks.

An interesting aspect of the 6.4.2 is the requirement to “prevent” web-based attacks. Most organizations deploy WAF to generate alerts rather than block all suspicious activity, since the latter can also result in false positives that block legitimate traffic. One assumes that a WAF that prevents some attacks (through rate limiting to block brute force attacks) will meet auditors’ requirements.

6.4.3 All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows: 

•      A method is implemented to confirm that each script is authorized. 

•      A method is implemented to assure the integrity of each script. 

•      An inventory of all scripts is maintained with written justification as to why each is necessary. 

Effective Date: March 31, 2025.  Best practice until effective date.

Like Requirement 6.3.2, the Requirement necessitates visibility to potential threats, including the creation and ongoing management of an inventory of payment page scripts used in an application. The DSS suggests teams can meet this requirement through the use of SubResource integrity (SRI) and Content Security Policy (CSP) controls.

How SD Elements Helps

Version 4 of the PCI DSS introduces 60 new requirements with which development, security, and operations teams must comply. But it is just one of many regulatory requirements organizations must anticipate, understand, and validate their applications. Keeping controls current with rapidly changing and often overlapping requirements can challenge even the most well-staffed and funded organizations.

The key to compliance is visibility to requirements and consistency in approved security controls. Testing for compliance at the end of the development process slows down development and contributes to friction between development, compliance, and security teams. Teams can only maintain compliance while meeting aggressive product delivery goals by anticipating each requirement and assigning controls to appropriate team members prior to beginning development.

While many of the new requirements will not be enforced until 2025, smart organizations are preparing today. SD Elements provides teams with a simple method for complying with PCI DSS and scores of additional security and privacy guidelines. It includes developer-centric recommendations for how to satisfy PCI-DSS v4.0 requirements, including specific countermeasures and e-learning coursework.

Using SD Elements is simple. It starts with a short survey describing an application’s technical stack, deployment environment, and relevant regulatory guidelines. SD Elements translates these into a list of security requirements and actionable controls that are assigned to development, security, and operations personnel through their normal workflow. Making PCI DSS compliance part of your “business as usual” operation minimizes the chance of compliance violations and ensures developers are leveraging a secure, reliable source of information.

Ready to see what SD Elements can do? Book a demo!

The post Preparing for PCI DSS V4 appeared first on Security Compass.

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

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

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

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

Next Steps

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

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