The document discusses security best practices for APIs and containers. It recommends establishing guardrails for authentication, data lifecycle, integration, deployment, changes, and testing. Guidelines should allow flexibility in tools and methods while ensuring consistency. Security must be integrated throughout the development process, and anomalies should be monitored to detect issues. While new technologies enable agility, responsibility is needed to ensure security is not compromised.

1. #RSAC
SESSION ID:
API Security:
Assume Possible Interference
______ASD-R11___
Cybersecurity Leader & Advisor
Julie Tsai

2. #RSAC
A Protocol?
2
A FRAMEWORK FOR INTERACTION, EXCHANGING DATA AND SERVICES
APIs - Application Programming Interfaces:
How the 2019 World Wide Web Communicates

3. #RSAC
Like Hilde
3
WHO
WHAT
WHERE
WHEN
WHY
HOW
Be a Journalist to Secure APIs

4. #RSAC
4
WHO
WHAT
WHERE
WHEN
WHY
HOW
Specifically…
=> aka AuthN (Authentication) via AuthID
=> aka AuthZ (Authorization) via OAuth
=> Are Sessions, Keys, Tokens Stored?
=> Does Access and Data Expire?
=> Our Purpose for Accessing This Data
Least-Privilege, Explicit Trust, Implicit
Deny

5. #RSAC
360-View on Exploitability
5
Do the services interact in a way that creates the least astonishment?
Is the lifecycle and travel path of the data known?
Is the data forgotten after use? Can this be proven?
What if authorization models for different services get mixed? To
different users, with different privileges?

6. #RSAC
6
PHOTO TITLE
Wait, didn’t containers and service isolation solve this?

7. #RSAC
B U T A P I I S J U S T
T H E B E G I N N I N G …
7
There’s
still some
stuff
beneath the hood

8. #RSAC
8
L 1 . P H Y S I C A L
L 2 . D A T A L I N K
L 3 . N E T W O R K
L 4 . T R A N S P O R T
L 5 . S E S S I O N
L 6 . P R E S E N T A T I O N
L 7 . A P P L I C A T I O N
8 ? E C O N O M I C
9 ? P O L I T I C A L
1 0 ? R E L I G I O U S
Defense-in-Depth Matters
S E C U R I T Y I S F U L L - S T A C K O S I P R O B L E M - L A Y E R S 1 -
7 , 8 , 9 … 1 0

9. #RSAC
9
Defense-in-Depth Matters
What could happen?!
L 1 . P H Y S I C A L - I N T R U D E R P L U G S I N C O N S O L E I R L
L 2 . D A T A L I N K - P I N E A P P L E W I F I
L 3 . N E T W O R K - C O M P R O M I S E D T R U S T E D I P
L 4 . T R A N S P O R T - U D P D N S R E F L E C T I O N
L 5 . S E S S I O N - C L E A R T E X T C O M M S C O M P R O M I S E D
L 6 . P R E S E N T A T I O N - S S L W E A K C I P H E R / M I T M
L 7 . A P P - C O D E A L L O W S W R O N G A C C E S S
L 8 . E C O N O M I C - U N D E R R E S O U R C E D
L 9 . P O L I T I C A L - M I S A L I G N M E N T S
L 1 0 . R E L I G I O U S - L E A P S O F F A I T H + F U D

10. S H I F T L E F T & S H I F T R I G H T
Upstream Secure Containers &
End-State Monitoring

11. #RSAC
Containers and Chroot Jails:
Classic Tune, New Words
11
Dedicated namespaces and resources. Process isolation. Ephemerality.
But shared kernel.
Example threat model - https://www.twistlock.com/2016/12/06/protecting-
containerized-apps/: Malicious container attacks underlying OS or other containers

12. #RSAC
12
(Skipping the pets -
you know why you
shouldn’t make pets)
Container SRC as Workhorses, Not Just Cattle

13. #RSAC
13
Workhorse & Cattle Lifecycle
1. Born
Instance created
2. Eat/Sleep
Powered but no
new changes to
instance, or
updates to image
3. Expire
When deprecated
or
compromised/vuln
erable, instance
terminated with
no feedback
Container Lifecycle: Cattle v. Workhorse
1. Born
Instance created
2. Trained
Secured
configs/images
3. Updated
Config & Repos
continuously
updated
4. Corral
Use cgroups to
authorize. System
calls whitelists.
5. Maintain
or Expire
Maintain by
chef/puppet/cfeng
ine/ansible/salt
etc. Or expire.

14. #RSAC
Container SRC as Workhorses, not Just Cattle
(Skipping the pets - you know why you shouldn’t make pets)
14
Container images must be maintained, not just fire and forget or expiraton.
Expiring the compromised container or service (i.e. shooting the cattle) only solves once. But the
herd needs to be inoculated – to evolve – beyond issues to prevent recurrence. Or, think of baking
a cake vs. stir-frying*.
* C R E D I T ~ D A L V E S .
—> So what? Well, upstream learned remediation drives down Rate of Defect Recurrence! In
practical terms, you note and track the vuln, and incorporate the fix in the Dockerfile (or source
code or secure patch repo) in source-controlled, change-managed config. So it scales beyond that
one image.
Example https://engineering.salesforce.com/open-sourcing-dockerfile-image-update-
6400121c1a75

