We’ve Got You Covered

We are a fully automated API DevSecOps solution (this is enough for most people that would ask this question because that description implies what we do. We auto generate tests integrate into the CI/CD toolchain as well as the vulnerability management software to automatically take care of APIs across the SDLC). A team with Postman can only do 1/100 of what one person can do with our platform.

Do your engineers cover all the negative test cases as well as the nested-negative test cases?

Do your engineers use an authorization mechanism to check if the logged-in user has access to perform the requested action on the record in every function that uses an input from the client to access a record in the database? 

Are these in-house security engineers conducting their tests during the development phase of new APIs?

Regardless if you have DAST and SAST solutions do your engineers define all sensitive and personally identifiable information (PII) that your application stores and works with and review all API calls returning such information to see if these responses can be a security issue?

→ Excessive Data Exposure- Automatic tools usually can’t detect this type of vulnerability because it’s hard to differentiate between legitimate data returned from the API, and sensitive data that should not be returned without a deep understanding of the application.

During your API audit did the testers review your API endpoints against function-level authorization flaws, while keeping in mind the business logic of the application and groups hierarchy?

→ Broken Function Level Authorization- Implementing proper checks can be a confusing task, since modern applications can contain many types of roles or groups and complex user hierarchy (e.g., sub-users, users with more than one role).

Awesome, that is exactly why I am here. Every single security tool out there is basically a Negative security model, which require AI/ML solutions to analyze large swaths of data to make educated guesses on what type of activities should be denied. However, since you have such good security controls in place our positive security solution can define what the API was designed to do and only allow those calls to perform those predefined functions if they come from trusted sources. Therefore, we do not need to "guess" when we "know" that your APIs have the potential to be exploited. Aside from less accuracy, it can be difficult to understand exactly why the AI/ML identified something as a vulnerability especially when you consider that 70% of security teams report being overwhelmed by the constant false positives. So for it to notify you of something that needs to be fixed it's already too late, usually 200 days too late to be exact. Additionally, they must be constantly changed and updated to include the latest threats, but since our solution only permits what your specification allows we do not have to worry about that. The AI/ML we have is mainly for people with documentation that isn't as thorough as yours, as well as to validate that your design indeed does what it says. So it doesn't need to be overly complicated to "theoretically" offer value.

Most companies using GRPC API's internally still have REST API's that are open to the public. We can protect REST API's, which are the ones to protect anyways since these are public facing and are the most vulnerable.

We have an approach with Apigee today that is straightforward.  We would use this for the Proof of Value process.

https://docs.apigee.com/api-platform/tutorials/tutorial-create-spec

APIsec Standard $500 per Application or microservices App

APIsec Professional $1950 per Application or microservices App

One Application = One OAS / Swagger file

One microservices App = Multiple short OAS / Swagger files

We integrate with cloud GitHub, we can evaluate on an prem github to determine ease of integration.

All versions.

Yes, we look at sensitive data in the Swagger (today defined as PII) but this can be customized as needed to increase the scope of what is sensitive data (using Regex or patterns).

Yes, APIsec stores its own playbooks in a Github repo.

Yes.

We have a whitepaper that explains how the calculations are derived.

Custom playbooks are not modified upon upgrade, rather is a private copy of the playbook.

APIsec is built on top of API and nearly all aspects of the product is exposed as an API.

A scanning service is Opex versus a Penetration test can be capitalized.

APIsec has over 99 categories out of the box and our users are able to customize / build additional ones as needed.   

We cover far more than the OWASP Top 10, built from our understand of the top 1000 API breaches that have occur.

‍

Value is maximum when we have multiple roles and tenants. The ABAC and RBAC value comes shining then. Hence, we recommend having authentication to demonstrate the value of the product.

Limited number of tests can be executed without authentication, it can be used more for initial data gathering before customer meeting, but not for product demonstration.

Access control through authentication is one way to ensure data access, breaches are more about authenticated users having access to data that they should not. Take Facebooks API breach, Cambridge analytica had access to the “show as user” button, that was excessive data access. Salesforce allowed different tenants to query other tenants. This is a result of business logic checks not being completed. This is where APIsec shines.

Many of our customers run APIsec against their staging or nightly build environments. These tend to be development environments that usually don't have the per use pricing elements of production environments.

APIgee gateways if they are the first entry point to the API may have rate limiting enabled in which case you must set rate limits in the APIsec UI to ensure that APIgee does not see us as a BOT.

APIsec builds the definition of what is allowed and now allowed for the roles that you provide. Using a simple workflow you can validate these permissions that we have learned and then ensure the API behaves according to your desire for the roles versus what is coded. Access control validation is a feature our customers really appreciate.

Penetration test results are very sensitive and are accessible only to the tenant of APIsec that has appropriate permissions. APIsec is SOC2 compliant and takes steps to ensure that data within our platform is protected.

With only one endpoint you likely will only be able to apply Injection type of attack playbooks. Much better to identify a more complex API to allow APIsec to run broader range of attack scenarios.

Discovery of Shadow APIs is a serious problem. The way to uncover these is to look at communications traffic and uncover API traffic that is not assigned to a known API. This requires an inline deployment. We have purposefully focused on the problem of logic vulnerabilities that expose data that should not be exposed. The breaches today are occurring from lack of good protections where authenticated users are able to access and modify data that is not theirs resulting in large and significantly impacting breaches.

Today we don’t solve the discovery of shadow or rogue APIs rather we focus on the securing of APIs that are known and critical to your business.

1) We are looking for an API with different methods, read, write, modify.

2) We are looking for an API with different tenants / users to test ABAC

3) We are looking for an API with different roles to test RBAC

‍

1) For public APIs: use APIsec public cloud scanner.

2) For private on premise APIs: use the APIsec kuberetes or docker container (we will provide the instructions to instantiate)

3) For API on the customer cloud (GCP, Azure, AWS): we can use your credentials to setup the scanner container on your cloud.

Fedramp issued the following guidance: https://www.fedramp.gov/assets/resources/documents/CSP_Vulnerability_Scanning_Requirements.pdf

Which includes: "All web interfaces and services (or approved sampling percentage) must be scanned".

Most applications are exposed as WebApplications, MobileApplications and Services that are consumed through APIs. The API layer is the common building block for all of these applications. The major struggle with webapp and mobileapp scanning is they do not fully cover data access vulnerabilities (OWASP top 10) specially role and tenant data access control.  The only way to provide this scanning is running business logic validation at the API layer. Our customers eliminate unnecessary web/mobile app scan and instead use the API scan reports to show controls.   

Can we show you a API penetration report custom to your API?

Zaproxy is a free tool from OWASP. As the name suggests it acts as a proxy for API calls. Exercising the API is something that a human would do to go through the Zap proxy. Creating the scenarios to uncover vulnerabilities is something a human would do. Interpreting the results of the Zaproxy is something a human would do. As the config changes or the API changes a human would have to keep up with zaproxy to ensure full coverage.

Compare that to APIsec. We are fully automated. We keep up with the API (no human). We create the scenarios, called categories (no human), we run the tests (no human), we interpret the results (no human).

So if an organization has security experts that will be dedicated to keeping up with the API, researching the market to understand scenarios, and running these tests as fast as developers change or modify application code then that is the equivalent.

BTW: Did I mention Apisec is a 3rd proof of security with our automated Pen test reporting. Most organizations need a 3rd party proof of security. You can not get that with Zaproxy.