Time to Think Beyond Access – 3 Lessons from Capital One Data Breach

Last week the Internet was a buzz with the information related to Capital One Data Breach. Around 30 GB of data was breached. It is estimated to consist of around 140,000 social security numbers (SSN); 80,000 bank account numbers of US consumers and around 1 million social insurance numbers (SIN) for Canadian credit card consumers.


As per the information published and inferred by a number of news outlets, the attacker was able to exploit a mis-configuration in Web Application Firewall (WAF) which allowed the attacker to assume the role of the WAF in order to list as well as copy the contents of AWS S3 buckets.

3 Lessons from this Breach

1.    AWS S3 bucket in this breach was not publicly exposed. So, contrary to the popular belief, a major data breach is not limited to AWS S3 buckets that are mis-configured and publicly exposed. Think beyond security tools that are doing configuration checks.

2.    The data was exfiltrated in this breach using the Sync Command that internally uses APIs. Modern Internet applications are driven by APIs and as seen in this breach today’s Web Application Firewall (WAF) is not the best tool for securing APIs. Think beyond authentication & authorization as today’s threats are ONLY about Data.

3.    This data breach was reported to Capital One via their responsible disclosure email. Capital One did not have the right set of tools to provide visibility and discovery. Think beyond reactive response and look towards the right set of tools that provide visibility and discovery which will lead to a better understanding of your Data movement.

Learn More

Check out this 44 seconds video about the data breach and how ArecaBay can protect your data.

Check out our detailed 6 minutes video demonstrating ArecaBay capabilities to detect and prevent un-authorized AWS S3 downloads

Traditionally and even today, a number of us tie Security to Access Control. Access control is needed but this breach is a great example to think beyond and to look at Data and the interface to that data i.e. APIs as a means to secure the Data. Please comment below and let me know what you think. Also, please follow me on Twitter @ravi_balupari and let’s talk some more.

#apisecurity #capitalonebreach #databreach #cybersecurity #cloudsecurity #apidatasecurity

Microservices Needs API Security, but API Security Should Not Depend on Microservices

APIs are the interconnect protocol in microservices architectures, and for this reason, API Security is an essential component of microservices security, besides, of course, the service platform security and container security itself.

However, microservices architectures present opportunities and challenges for API Security implementation: 


  1. API calls between services usually go through proxies and/or other virtual components that are under the control of DevOps. Therefore, API security functions can be attached to these components without modification of infrastructure components.

  2. Microservices tend to be a group of highly distributed and ephemeral services. This means that the conventional hair-pinning and traffic redirection through a security gateway will not work for a vast majority of deployments. 


As a result, most API security services for microservices are delivered as add-ons and plug-ins to existing microservices infrastructure components. Now, while this can be effective if the entire Service Mesh has been converted to microservices, the reality is that microservices based API security isn’t a viable solution in a hybrid, multi-cloud, and highly distributed environment. 

Gartner points out that API security should comprise of a continuous three-step iterative process. They go on to describe them as Discover, Monitor and Secure. The order highlights the steps in which a successful API security implementation should naturally follow.


An organization must first discover the APIs that are currently in use because just like Shadow IT, Shadow APIs can be a potential data breach vector; and furthermore, discovery tools should not be limited by the application architecture. Hence a microservices-centric tool will not be an effective discovery tool for hybrid environments – also known as the large majority of enterprise deployments. 



Hybrid environments also need a monitoring solution that works across different architecture models, and the monitoring itself should not enforce the adoption of any particular model. Also, monitoring should be a zero-impact to observed systems.


Finally, when it comes to securing APIs, one needs a solution that ensures that all API calls, without exception, can be secured in an end-to-end manner. API security implementation is only incomplete all API calls passing through a particular set of network components can be effectively secured.

In summary, it is not a question if API security should be part of a microservices architecture – it definitely should. However, the microservices API security should be considered as part of the broader Service Mesh API security solution, encompassing all enterprise applications and components, and not as a means to an end.

ArecaBay provides the only API security solution that integrates private, public and distributed application environments and provides a single point of control to manage API security at any scale. Furthermore, ArecaBay "uniquely" continuously observe APIs at the object-level {payload} to ensure that even data exposed by-design is not leaking private data.

Learn more about our Dynamic API Risk Trackers (DART) And API DLP 

Advanced Microgateway Functions in a Service Mesh without Adding Gateways

A recent Gartner report (ID G00373257) defines elegantly a general Service Mesh architecture and how a set of microgateways are needed for East/West or lateral API mediation (Figure 1).

