Defining Security in Software: Frameworks, Compliance, and Best Practices

The OWASP Top Ten Proactive Controls 2018 version states, “Insecure software is undermining our financial, healthcare, defense, energy, and other critical infrastructure worldwide. As our digital, global infrastructure gets increasingly complex and interconnected, the difficulty of achieving application security increases exponentially. We can no longer afford to tolerate simple security problems.”  Little wonder that the first control on the list is to Define Security Requirements.  Security requirements provide a foundation for a system being developed to be resilient to security threats that have previously occurred. So, how do we do this in a world where the developers simply write code?

Organizations often struggle to identify security touchpoints for an end-to-end product development lifecycle. The more challenging part is to resonate the touch points with what enterprise security means to the organization. For example, too many security touchpoints may prevent developer agility and slow the development cycle, whereas having fewer touchpoints will/may lead to fixing security issues when discovered later in the stages, which may be twice as expensive. The amount of time given to security can vary depending on what drives security within the organization. For example, start-ups may not spend much time considering the security implications as they try to balance keeping the lights on by delivering products. At the same time, organizations in highly regulated industries may have rigorous formal processes to follow.  Most organizations fall somewhere in between and have requirements driven by customers’ expectations and legal and GRC (Governance, Risk, and Compliance) concerns for the organization that must be considered with the limited available resources.

According to Veritas, only 14% of Waterfall projects succeed without encountering challenges. In contrast, Agile projects exhibit a higher success rate, with 42% achieving success without facing significant obstacles. Agile projects typically rely on DevOps, emphasizing collaboration between development and operations teams. This approach focuses on delivering products at scale while maintaining value, enhancing the overall business. DevOps stands for Developer Operations and is a set of practices, tools, and philosophies that combines Software Development, Application Delivery, and Information Technology (IT) Operations [SANS]. This implies a complete software development lifecycle, establishing a continuous feedback loop among development, operations, continuous integration and deployment, logging, monitoring, and quality assurance. Consequently, it enhances orchestration and collaboration across various teams. This loop still does not include security, as the sections below explain.

Security Frameworks

Compliance as a forcing mechanism: Security requirements provide a foundation of vetted security functionality for an application. Instead of creating a custom approach to security for every application, standard security requirements allow developers to reuse the definition of security controls and best practices. Those exact vetted security requirements provide solutions for security issues that have occurred. Requirements exist to prevent the repeat of past security failures. Enterprise Security and GRC teams should vocalize about such requirements to be created and adopted by all development teams. Security requirements should address authentication, authorization, network segmentation, data protection, and vulnerability scanning. The most common frameworks to formulate these requirements are CIS Benchmark, NIST-SP-800-53, and OWASP ASVS. Well-known methods for gathering security requirements include:

• NIST SP 800-53: The National Institute of Standards and Technology (NIST) Special Publication 800-53 provides a catalog of security and privacy controls for federal information systems and organizations.
• OWASP SAMM (Software Assurance Maturity Model): The OWASP SAMM framework guides organizations in evaluating and improving their software security posture. It includes governance, design, implementation, verification, and operations practices, with specific activities to gather and define security requirements.
• BSIMM (Building Security In Maturity Model) is a framework based on the observed practices of many software security initiatives. It helps organizations understand and improve their software security programs by benchmarking their practices against those of other organizations.

Other notable frameworks include the Comprehensive Lightweight Application Security Process (CLASP), Microsoft’s Secure Development Lifecycle (SDL), Security Requirements Engineering (SQUARE), and Secure Requirements Engineering Process (SREP). Work has also highlighted the difference between BSIMM and OWASP SAMM, which organizations can refer to while building security requirements. With this knowledge, we can now look at how to determine the security requirements we need.

Gathering Security Requirements

As with general system requirements, security requirements must be written to achieve a specific goal. According to Snyk, there are several components to creating reasonable security requirements. Security requirements must be consistent, clear, and unambiguous and stated in a complete, measurable, and testable fashion. Organizations starting their journey may simply state that software must be developed securely. That engineers are not traded by academia has been well established. Five years ago, Jack Cable wrote in the Harvard Business Review as a graduate student that 23 top US computer science schools do not require cybersecurity classes. Earlier this year, when working for CISA, he found nothing had changed. Fundamentally, this means that organizations cannot expect developers to be able to create secure solutions without investing in training and guidance.

Since it is an unused skill, organizations sometimes face challenges in gathering these requirements during the design phase of a product or application. Security requirements are often limited to authentication, authorization, network segmentation, and the OWASP TOP 10. However, involving appropriate security stakeholders can reveal a broader spectrum of necessary security measures. Secure design should consider the CIA triad (Confidentiality, Integrity, Availability) of the product/application. So, what are the ideal process models for creating secure architecture and designs that balance security with the rapid pace of enterprise-level software development? To effectively gather security requirements, it is imperative to consider several factors:

