APPSec/API Security Summit hosted virtually by Techstrong Group. The event touched on chats, a beautiful usher-in intro by Techstrong Group CEO & President, Alan Shimel, keynote speeches and teachings that captured the following areas:

• 5 top risks to focus on your API Security delivered by Larry Maccherone
• Do This, Not That - Appsec/API Security delivered by Mike Rothman
• 5G is a DISH Best Served Reliably delivered by Brian Mengwasser and Aaron Rinehart
• Software Supply Chain - The Missing Links delivered by John Willis
• API Attack Protection, Don’t overlook your #1 Attack Vector delivered by Bret Settle
• What Are the Metrics That Matter in Appsec delivered by Andi Allis
• Black and Blue: Attacker’s and Defender’s View Point on API Vulnerabilities delivered by Matt Tesauro
• API Myth Busters: Five Security Myths Keeping you at Risks delivered by Nick Rago
• Security Testing at Scale delivered by Caroline Wong
• 3 keys to Continuous API Security delivered by Mitch Ashley

Security principles call us to a duty to achieve maximized cyber risk reduction with available time and money and see every decision as a forecast that yields futuristic impacts. Forecasting our choices will have better outcomes than alternatives.

The value of mitigations of risks should center on the risk addressed, the efficacy of a mitigation against a particular risk and the cost of mitigation.

API RISKS AND MITIGATION TOOLS

• Poor authentication design/technology which can be mitigated through threat modelling.
• Access control logic flaws, can be discovered through Penetration testing.
• Known vulnerabilities w/ available patch and/or WAF signatures. This can be mitigated by carrying out SCA (Software Composition Analysis) and setting up WAF(Web Application Firewalls).
• Zero days in components(SQL) which can be mitigated by carrying out RASP(Runtime Application Security Protection).
• Vulnerabilities in custom code can be mitigated by employing SAST(Static Application Security Testing) or IAST(Dynamic Application Security Testing).
• No/poor encryption can be found through performing DAST(Dynamic Application Security Testing).
• Shadow APIs can be mitigated by setting up Cloud WAAP(Web Application and API Protection).
• DDos attacks can mitigated by putting in place Dedicated API Security Tools.
• Overuse by legitimate users can be checked through enabling API Gateways.

Looking into the software architecture of today, Applications are driven by Microservices, have become faster and accelerated by DevOps culture and are also built and deployed by containers and Cloud platforms. On the other hand, this complexity has broadened the attack surface, attackers enumerate these APIs through scanning of swagger files, monitoring of network traffic as they employ a range of tools and technologies to exploit them.

OWASP API Top 10 Attacks

• Broken Object Level Authorization.
• Broken Authentication
• Excessive Data Exposure
• Lack of Resources & Rate Limiting
• Missing Function Level Authorization
• Mass Assignment
• Security Misconfiguration
• Injection
• Improper Assets Management
• Insufficient Logging and Monitoring

Though not all sufficient, traditional defences are effective in mitigating API attacks, using WAFs and API Gateways to manage security services and more importantly, having an in-depth knowledge of our threat landscape and attack surface. Employ out of band traffic together with active control integration to monitor all APIs in order to discover and block attacks. There is a need for security experts to collaborate with developers and enable them to understand the how and why fixing API security is quintessential.

Bottom Line Summary: five Do’s for API Security

• Visibility
• Sophisticated detection
• Out of band monitoring
• Collaboration with developers
• Runtime monitoring

APIs have experienced a spike in growth which has made it universal since the modern day software applications now make use of APIs. On another scale, APIs are becoming a huge attack vector since API protection is often overlooked. It was projected that by the end of 2022, API attacks will become the most-frequent attack vector, causing data breaches for enterprise web applications (Gartner).

API adoption brings many advantages - ease of integration, multi-use components, better automation, etc. and has become so vulnerable due to lack of visibility & awareness, sophisticated and multi-step techniques, poor accountability for acceptable API usage and its complex bot-based attacks. Posing potential risks in the areas of unauthorised access, improper information disclosure, functionality abuse, denial of service, security misconfigurations, etc.

Considerations when defending APIs

• To identify API attacks in real-time, you should know when your APIs are under attack.
• To block attacks before any damage is done, you should have managed to defend your app.
• To gain detailed insight of any attack, you should understand the motivation or the intention of the attacker.
• To understand the API attack surface, you should understand what is really out of the wild.
• To visualise API attack surface risk, you should know which API presents the greatest risk.
• To assess API compliance, you should know if your API meets your schema requirements.

How do you build the measure of a security program? Stresses on the importance of knowing the defences that work together to stop adversaries. The metrics exploration on Vulnerability management: (bad metrics)

• Review the current metric - challenge the definition
• What systems are not covered?
• What Vulnerabilities are not counted?
• What less relevant Vulnerabilities are counted?

Patching Vulnerabilities

• What is the average of open Vulnerabilities?
• How long have the current Vulnerabilities remain unpatched?

The best ways to improve metrics are to explore ways to improve this metric as well as other ways to apply them to other aspects of our security program.

New metric that might be considered in Vulnerability management Challenge the definition - the goal is to find definitions that matter differently based on their level of criticality. Patch with SLA measurement - Critical (7 days), High(30 Days), Medium(90 days), Low(180days) .

Risk management objectives

• Externally Driven - Use Cybersecurity as a competitive differentiator.
• Comply with a regulatory requirement, contractual obligations or industry standard.
• Achieve a defensible level of "due care".
• Achieve a comparable level of Cybersecurity to peers and/or competition.