Cloud-native application security involves balancing contradictory requirements: the benefits of cloud services in accelerating development, while at the same time handling security in an adverse environment where there are more attack surfaces and opportunities for data breaches. Today, tools exist that focus specifically on the security and vulnerability posture of cloud workloads. Container and configuration vulnerabilities are identified, and enforcement policies are enacted to protect the workloads if these are operating with such vulnerabilities.

Unfortunately, many security tools do not address the vulnerabilities of APIs. Cloud-native applications expose many internal API services and developers are increasingly using external API services for their applications. Both internal and external API use expose the workload to new vulnerabilities; more strongly, workload security and API security are really two sides to the same coin. 

Most security solutions adopt a negative security model, whereby manual rules and manual tuning need to be done in order to detect attacks, many times after they hit our systems.  With thousands of APIs written every day, this model has reached his limits. Its time to move to a positive security model, and start worrying about security from design time when potential vulnerabilities are easier to catch and address.

This talk specifically focuses on the security problems and vulnerabilities exposed through APIs. Questions we address include:

• What does a developer know about a service before using it?
• Does a poorly defined interface expose API service vulnerabilities?
• Does the service perform well to begin with?
• What is a positive and a negative API security model and can we leverage this?
• How does the developer get/maintain an access token?
• Do API specs show critical use cases and dependencies?
• Can the security impact of an external API service be estimated and managed?
• Do the APIs violate the OWASP API top 10?
• How can we test against the OWASP API top 10?
• Can PII be shared with such services?

  
  

We show how Cisco and 42Crunch combined solutions address both sides of the security coin: container workload and API security and we present actual issues with a live demonstration.