How to protect applications from third party services and APIs?

Author: Keshav Kamble

Application architecture is rapidly changing from monolithic virtual machine based to containerized micro-services based. Micro-services provide the perfect agility and DevOps freedom that IT managers need. Scaled-out distributed applications consume local as well as web based services by service commissioning and subscription models. Web based services and REST APIs for consumption of those services have been largely accepted as an ideal model by the development and security operations community.

However, there are multiple unanswered security issues where solutions are still being sought. In some of the larger discussions, attention has been drawn to service decommissioning. A potential security issue that remains largely unanswered. As soon as a service subscription expires or services are disconnected, it is expected that the service provider would stop interacting with your applications. But that is often not the case. In some deployments, as discussed, the service was decommissioned but the service provider continued to pull and push data from the applications. All of this went unnoticed due to a disconnect between application and network security personnel. The existing pin-holes or policies in network security continued to allow the interaction in both directions.

This usage model is also exposed due to API security vulnerabilities. The services and APIs security are largely driven by user authentication and data encryption only. These APIs and API based services require additional security scrutiny before integration by working closely with the service provider. Unfortunately, it slows down the development process but any upgrades in the service APIs add burden on development and security operations.

How do you solve these two crucial problems with third party services and APIs?

Thoughts

Planning of such third party services cuts across both development and CISO organizations. Unilateral decision making could pose big security issues. There has to be consensus on how and when the service commissioning or consumption starts and how and when it stops. Proper clean up procedures need to in place and automated.

If you think slightly technically on the security problem with third party services, it boils down to which application resources e.g. control and data sockets are opened by APIs and what data gets exchanged between your application and the web based services. As long as you have tight and deterministic control on those, your applications are completely secure from those APIs and the services. That is where the concept of pico-segmentation helps you solve the problem in a manner where one-touch segmentation provides you control over the type of services consumed along with the start time and stop time. This method provides you following types of controls:

  • A method of deterministic application security and segmentation.
  • Security and compliance of these services for the application and data protection is also under your control.
  • Complete visibility into the APIs, data exchanges and level of encryption used by the APIs.
  • Encryption, compliance (HIPAA, PCI, FedRamp, GDPR etc.) on the interaction.
  • In-depth visibility into the service provider application interfaces.

The pico-segmentation approach provides micro-policies for precise opening for APIs to interact with third party services without allowing the APIs to expose vulnerabilities. It also provides security from any penetrations from outside into these APIs and into your application eco-system. Moreover, these micro-policies are programmed for time of opening and closing. Therefore, just by configuring the times, you can commission or decommission the services. After the micro-policy expires, no outside third party services can connect or talk to your application. Every such attempt would be intercepted, mitigated by pico-segmentation logic along with reporting the source of such attempts.

The pico-segmentation is largely automatic but has programmability as well. Deployment is easy and can be deployed via DevOps automation tools e.g. Puppet, Chef, CloudFoundary etc.

My fellow Security Ops friends, more power to you!

Comments are closed.