INTERFACE by apidays 2023 - Secure Software Development Framework (SSDF) & API Security, Bill Jones, Softrams

INTERFACE by apidays 2023
APIs for a “Smart” economy. Embedding AI to deliver Smart APIs and turn into an exponential organization
June 28 & 29, 2023

Secure Software Development Framework (SSDF) & API Security
Bill Jones, Security Practice Director at Softrams

------

Check out our conferences at https://www.apidays.global/

Do you want to sponsor or talk at one of our conferences?
https://apidays.typeform.com/to/ILJeAaV8

Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io

Explore the API ecosystem with the API Landscape:
https://apilandscape.apiscene.io/

Transcript

1. SSDF & API Security Presentation Prepared by Bill Jones Softrams - Security Practice
3. AGENDA • What is SSDF? • Practices – In a Nutshell • Why does it matter? • What can we do? • API Security Impact? • Most Importantly
4. What is the SSDF? • Secure Software Development Framework – Recommendations for Mitigating the Risk of Software Vulnerabilities. *(In the Development Environment) • When we think about API security often, we think about testing the APIs with application penetration and other static/dynamic testing techniques and much more. • We need to shift [insert direction] with our focus and apply practices with policies using the SSDF. • Say Hello to the NIST 800-218.
5. How I View Practices? NIST PROVIDES PRACTICE AREAS AND EXPECTS ORGANIZATIONS TO USE THEM TO BUILD OUT POLICY THAT WORKS BEST FOR THE ORGANIZATION. PRACTICES ARE BROKEN OUT AS THE MAIN OVERARCHING CATEGORY FOR WHAT IS COVERED UNDERNEATH IT, LIKE AN UMBRELLA. THE DOCUMENTS ARE ORGANIC AND NEED TO BE UPDATED OVER TIME AS PROCESSES CHANGE WITHIN THE POLICY AREAS OR FRAMEWORK.
6. Practices – Not API Security Specific Prepare the Organization (PO): Ensure that the organization’s people, processes, and technology are prepared to perform secure software development at the organization level and, in some cases, for individual development groups or projects. Protect the Software (PS): Protect all components of the software from tampering and unauthorized access. Produce Well-Secured Software (PW): Produce well-secured software with minimal security vulnerabilities in its releases. Respond to Vulnerabilities (RV): Identify residual vulnerabilities in software releases and respond appropriately to address those vulnerabilities and prevent similar vulnerabilities from occurring in the future.
7. • Practice Data At A Glance Practices Tasks Notional Implementation Examples Define Security Requirements for Software Development (PO. 1) Identify and document all security requirements for the organization’s software development infrastructure and process, and maintain the requirements over time. Educate affected individuals on impending changes to requirements. (Ongoing Updates) Protect All Forms of Code from Unauthorized Access and Tampering (PS. 1) Specify which tools or tool types must or should be included in each toolchain to mitigate identified risks, as well as how the toolchain components are to be integrated with each other. Use version control features of the repository to track all changes made to the code with accountability to the individual account. Design Software to Meet Security Requirements and Mitigate Security Risks (PW. 1) Use forms of risk modeling – such as threat modeling, attack modeling, or attack surface mapping – to help assess the security risk for the software. Review vulnerability reports and statistics for previous software to inform the security risk assessment. Identify and Confirm Vulnerabilities on an Ongoing Basis (RV. 1) Gather information from software acquirers, users, and public sources on potential vulnerabilities in the software and third-party components that the software uses, and investigate all credible reports. Use threat intelligence sources to better understand how vulnerabilities in general are being exploited.
8. Why does it matter? Communication! Your organization will be able to supply your SSDF implementation to external entities and build trust, your API may receive more consideration within the industry sector you’re targeting. Most importantly again, building trust within your software! Secured from the start following policies and practices to avoid potential data leaks (APIs love to leak data)! While the SSDF is high-level, your adaptation of the example practices will allow you to define what works best for your organization. There is no one size fits all! With this freedom to adapt your policies to meet defined practices, you’ve begun to create more secure APIs (software too). For APIs you’ll want to focus on modular code that has been hardened and follows defined policies for updating.
9. What can we do? Communication! Your organization will be able to supply your SSDF implementation to external entities and build trust, your API may receive more consideration within the industry sector you’re targeting. Regarding API security many of the implementation examples will help ensure all areas are covered to develop secure interfaces from the get-go. Implement the SSDF and begin training your organization on the importance of defining implementations via tasks which relate to a practice area for secure development.
10. API Security Impact NIST 800-218 v1.1 isn’t the end all be all but it is a starting point to ensuring mature development standards are maintained within your organization. TRUST is built by being able to attest to your defined policies (and yes artifacts will likely be required). SECURED from the get-go by enforcing SSDF policies within your organization. TRAINING is a huge part in the success of any new imitative and the SSDF implementations should include continuous training activities.
11. Most Importantly In addition to risk, factors such as cost, feasibility, and applicability should be considered when deciding which SSDF practices to use and how much time and resources to devote to each practice.