apidays LIVE New York 2021 - API-driven Regulations for Finance, Insurance, and Healthcare July 28 & 29, 2021 Why Software Teams Struggle with API Security Testing Scott Gerlach, Co-Founder & Chief Security Officer at StackHawk

1. Why Software Teams
Struggle with API Security Testing
and How to Make it Easier
Hint: None of the reasons are “Developers Don’t Care about Security”

2. $ whoami
Scott Gerlach
● CSO/Co-Founder StackHawk, Inc
● CISO @SendGrid - 3 years
● Sr. Security Arch @GoDaddy - 9 years
● Husband, Dad, Brewer, Golfer, tinkerer
● @sgerlach
● linkedin.com/in/scott-gerlach-kaakaww

3. API Security Problem Overview
API Security : How can I to go to there?
Static Code Analysis
● Noisy, often lacks Application Context
● Language Dependant (Don’t get me started on IDE support)
Dynamic Code Analysis
● Better at actual app and context, but still somewhat noisy
● Hard to use and many don’t support RestAPI, GraphQL
RASP, IAST, WAF
● Wait until someone/something else finds it… in Prod, and hopefully block it

4. Problem One:
Working Agreements Aren’t
Clear

5. Hey! I broke the crap out of your thing. Cool huh!

6. working agreement | [wur-king ə-ˈgrē-mənt ]
Definition Time
1. The purpose of a working agreement is to ensure the Agile Team shares
responsibility in defining expectations for how they will function together
and enhance their self-organization process
2. Working agreements can apply to services, and can even be documented.
3. You can certainly make a working agreement with the Security Team…
just saying

7. Functional Agreements:
● Rate Limiting?
● Standardized Errors?
Data Input:
● Validation?
● Encoding?
● Escaping?
Data Output:
● Validation?
● Encoding?
● Escaping?
● Paging?
Data Working Agreement
Functional Agreements:
● Back off routines?
Data Input:
● Validation?
● Encoding?
● Escaping?
Data Output:
● Validation?
● Encoding?
● Escaping?
Backend Team (API Team) Front End Team

8. Functional Agreements:
● Rate Limiting
● Standardized Errors
Data Input:
● Validation
● Encoding
● Escaping
Data Output:
● Validation
● Encoding
● Escaping
● Paging
Data Working Agreement
Functional Agreements:
● Back off routines
Data Input:
● Validation
● Encoding
● Escaping
Data Output:
● Validation
● Encoding
● Escaping
Backend Team (API Team) Front End Team
YES, THAT!

9. Problem Two:
Security Tools are Built for the
Security Team

10. Hey! I broke the crap out of your thing. Cool huh!
FIX ALL THE THINGS!
I think we’ve got a
SQL Injection here

11. Security Websters
CSRF: Cross Site Request Forgery
XSRF: Cross Site Request Forgery
Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted
actions on a web application in which they’re currently authenticated. With a little help of
social engineering (such as sending a link via email or chat), an attacker may trick the users of
a web application into executing actions of the attacker’s choosing. If the victim is a normal
user, a successful CSRF attack can force the user to perform state changing requests like
transferring funds, changing their email address, and so forth.
We couldn’t decide which one to use, so we use both interchangeably. Isn’t that cool? Anyway, I
hope some of this text helps you understand what this means because we wrote a lot of it.

12. Let’s Teach Them AppSec
If they know how attackers think, they’ll be able to test like an attacker - Hack Yourself!
● Here’s 11ty Billion new Acronyms to learn
● Also, let’s talk about risk
● But wait before that, do you know the Internet is a bad
place?
● If you have sent any of your Devs to a Security Training
program, who usually gets selected?

13. “We Need to Model Out a Price Increase”
Have you ever seen the FP&A team teach the basics of accounting to the Exec Team

14. Lastly, and worst of all,
they suffer from….

15. Problem Three:
The Production Bias