• Define Security Early: Establish foundational security measures at the start of development to integrate security into design. Security should be a non-functional requirement that is considered early in the design phase. Adding security later is costlier and less effective. Retroactive security fixes can lead to technical debt and increased costs.
• Identify the current process gap: Security is often overlooked when designing applications and products, leading to vulnerable packages and the mis-prioritization of risks. These gaps stem from poor guidelines for reviewing, assessing, and re-evaluating vulnerabilities and inadequate training and escalation processes. For example- The frequent use of vulnerable packages increases the likelihood of exploitation, creates frustration for security teams, and fosters institutional apathy, slowing progress in mitigating risks.
• Engage the Right Stakeholders: Ensure product owners and business sponsors understand threats and risks by defining what needs to be secured, how it should be secured, and against whom. Shift-left security approaches should involve more than just engineers. This will ensure adequate security expertise is engaged to tackle:
  • Modern software consists of interconnected systems spanning cloud and corporate networks.
  • Generative AI and emerging technologies introduce new security challenges with limited established best practices.
• Identify the organization’s security goal: Based on compliance posture or security decisions, an organization will have a high-level goal set to ensure security through SDLC, providing some inputs on where security touchpoints should exist and in the optimal security architecture and design.

Where To Start

Security awareness and training: Security awareness training should be designed to educate members of development and operational teams at all levels about the general principles of cybersecurity, available patterns for protecting against potential threats, and the importance of security policies and procedures. Not enough security training in the organization can lead to several risks, such as — The use of prohibited, discouraged workflows or unintentionally missing essential security steps regularly is indicative of the following:

• Gaps in routine training practices around services, systems, or tooling.
• Poor documentation around services, systems, or tooling.
• Poor guidelines remain present within the organization despite their discouraged status.
• Poor processes for re-review of new processes or expectations.
• Capability gaps within the capability restriction for prohibited or discouraged workflows.

The frequent use of undesired workflows for accomplishing tasks:

• Increases the probability and impact of misconfiguration.
• Confusion by actors attempting to accomplish actions.
• Institutional Knowledge acting in the place of policy, hampering compliance efforts.

Security Champions Program: A Security Champion program spreads awareness of best practices by influencing organizational behavior toward better habits to reduce overall security risk. Security champions solidify one of the integral roles within the development team and provide specific focus on the “securability” of a solution. Security Champions become the focal point within the development team, providing access to resources from Security Architecture and Application Security. Security Champions will be volunteers who act as embedded security representatives on their teams and are responsible for the following:

• Driving force within the team for security activities.
• Gaining security knowledge/skills and sharing with their team.
• Ensuring security best practices are followed by observing, reporting, and remediating security concerns.
• Building a strong relationship with the security team as the liaison between them and their team.

Threat modeling is invaluable if you can encourage a process that can keep up with development. Threat modeling identifies risks and gaps in the system from an attacker’s point of view. Usually, a team of subject matter experts review an application diagram, system architecture, or data flow diagram to facilitate building a better system In the most basic form, Adam Shostack has proposed that a threat model can be reduced to four basic questions:

1. What are we working on?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good job?

The output of this activity is recorded as a risk to the system. This is then measured for impact and probability to determine the severity. The severity is then used for prioritization within the overall software development process. Threat modeling is as art as science and thus benefits from an iterative methodology to holistically evaluate the proposed solution. Organizations can use the following steps to perform threat modeling exercises.

1. From a high level, identify any apparent risks that should be addressed.
2. Decompose the application/system into modular pieces. Identify risks at the modular level.
3. Use one or more risk assessment models to help identify other threat vectors (e.g., PASTA, STRIDE, etc.)
4. Identify active controls in the environment.? Do these mitigate any identified risks, or have additional gaps been identified? List remediation(s) and likelihood and impact ratings from the identified threats should the threat be realized.  These efforts can be quantified using standard risk metrics.
5. These steps are repeated until a comprehensive threat model has been produced.

Once we have security requirements, these requirements must become part of the system’s quality assurance plan.

Validating Security Requirements

Verification and validation can typically be thought of as “Did we build the right thing?” (validation) and “Did we build it correctly?” (Verification). These two succinct questions can be applied to security requirements in multiple ways:

• Do we have the right security requirements proposed for the system?
• Is the implementation required for the security requirement appropriate?

Vulnerability management: Every organization has some form of vulnerability management, whether it is a core-IT infrastructure or a holistic one, which includes IT, Applications, Software, products, network infrastructure, etc. The security requirements and subsequent security hardening that came should be validated in this phase. This phase mostly consists of summarizing the output of different scanning tools into more actionable insights. A list is included below of some of the areas that fit within this space:

• Triage and Remediation processes.
• Reduction in the number of false positives.
• Providing insights into teams for “What they are running?”
• Aspirations towards Engineering Excellence.
• Providing re-usable vetted patterns using known and continuously reviewed systems.

External scans and penetration tests: The organization can choose to create a vulnerability disclosure program to crowdsource the application security testing and, at the same time, validate the security controls if/when a certain vulnerability is reported. Outside of this, the organization can also have third-party penetration tests on the application by scoping the test for specific domains (network, application, access control, etc.), and thus using the information/output to further feed into the software development lifecycle.

Conclusion

Defining holistic security for software development is not just a policy-based approach but also a tag team and winning trust from peer teams across the company. When security becomes the motto and principle of the company, then and only then will teams feel empowered to inject relevant processes and technology to achieve certain security assurances. Secure engineering isn’t just a program but an organization-wide initiative where every team is equally responsible for achieving the goal of systemic organizational security as a process. Security must be embedded into each phase of the software development process. Failure to do so will produce weakened solutions.

The post Defining Security in Software: Frameworks, Compliance, and Best Practices appeared first on The New Stack.