15. #RSAC
Workhorse Communication: Service Mesh
15
From https://dotnetvibes.com/2018/07/23/sidecar-design-pattern-in-your-microservices-ecosystem/

16. #RSAC
Less Is More in Containers
W H A T ’ S A H A R D E N E D C O N T A I N E R ?
16
L E T ’ S W A L K T H R O U G H T H I S :
1. strip down packages, especially easily exploitable ones useful to
hackers (telnet, ftp, make, gdb, nmap, strace, legacy daemons)
2. minimize host/network services and daemons
3. ssh and account enforcement
4. logs
5. key file/config alerting
6. vulns + patching scanning
7. and… scrap anything in there you don’t need.

17. #RSAC
Monitoring the End-State
Abuse, Anomalies, and Access
17
What’s Normal? Anomalies in conjunction tell the story.
We don’t know - and can’t comprehensively predict - what we don’t know. Root
cause and security incidents don’t present themselves as such upfront.
What to do?
Flag + Correlate for simple indicators of what shouldn’t be happening. i.e.
Resources volume or ways that shouldn’t be used. Things that shouldn’t be
accessed. Non-cyclical transaction trends.

18. #RSAC
Post-Flight Gut-Check DevSecOps
A K A A R E W E S E C - I N G A N D O P S - I N G W I T H O U R D E V - I N G ?
18
1. Security, Compliance, Privacy
When are your S-C-P pros leveraged in the process for the product? Customer development, inception
or design, dev or testing, alpha – or when an “event” happens?
2. Uptime and Performance
Do we truly know it better than our end-users?
3. Scale Complexity and Change
Is there the necessary speed in deployments/change across all of your teams?
Can you accommodate (or tolerate) diverse deployment & build methods across teams?
Do you get the same level of visibility, health, and security from each of them?

19. T H E R I G H T A M O U N T O F S T R U C T U R E
Guidelines & Guardrails

20. #RSAC
20
The Right Amount of Structure
The Right Amount of Structure - a Score

21. #RSAC
Where To Use Guardrails 1
21
1. AuthN/AuthZ
(AutheNtication/AuthoriZation)

22. #RSAC
Where To Use Guardrails 2
22
1. AuthN/AuthZ
2. Lifecycle of the Data

23. #RSAC
Where To Use Guardrails 3
23
1. AuthN/AuthZ
2. Lifecycle of the Data
3. Build Integration

24. #RSAC
Where To Use Guardrails 4
24
1. AuthN/AuthZ
2. Lifecycle of the Data
3. Build Integration
4. Production Deployment

25. #RSAC
Where To Use Guardrails 5
25
1. AuthN/AuthZ
2. Lifecycle of the Data
3. Build Integration
4. Production Deployment
5. Change - Code, Configs, Dependencies

26. #RSAC
Where To Use Guardrails 6
26
1. AuthN/AuthZ
2. Lifecycle of the Data
3. Build Integration
4. Production Deployment
5. Change - Code, Configs, Dependencies
6. Regression Test - Catch the Ripple

27. #RSAC
Where To Use Guardrails 7
27
1. AuthN/AuthZ
2. Lifecycle of the Data
3. Build Integration
4. Production Deployment
5. Change - Code, Configs, Dependencies
6. Regression Test - Catch the Ripple
7. Security & Compliance Requirements

28. #RSAC
Where To Use Guidelines 1
… W I T H I N T E R N A L C O N S I S T E N C Y I N R E L E V A N T S C O P E
28
1. Develop/Build in the OS/Language You Will

29. #RSAC
Where To Use Guidelines 2
… W I T H I N T E R N A L C O N S I S T E N C Y I N R E L E V A N T S C O P E
29
1. Develop/Build in the OS/Language You Will
2. Use the Tools That Work for You, without Significantly
Hampering Others

30. #RSAC
Where To Use Guidelines 3
… W I T H I N T E R N A L C O N S I S T E N C Y I N R E L E V A N T S C O P E
30
1. Develop/Build in the OS/Language You Will
2. Use the Tools That Work for You, without Significantly
Hampering Others
3. Deployment Methods. CI/CD Innovation. Private or
Public Cloud. Bare Metal. Multi-cloud or Single.

31. #RSAC
Where To Use Guidelines 4
… W I T H I N T E R N A L C O N S I S T E N C Y I N R E L E V A N T S C O P E
31
1. Develop/Build in the OS/Language You Will
2. Use the Tools That Work for You, without Significantly
Hampering Others
3. Deployment Methods. CI/CD Innovation. Private or
Public Cloud. Bare Metal. Multi-cloud or Single.
4. How DevSecOps Manifests in Your Org

32. #RSAC
Where To Use Guidelines 5
… W I T H I N T E R N A L C O N S I S T E N C Y I N R E L E V A N T S C O P E
32
1. Develop/Build in the OS/Language You Will
2. Use the Tools That Work for You, without Significantly
Hampering Others
3. Deployment Methods. CI/CD Innovation. Private or Public
Cloud. Bare Metal. Multi-cloud or Single.
4. How DevSecOps Manifests in Your Org
5. Culture — Congruence of the Walk with the Talk

33. #RSAC
Are We There Yet?
33
From monolith to microservices…
Decoupling dependencies…
Agile, independent teams…
Continuous Deployment of epheremal containers…
Open, networked world…

34. #RSAC
Are We There Yet?
34
…with Great Power Comes Great Responsibility.

35. #RSAC
References & Image Credits
35