16. Examining the Production-Bias: People
Primary Value: These groups are very focused on the “finding” of vulnerabilities/security bugs. MOAR
findings = MOAR better.
The Security Team Pen Tester
Production is where they know the app the best Production is their only point of access
Repercussions…
● More focused on the numbers of things found, than finding and fixing the right things
● Inefficient — the “finders” are not the “fixers”
● Reinforces an adversarial relationship — “Hey look, I broke your stuff”
*Assuming you have a security team

17. PLAN
M
ONITOR
CODE
BUILD
T
E
S
T
RELEASE
DEPLOY
OPERATE
Security is either
a blocker
or “playing catch up”
DEV OPS
Examining the Production-Bias: Timing

18. Example RestAPI - Pants`R’ Us
GET /rest/api/v1/listPants
Returns list of pantIds
GET /rest/api/v1/{pantId}/details
Returns details about a pair of pants, size, color, stock

19. Example RestAPI - Pants`R’ Us
GET /rest/api/v1/listPants
Returns list of pantIds
GET /rest/api/v1/{pantId}/details
Returns details about a pair of pants, size, color, stock
HUNDREDS OF STYLES AND SIZES WAITING FOR YOU!

20. Example RestAPI - Pants`R’ Us
SO MANY PANTS!

21. Also, there’s a major problem with appsec tools that
favor running in production…
THE BUGS ARE
IN PRODUCTION.
Illustration by Stories by Freepik

22. I wouldn’t want a Junior Developer
making security decisions
Trust Issues

23. I wouldn’t want to put a new hire
Developer in the position of
making an uninformed risk
decision
Trust and Support
-Scott Gerlach

24. The Chase to Perfection
● Find 11ty Billion issues -> We have to fix all of these!
● Why? What is the actual risk in the context of the business?
● What if your QA filled 1,000 tickets for bugs that are
unlikely to degrade user experience?
“I’ve never had a satisfying conversation on
why a security issue is ever more important
than a feature. Ever.” - Product VP

25. If You Don’t Have a Security Team
● Where do I start?
● OMG, forget it. I have other stuff to do.
● Wait, maybe the DevOps team can handle it

26. There are Good AppSec Dev Tools Out There
Developer native tools (in context, how they work)
● Snyk
● Fossa
● npm audit
● GitHub (package inspection, PR Bot)
● OWASP Dependency Check

27. Context of the Code is lacking
Inefficient
Time Consuming
Expensive
Context of the App and how it works
Context of Business Risk
Examining the Production-Bias: Context

28. Wrong Team Wrong Time
Wrong Context

29. Getting Started:
The Right Way

30. How Test-Driven
Security
Should Work
When a team writes code, they know the syntax
is wrong when it won’t compile.
When a team merges code they know there is a
problem when it doesn’t merge.
When a team runs unit tests, they know the
code is wrong when it fails the unit test.
When a team runs integration tests, they
know the code is wrong when it doesn’t work as
designed.
When a team introduces a
vulnerability, they know when it
fails a security test.

31. PLAN
M
ONITOR
CODE
BUILD
T
E
S
T
RELEASE
DEPLOY
OPERATE
DEV OPS
Right Time: Pre-Production
Security Tests
Security Tests
Instrumenting Security Tests into CI/CD
gives engineers immediate feedback.
Adding the ability to test locally allows for
quick iteration in the fix-test loop if a new
bug is identified.
Local Dev & CI/CD

32. ● Set up working agreements across
teams/apps/departments
● Create Standards documentation automatically
(OpenAPI/Introspection)
● Seed the database! Test in Pre-Prod!
● Understand these two things deeply
○ Object Level Authorization (Tenancy Filtering)
○ Function Level Authorization
Cover Your Bases

34. ● Engage a project team and their pipeline
● Choose AN app or service to start
● Choose a technology (SCA, DAST)
● Iterate and expand
Just Start!

35. Thanks!
scott.gerlach@stackhawk.com @sgerlach https://stackhawk.com