Figure 1. (source Gartner Report)

A few things worth highlighting in this architecture:  

  1. The definition of Service Mesh isn’t limited to containerized microservices. It contains Miniservices, monolithic app Macroservices, and Macroservices based on a legacy app adapter. This definition fits most, if not all, existing enterprise applications environments. 

  2. North-south mediation is separated from east-west mediation. This seemingly obvious separation is important in truly defining what a microgateway function should be. Many API Gateway products simply port their implementation to a microservice architecture (usually using containers) and then self-proclaim to be a “microgateway.” In light of this architecture, it is still performing a North-south mediation function, albeit microservices themselves. 

  3. The microgateway layer is a functional layer. This means that actual network traffic or API calls in the wire do not necessarily have to pass through one additional gateway/proxy, as long as a network component inline of the API call flow performs the Monitoring/Security/Traffic Management functions sufficiently. 

It is the point number 3 that we would like to expand further. In the physical world, if we want to enhance monitoring/security/traffic control of flows into a building, the best approach may not be to add yet another gate. Perhaps adding a set of video surveillance systems with proper alarming in combination with automatic lock-down to existing doors would be a lighter-weight, non-intrusive, more effective way.

In fact, in most service meshes today, there are built-in “gateways” through which inter-service API calls flow. Figure 2 shows a few of these “gateways”:

  • Some enterprises use API Gateways to mediate API calls. They do provide Monitoring/Security/Traffic Management functions to the API calls that they are front-ending, but naturally, they can only manage API calls that go through them – but not all service API calls are leveraging an API gateway. It is hard to find a real service mesh in which the majority of API calls are mediated by an API Gateway these days. Moreover, some of the functions are relatively limited. For example, most traffic management is about rate limiting. 

  • Load Balancers and proxies, including sidecar proxies implemented in a container system, are naturally gateways. They are not purpose-built API gateways and hence lack many of the API mediation functionalities.  

  • A message bus cannot be considered a gateway in the strictest sense. However, API calls do flow through them in a message-oriented implementation. 

  • Enterprise Id Providers can be considered logical gateways as they are the “gatekeeper” of any API transaction. They control the generation, validation, authorization of tokens used to make API calls. 

Figure 2: Gateways in a Service Mesh

Now, the question becomes: what if we can build enough surveillance into the service mesh, then leverage existing gateways to perform the security policy functions in case of anomaly/attacks? After all, what is needed is not yet another gateway, but intelligence knowing what the user and API activities are and what might be anomalous about those activities. 

ArecaBay’s Network Engine is a better and frictionless approach to performing the microgateway functions without adding more network gateways. The Network Engine consists of two parts: 


  1. A collection of micro-sensors deployed into the service mesh infrastructure. They can be of the following types: 

    • A plug-in to Load Balancer Proxy 

    • A plug-in to API Gateway 

    • A plug-in to sidecar proxy 

    • A network tap (physical or virtual) 

    • A sidecar sniffer 

    • A consumer of the message bus 

    • An IdP callback function 

  2. A central correlation and policy enforcement function that takes API call data and performs advanced microgateway functions. The network of microsensors capable of filtering and capturing highly targeted API object level data enables advanced functions much beyond what point gateway products can provide. Here are a few examples(more examples are available in a whitepaper):

  • Monitoring

  1. API object level tracking allows us to provide a set of Dynamic API Risk Trackers that are able to detect, for example, out-of-range parameter input or access token/user mismatch.  

  2. Multi-point capturing enables API calls originating from a single front-end action be traced across services. 

  • Traffic Management

  1. As we can track cross-service calls at object level, we can track data movements that are otherwise permitted by the app implementation but are in violation of data locale rules (e.g. GDPR) 

  2. As a monolithic app is broken down into smaller microservices, sometimes a smaller number of front-end calls may result in an excessive number of backend calls. An advanced rate-limit policy can control cross-service call rates.  

  • Security

  1. Out-of-band actions do not require an “inline” device. For example, leveraging IdP callback, if a particular user is suspected of generating abnormal API calls, the user session can be invalidated, and the user be required to perform a “Step-up” authentication.  

  2. In-line actions are performed by leveraging various gateway plug-in microsensors.

In summary, a set of intelligent microsensors can enable advanced microgateway functions without having to add yet another inline gateway layer to the service mesh implementation. Such No-gateway approach is the most seamless and non-disruptive implementation of a service mesh microgateway. If interested, we will be delighted to demo to you.