Tag: API security

  • API Sprawl a Looming Threat to Digital Economy

    API Sprawl a Looming Threat to Digital Economy

    New estimates say the total number of public and private APIs in use is approaching a whopping 200 million. APIs are becoming increasingly crucial to the global digital economy. They are the backbone of many digital platforms and drive the composable enterprise model. But this ubiquity presents sprawl issues.

    F5 recently released a study that examines the conditions of the API economy at large. Authored by Rajesh Narayanan and Mike Wiley of F5, the paper, Continual API Sprawl: Challenges and Opportunities in an API Driven Economy, articulates the state of API sprawl and the conditions behind its arrival.

    According to Narayanan and Wiley, “If data is the new oil, then APIs will become the new plastic.” This looming reality will require a continuous approach to API management to avoid further polluting the digital ecosystem.

    Below, I’ll review the report’s main takeaways to see what has given rise to API sprawl and consider how IT leaders should respond.

    State of API Growth

    APIs have evolved as a standard mechanism for businesses and services to connect and share value. And, as more companies begin to rely on them, the API economy is becoming big business—83% of organizations today consider API integration a critical part of their business strategy, according to the 2020 Cloud Elements State of API Integration Report.

    There is a proliferation of API styles. Thousands of public productized APIs exist, but more private and partner APIs are in use. Technically speaking, APIs come in many different forms—they may be web-based, browser-based or embedded into devices. The report also identifies single-purpose APIs and those that aggregate multiple data providers.

    API use cases are pervasive, from hotel bookings to weather, stock tickers, transportation, IoT, DevOps workflows and many other areas. “API-powered apps have permeated every aspect of our lives,” said the report. Yet, typical market estimates are usually quite conservative when sizing up this market, said F5. According to F5’s aggressive calculations, we will be approaching 1.7 billion active APIs by 2030.

    APIs present a high value from startup use cases to enterprise applications. However, a downside is that this growth is leading to sprawl, said Narayanan and Wiley.

    API sprawl is the term used to describe both the exponentially large number of APIs being created and the physical spread of the distributed infrastructure locations where the APIs are deployed.

    Factors Driving API Sprawl

    Sheer growth. Sources predict the number of developers will grow to 45 million by 2030. SlashData also estimates that 30% of developers already use APIs. As the number of APIs on the market moves into the millions, managing growth poses a significant challenge, especially without proper governance and best practices.

    Lack of standards. “The lack of a common shared model contributes to API sprawl,” the report said. API design standards do exist, yet guidelines often leave room for nuances between services. Standards have also emerged around specific industries, like financial data exchange (FDX). While helpful for a single sector, this doesn’t advance multiple industries simultaneously. A lack of standardization leads to differing versioning approaches and integration challenges.

    New development approaches. Integration requirements are forcing many new APIs to unite disparate business apps. The microservices architecture trend is also adding to sprawl, as “APIs are both northbound to interfaces via microservices and horizontally between microservices.”

    Continuous software development. Continuous development, paired with the need to connect business units with bespoke requirements, could produce multiple versions of the same API. This quickly leads to maintenance difficulties, out-of-date documentation and broken clients. The report also cites rising data creation and “everything-as-a-service” trends as harbingers of an API sprawl.

    Various computing evolutions. New computing trends are also prompting a sprawl, says the report. Business units may be operating on different on-premises or cloud environments. When this hybrid situation occurs, APIs could get dispersed over many locations and become difficult to track. Specific connections may be created to cater to new environments like edge computing and IoT devices, further increasing sprawl.

    Problems With API Sprawl

    A digital economy reliant on APIs also relies on the underlying stability and availability of these services. Yet, “APIs have a shelf life and become unsupported if ignored by the developers,” the paper acknowledged. It could be hard to maintain service reliability for APIs sprawled across a distributed cloud. In addition to reliability issues, there are many other possible repercussions of an API sprawl.

    For one, management and operation at scale become difficult. Not all APIs are based on a specification, like OpenAPI. This means that API documentation may not be as streamlined and accessible, thus hurting discoverability and onboarding. “A simple means to connect these APIs may not be possible with conventional or legacy networking approaches,” the report added.

    As developers are top consumers of APIs, a sprawl could negatively impact their integration experience. Maintaining a swelling library of API dependencies can be cumbersome. Plus, APIs are prone to evolve and version over time and when endpoints are altered without advance notice, it leads to broken clients. Even small changes in API functionality can have a huge impact since all observable API behaviors will become relied upon, whether documented or not. (This is known as Hyrum’s Law).

    But the security ramifications of API sprawl are perhaps the most troubling. A whopping 91% of enterprises experienced an API security incident in 2020. Malicious API traffic also rose by a staggering 300% in mid-2021, Salt Labs found. Increased API use will undoubtedly cause more frequent attacks.

    “Unmanaged API sprawl is a security breach waiting to happen,” said the report. APIs typically adopt API keys for authentication and authorization, but this method is prone to misuse. Credentials are often exposed or misconfigured. Bad actors can use APIs to steal loads of data and computing power. As a result, sprawl is undermining trust in API connections and responses.

    Mitigating The Sprawl

    With the growth of the API economy slated to reach the billion mark in the next ten years, figuring out secure, stable inter-cluster communication will become more critical. According to F5, existing solutions (gateways, ingress controllers, service mesh and forward and reverse proxies) are not an adequate response.

    “We believe the solution should hence involve an intermediary (proxy) device focused on solving inter-cluster connectivity, security and integration challenges.” The writers call this solution API Gateway 2.0, which they describe as a bi-directional application-level proxy. The technology exists to implement such middleware and perhaps it could help companies address sprawl issues.

    Outside of Narayanan’s and Wiley’s recommendations, there are plenty of actions API owners can take to avoid adding to the sprawl. Here are a few:

    • Treat the API as a product
    • Improve developer experience
    • Use spec-driven development
    • Ensure up-to-date documentation and code libraries
    • Use consistent endpoint naming
    • Set clear guidelines for versioning and deprecation
    • Go beyond API keys with OAuth and OpenID Connect

    For more context, check out Continual API Sprawl: Challenges and Opportunities in an API Driven Economy for free without an email gate here.

  • GraphQL’s Greatest Strength is Also its Greatest Weakness

    GraphQL’s Greatest Strength is Also its Greatest Weakness

    Michael Scott: Why don’t I tell you what my greatest weaknesses are? I work too hard, I care too much and sometimes I can be too invested in my job.
    David Wallace: Okay. And your strengths?
    Michael Scott: Well, my weaknesses are actually strengths.
    David Wallace: Oh. Yes. Very good.

    GraphQL is a new query language that offers a simple way to interact with structured data. The best thing about GraphQL’s design is its convenient data fetching process which enables the requesting party to collect limitless data and perform multiple actions, all with a single API call. This interaction method makes it super useful and very easy to use. However, from a security perspective, its greatest strength could also be its greatest weakness.

    I recently met with Elad Koren, chief product officer, Salt Security, to understand the nuances of GraphQL security. According to Koren, GraphQL affords better usability than REST APIs, yet its bundled request model may compromise systems that don’t employ proper object-level authorization checks. Also, since developers interact with GraphQL services differently than typical web APIs, hackers could avoid detection by typical firewalls, requiring a new approach to security.

    These concerns aren’t dealbreakers for adoption; rather they are a reality check for those using GraphQL in production. Below, we’ll explore some potential weaknesses and look at some general mitigations that providers can take to improve the confidentiality of their GraphQL endpoints.

    What is GraphQL?

    GraphQL was initially developed by Facebook and open sourced in 2015. It’s a query language that makes data retrieval and manipulation with external sources very easy. Instead of programming and linking together complex calls with traditional HTTP API requests, GraphQL enables a client to bundle queries into a single request. This design pattern reduces the under- and over-fetching pattern that REST APIs typically suffer from.

    “You get exactly what you need, not more or less,” described Koren. This makes GraphQL a popular choice for modern database mechanics over REST, as it’s similar to SQL querying.

    Adoption of GraphQL is steadily growing; a 2020 RapidAPI survey found GraphQL usage had quadrupled. GraphQL is now used by 22.5% of API developers. But when it comes to overall API design patterns, REST is still the dominant architectural style used by 93.4% of APIs, found Postman’s 2020 State of API Report.

    GraphQL is promising and has a number of benefits, but remains in an early adoption phase. “It’s still a technology that early adopters are starting to look into—it’s not so widespread,” said Koren. Due to its age, GraphQL security practices are immature, exposing a few potential vulnerabilities for platforms that use GraphQL.

    Unique Security Concerns

    So, what are some unique security concerns in the GraphQL paradigm? Well, according to Koren, it begins with a lack of understanding. “Security is not necessarily top-of-mind most of the time,” he said. “When developers choose to implement GraphQL, they assume that they’re not using APIs anymore and that traditional REST API vulnerabilities do not apply.”

    In fact, the opposite may be true. GraphQL APIs can easily suffer from broken object-level authorization, OWASP’s number-one API vulnerability, just as REST APIs do. But, with greater ease of access to many underlying systems, a single GraphQL query could exfiltrate much more information than a typical API request. If the GraphQL provider does not have granular authorization checks for each particular method and resource, a GraphQL endpoint could suffer from data overexposure.

    Another issue concerns spotting malicious behavior. Typically, when hackers perform reconnaissance on an API, they brute-force it with many requests; trying different namespaces and changing user agents in the process. With REST APIs, this sort of malicious behavior is easier to catch with standard web application firewalls (WAFs) since it’s easier to notice hundreds of peculiar malformed requests. However, with GraphQL, a hacker conducting query batching could completely fly under the radar of typical thresholds.

    This could easily lead to an account takeover, said Koren, who has seen this in production. He described a production payment service that used GraphQL; callers could perform mutations and capabilities they shouldn’t have been allowed to perform, such as pulling up other users’ account information and even initiating transactions.

    It’s easier to limit this type of nefarious traffic with REST APIs by assigning access parameters to each resource and handling authorization checks once at a time. But, this playbook is thrown out the door in GraphQL. “When you’re using a single point to access the data, you may have some false sense of security,” said Koren. In practice, having a single access point requires hard work to retain its integrity. A usable GraphQL frontend may also often mask a convoluted backend made of disparate API styles, Koren explained, making it much harder to correlate user authorizations to specific resources and mutations across various microservices.

    Tips to Mitigate Weaknesses

    So, with these weaknesses in mind, how should GraphQL-based platforms respond? Koren provided the following advice to protect GraphQL APIs:

    • Adopt a security mindset in development: It’s vital to start with a security culture from the beginning. Usability shouldn’t compromise security; ideally, they should complement each other.
    • Ensure proper authorization checks are in place: Whenever an asset is provided to the user, you need to consider whether the user is authorized to access it—especially if they are hitting multiple resources at once.
    • Set a new baseline specific to GraphQL: GraphQL owners need to adapt their perimeter security systems to look for new queues. These validations should consider typical REST API security checks and nuanced thresholds that consider nested queries and batch queries.
    • Know your API inventory: Maintain a clear picture of the underlying architecture of what is beneath the GraphQL endpoint. Verify the data sources and ensure they correctly correspond to user privileges.
    • Increase visibility into API calls: If possible, increase your visibility into queries, mutations, attributes, variables and underlying specifications and how they interact with each other.

    Strengthening GraphQL Endpoints

    API attacks are rapidly increasing. Gartner estimates APIs will become a top threat vector in 2022, and Salt Labs data showcased a shocking 300% growth in malicious API traffic in mid-2021.

    “Like any other innovative tech that comes into the mainstream, it will rise in popularity, but it will not surpass REST in the foreseeable future,” says Koren. Perhaps in three to four years, GraphQL’s current 20% adoption rate will rise to 30% to 50%. While GraphQL is still a relatively niche tool, its use is growing, especially among API-first cloud-native tech companies. And with this adoption will come novel security concerns.

    According to Koren, query batching makes catching malicious attacks using ordinary firewalls tricky. Thus, training a new baseline to discover anomalies unique to GraphQL will be necessary to find and limit hackers while they are still in the reconnaissance phase. Thus, we’ll likely see future security investment go into spotting these atypical GraphQL interactions.

    In general, perhaps the best advice is to treat GraphQL with the same level of intensity you would with any other type of API—if not more. As a single doorway to many underlying systems, GraphQL requires added security forethought and careful application of user authorization.

    With that squared away, hopefully, GraphQL’s greatest strength will remain just that—a great strength.

  • Salt Security Adds Support for GraphQL APIs

    Salt Security Adds Support for GraphQL APIs

    Salt Security has extended its platform for securing application programming interfaces (APIs) to include support for APIs built using GraphQL.

    GraphQL is an open source data query and manipulation language for APIs that was originally developed by Facebook. It provides a more efficient approach to querying data than the REST APIs that are widely used today.

    Elad Koren, chief product officer for Salt Security, said adding support for GraphQL alongside existing support for REST APIs to the Salt Security API Protection platform will make it possible for security teams to discover those APIs, mitigate data exposure, stop attacks and eliminate vulnerabilities. The Salt platform parses the complex structure of each GraphQL query to identify unique object entities that are then used to create a complete inventory of the GraphQL APIs being employed.

    APIs built using GraphQL are more challenging to secure because of the unique call and response formats, noted Koren. Cybercriminals can also, for example, leverage GraphQL capabilities such as nested queries and query batching, to launch distributed denial of service (DDoS) attacks, he said.

    Many developers will tend to assume that, because GraphQL is relatively new, most cybercriminals are primarily focused on exploiting REST APIs. However, as more developers employ GraphQL, it’s only a matter of time before cybercriminals begin to find ways to exploit APIs that may not be as secure as the REST APIs that many organizations already know how to secure.

    The Salt Security platform itself is based on a big data engine that employs machine learning algorithms and other forms of artificial intelligence (AI) to identify attacks in real-time. It creates a baseline to identify legitimate system behavior while preventing cybercriminals from using penetration testing tools to perform reconnaissance.

    From a DevOps perspective, the Salt Security API Protection Platform integrates with tools such as Jira and Slack to ensure that remediation details are routed to the right development team in addition to helping track tickets to ensure remediation fixes are implemented. It also can be integrated with security information event management (SIEM) platforms from vendors such as Splunk and Sumo Logic to enable incident response for both DevSecOps and security operations teams.

    Most IT teams will not be replacing REST APIs with GraphQL-based APIs overnight. However, there will soon be enough APIs based on GraphQL to warrant additional security measures. Less clear is to what degree those security measures will be put in place by DevSecOps teams versus a security operations team.

    One way or another, however, the number of APIs that need to be secured is accelerating rapidly as organizations roll out a new generation of microservices-based applications that drive mission-critical digital business transformation initiatives. Each microservice has its own API that needs to be built and then secured. Unfortunately, most APIs are built by developers that don’t always have the greatest appreciation for security. As such, while more responsibility for API security is shifting left toward developers, many security teams would be well advised to make certain every API being deployed is fully secure.

  • Postman Survey Shows Focus on Building and Deploying APIs

    Postman Survey Shows Focus on Building and Deploying APIs

    A survey of more than 28,000 developers and application programming interface (API) professionals published today by Postman found nearly half of respondents (49%) are now spending the majority of their time developing APIs. More than a quarter (28%) now spend 20 or more hours per week working with APIs.

    Kin Lane, chief evangelist for Postman, a provider of a platform for building APIs, said that shift reflects an increase in software development and integration activity that began at the start of the COVID-19 pandemic. Almost two-thirds of respondents (63%) said the pandemic somewhat or significantly affected their work, with almost half of those respondents noting that changes made with their organization were enabled and supported by APIs.

    Additionally, a full 94% of respondents said the investment of time and resources into APIs will increase or stay the same for the next 12 months. The biggest obstacle to creating APIs is lack of time (45%) while the biggest obstacle to consuming an API is lack of documentation (55%). In terms of API goals, the survey found that quality (80%), agility (66%) and reliability (65%) are the top three goals among survey respondents.

    However, the survey also noted only a third of respondents said they could build and deploy an API in anywhere from a single day to a week, with most requiring one week to a month. About one-third also said they deploy APIs to production between once per week and once per month. More than 80% of respondents noted that less than 25% of their changes fail while a similar percentage said they can recover in less than a day with a third reporting they fully recover in less than an hour.

    The Postman survey also found that more than three-quarters of respondents (76%) have less than five years of experience with API development. Only half of respondents indicated that they agree or strongly agree that the leadership of their API team has a clear sense of where their API practice should be in five years. However, microservices (58%) and Kubernetes (50%), containers (46%), serverless architecture (44%) and GraphQL (35%) were ranked among the technologies that respondents were most excited about heading into 2022.

    On the plus side, more than 60% of respondents felt their API leadership and governance teams demonstrated a “willingness to change” as well as duly considering “the interests and opinions of employees.” When it comes to regularly providing feedback and process, more than half of leadership and governance teams (53%) scored well.

    The top two ways API teams collaborate is via a dedicated collaboration platform (50%) or by publishing API artifacts to repositories such as GitLab, GitHub and Bitbucket (45%), according to the Postman survey. The most widely used DevOps tools are Jenkins (37%), Azure DevOps (26%), GitHub Actions (25%), AWS DevOps (23%) and GitLab Pipelines (22%).

    In terms of deploying APIs, continuous integration/continuous delivery (CI/CD) platforms are the most widely employed (57%), followed by deploying APIs in the cloud (38%), frameworks (34%) and custom-built deployment methods (27%).

    Just over 70% of respondents ranked security and performance as the top factors considered when integrating with an API. When producing an API, however, the top factors are integration with internal systems, integration with external systems, adding functionality to an internal system and enhancing functionality for an end customer. Similarly, when consuming an API the top factors are integration with external systems, adding functionality for end customers, adding functionality to internal systems and integration between internal systems.

    In general, Lane noted that, as more APIs are developed and deployed to drive various digital business transformation initiatives, organizations will need to pay more attention to API discovery and management. There’s a tendency for different teams within organizations to not only create redundant APIs but also forget about so-called zombie APIs that are no longer supported but can still be exploited by cybercriminals.

    Overall, Lane said the survey makes it clear more organizations are pursuing an API-first approach to digital transformation. The challenge now is managing all the APIs that can quickly become too much of a good thing.

  • Securing Microservices Vs. Monolithic Apps

    Securing Microservices Vs. Monolithic Apps

    New requirements for Securing Microservices Vs. Monolithic Apps

    Enterprises are migrating from monolithic applications to microservices, hoping to accelerate software deployment and improve scalability. Security is sometimes glossed over in these transitions.

    Simple best practices like authenticating users and using SSL are still important to follow. But teams need to think through important differences between the two architectures to ensure new risks are not inadvertently introduced.

    As you begin  migrating from a monolith to microservices, some of these issues may seem relatively trivial. But left unaddressed they can create substantial security vulnerabilities, reduce performance, and result in technical debt.

    Some of the most important differences to consider include the number and size of attack surfaces, and how and where teams manage business logic security. Teams also need to think through the additional complexity of increased communication between microservices running in separate containers or machines. New issues also need to be addressed when application state is stored externally.

    1. One Larger Versus Many Smaller Attack Surfaces

    The biggest difference relates to the size and number of attack surfaces. A monolithic application is by definition a single application with a single attack surface. In contrast, a microservice architecture spreads the same functionality across multiple, independently running microservice applications, each with their own attack surface.

    The attack surface on the single monolithic app is also larger than on each microservice because the application has far more responsibilities to control.  In contrast, the attack surface of each microservice is much smaller because they are limited in what they can do. In traditional web application security, a web application firewall can protect the entire application in aggregate. With microservice security, however, teams need  to think about securing the connections to each microservice using a more adaptable firewall.

    2. Managing Business Logic Security

    Web application firewalls provide a front line of security to track what clients are requesting data and ensuring they have the appropriate credentials. Monolithic applications often add an additional layer of business logic security using a servlet. This performs logical filtering within the app itself to ensure requests are reasonable before passing them to the appropriate component.

    As a result, monolithic app components can operate on the assumption that the request has been validated at the application programming interface (API) level by the servlet. The servlet can keep track of who is making calls into the application and block requests that fall outside the bounds of normal behavior. A microservice rarely if ever has any idea about what has been done between other microservices. They are typically designed to operate independently from the details of everything around them, which means that business logic-level attacks are easier to perpetuate.

    3. Service-To-Service Complexity

    In a traditional monolith, messages are passed between functions within the application. In a microservice architecture, this traffic passes between multiple services that may reside behind a common firewall or separate firewalls.

    Developers may mistakenly believe these communications are safe when the messages are passed between services that exist behind a common firewall. But because of the dynamic nature of microservices, sometimes these communications are passed over wider networks. There can be security issues when data is passed between applications in plain text.

    Teams should consider encrypting data in transit as it is passed between microservices, and then encrypting data at rest when it is stored.  This encryption requires teams to think about creating an encryption process that runs in conjunction with provisioning and managing microservices. Each service needs to be provisioned with a public certificate and private key. There also needs to be a method for revoking  certificates and issue new ones when services are decommissioned or compromised.

    4. Authentication Latency

    Microservices can also increase the number of authentication steps required to execute a transaction. In traditional application security, an API security service only needs to secure one link between client and server.   With microservice security, additional consideration needs to be given to securing the connection from a client to each microservice and to the calls between them. This increases the number of security steps required for requesting and processing security tokens. Unless this process is efficiently engineered, each request can add latency and degrade performance.

    Some organizations may skip some of these steps, under the assumption that these services are communicating on a secure virtual private network. However, this can increase app vulnerabilities if the network is compromised. Another approach lies in implementing a better strategy for API security.

    5. Immutability

    Monolithic applications manage data as part of their operations. In contrast, microservices are architected so all data is stored external to the microservice, which is called immutability because the service does not change state. This makes it easier to spin up new instances or kill running ones without affecting the application as a whole. But because the microservice itself does not change, an external process needs to maintain a list of which microservices are allowed to talk to others. These need to be managed centrally and then either pushed out or pulled in to each microservice automatically.

    Another challenge is data integrity. In a traditional application, the state of a transaction can be monitored internally; if a step cannot be completed the entire transaction can be rolled back. In a microservice architecture this kind of state management needs to be managed externally.

    6. More Services To Monitor

    Traditional infrastructure-based monitoring was designed for providing endpoint and server security. Microservices generate more traffic between services at a finer level of granularity,  which can make it harder to automatically enable application observability through metrics, logs, and tracing. This is difficult enough just for measuring operational health, and even harder for tracking security posture.

    Another challenge confronting security designers lies in ensuring consistency for application observability data generated across microservices. At the least, security requires good logging and integration into incident response systems to alert security analysts to the possibility of subtle and slow-moving security breaches. More sophisticated approaches can combine these richer data sets with machine learning to help detect and block attacks without burdening teams with false positives.

    Planning for a New Security Posture

    None of these security concerns should be deal breakers for transitioning to a microservices architecture. But as enterprises begin to scale up their microservices implementation, these issues will grow in complexity. A little planning upfront could reduce the need for significant rework down the line.

    Security tools such as Traceable’s Defense AI are emerging to address these challenges in a more automated way. The key lies in balancing the appropriate set of rich observability data and machine learning, with a deep understanding of the rapidly evolving API threat landscape.

  • TraceAI : Machine Learning Driven App and API Security

    TraceAI : Machine Learning Driven App and API Security

    API security

    Modern applications are mobile first and are built around cloud-native distributed microservices architectures. These architectures have become the basic building blocks for complex and reliable distributed web and mobile applications. Many of these distributed APIs expose the business logic directly over the web; hence the attack surface and attack vectors are very different for these next generation applications. These next-generation applications demand next-generation application security solutions that need to stitch together a distributed application’s activity using techniques such as distributed tracing and then use next generation ML techniques to solve important application security problems.

    Proactive anomaly detection

    Anomaly detection approaches are a practical way to discover unseen strategies of attackers. However, these approaches are prone to very high false positive rates, thereby defeating their very purpose. Most anomaly detection systems flood analysts with false alarms resulting in a cognitive fatigue. Traditionally, the pitfalls of anomaly detection approaches have been addressed via false-positive workflows, better user interfaces and user experience tools. Analyst feedback is taken as a reinforcement on the algorithm and the algorithm tunes itself. However, the engineering cost of such an approach is very high and the product gets very complex leading to reliability and flexibility issues. Secondly, it still requires analysts in the loop to tune the back-end algorithms. Most practitioners think the issue lies with the anomaly detection algorithms, but in reality there is nothing much that the underlying mathematics powering these algorithms can really do in a cyber security setting. These very algorithms have been proven in domains other than cyber security.  At Traceable, we believe that the problem lies elsewhere. Our understanding of the nature of data shows that we need to support anomaly detection algorithms with something else. We need to marry specific application security nuances with the mathematics powering these anomaly detection algorithms. This understanding led us to build TraceAI.

    TraceAI and API

    TraceAI is the core engine that powers the application security functions of the Traceable Security Portfolio. The foundational principles behind TraceAI are:

    • To be able to dissect the AppSec requirement into the constituent entities that are root causes for application vulnerability
    • To be able to holistically observe the interaction behavior among these entities
    • To be able to discover anomalous patterns in this  behavior

    Using these guiding principles TraceAI implements a complex behavioral anomaly detector. To power this behavioral anomaly detector, we have identified five entities that interact with one another to result in security vulnerabilities. They are:

    • APIs – the basic building blocks of the distributed applications
    • API interaction – how these APIs are wired in order to provide the intended functionality
    • Actors – users, IP addresses or client-side applications such as mobile apps that use APIs to benefit from the intended functionality or in a malicious case, subvert the intended functionality. The actors may be assigned different roles such as admins, clients, managers etc…
    • API Data – inputs from actors required for the APIs to come to life. Outputs from APIs in response to the input.
    • Resources – back-end data or compute functionality requested by actors by calling APIs

    TraceAI combines APIs, API interaction, API data, resources and actors holistically to build an actor-centric and API-centric behavioral anomaly product. As a result, common behaviors, outlier behaviors, automaton behaviors (bots), and attack behaviors are discovered from trace data. These behaviors are API-centric as well as Actor-centric.

    False positives are eliminated by introducing additional security concepts commonly referred to as Trust-and-Risk models. TraceAI automatically identifies API risk and Actor-trust by observing data relative to a baseline which is again automatically built. The baseline in itself is not a piecemeal integration of various unconnected baselines, but is a holistic combination of various observations modeled using modern machine learning tools. We do not need teams of data scientists and security engineers to support the system as the underlying algorithms automatically learn from data. Once in production, the algorithms run in a self-drive mode, automatically building baselines and generating ML models.

    Machine learning algorithms under the hood

    The foundation of any machine learning is the depth and breadth of the dataset relative to the number of features used for detection purposes. Traceable agents, deployed inside your application, API gateways, and Kubernetes cluster, automatically collect all the necessary data and build distributed traces that form the data-layer foundation for TraceAI. Traces are continuously collected to become a learning set on logic and data flow from Edge APIs, to internal APIs to backends and third party services and thus generate the features that represent the application context. Having addressed the data challenge via the tracing platform our next challenge was to choose appropriate machine learning technology.

    The biggest challenge for machine learning in cybersecurity is having to deal with high-dimensional categorical data of sequential nature, combined with the need for explainability, causality, and attribution. Because the attackers’ strategy constantly changes, supervised learning has its limitations. Most popular ML algorithms fail miserably while simultaneously dealing with these two requirements. Taking these factors into account, we have engineered ML-based solutions by building algorithms ground-up (instead of fully relying on libraries) and adopting a self-supervised learning framework. Our unique way of representing multidimensional categorical information allows us to perform ML-based detection even on certain forms of encrypted data as well.

    A key component of the ML-based solution is the ability to discover the API endpoints, and to automatically generate the API spec via data analysis. As a result the expected request/response headers, body parameters and query parameters are not only identified, but are also characterized. This helps build the API spec, violations to which are flagged as anomalies. This completely automated process without the need for manually annotated data is feasible owing to the richness of data captured by the core distributed tracing platform.

    Complementing the ability to detect API data anomalies, TraceAI also detects anomalies in API interaction, and anomalies in users accessing these APIs. The User Behavior and Business Logic representation modules capture, represent and build baselines for regular user behavior and expected business logic. Unsupervised ML techniques are employed because these techniques are the only scalable alternatives. Once the baseline models are built, business logic abuse and behavior deviations are captured and surfaced as alerts.

    Extending behavioral anomaly detection to predictive threat detection, TraceAI introduces a novel exploratory learning paradigm for API security. This approach harnesses the fundamental principles behind reinforcement learning, adapted uniquely to application and user behavior representation. Using such an approach, we are able to generate potential anomalous patterns even before they occur. By comparing users’ activities against these generated patterns, we can identify users who are beginning to tread on a dangerous path. Hence, we can flag these users even before a full-blown attack is launched. As a byproduct, we are also able to quantify known and risky behaviors without manual intervention. Some of the machine learning techniques that we have used in order to power TraceAI are MinHash based embeddings, hierarchical user behavior clustering using LSH and OLAP-style sub-clustering, Bi-Directional RNN variants for time-series anomaly detection, and use of random walks with evolutionary algorithms for explorative learning.

    Anomalies in user behavior in the context of business logic

    Understanding application behavior and user behavior helps in:

    • Identifying violations to known user behaviors
    • Discovering novel behaviors
    • Grouping users based on their behaviors to create user cohorts
    • Determining how exactly APIs are being used in order to build a web application

    One can represent user cohort behavior as a summarized flow-graph as shown below.

    sample application flow
    Sample application flow.

    Each node in the graph represents an API that was called during an active user’s session. Two  nodes are connected if there is a transition from one API to another, and the flow between two nodes represents various statistics such as how many users exhibit such a transition or how often such a transition occurs across user sessions and so on.

    In the above figure, there are around 26 different nodes, each representing an API, and the flows connecting these nodes indicate paths of API access  based on monitoring users’ API call graphs. For a human analyst, this map is very difficult to comprehend and more so to detect that a particular user’s behavior has changed compared to other users’ behavior or to detect that a particular user’s behavior has changed compared to a baseline. Only machine learning algorithms can automatically interpret these kinds of representations and that too at the scale that we have to deal with.

    Behavioral clusters

    The figure above shows how TraceAI was able to create user behavior groups based on the pattern of API access. In essence TraceAI has peered into the complex flow graph shown above and then identified groups of users based on their respective API call flow behavior. The gray circles represent users who fall under commonly occurring behavior groups. These groups are low priority for an analyst as they are population characteristics. The red circle-A represents a user whose behavior is very similar to the gray circle-B. This means the user in circle-A is accessing the same APIs as users in  circle-B but managed to attack one or more APIs.  This further implies that the user in circle-A is following the same business logic as many other users but has managed to compromise one or more APIs. This is interesting information for an analyst, because one can now understand what led to the compromise in addition to knowing what was compromised.

    Tracking user behavior to detect API attacks

    Here, the figure above shows the user’s behavior and where exactly the attacks took place. There were authorization bypasses detected in two of the APIs (nodes) colored in red. The analyst now knows where the attack took place and how they got to this stage. The APIs leading up to the attacked API can now be analyzed for security vulnerabilities and code design flaws. In essence TraceAI has isolated and surfaced interesting behaviors from many possible behaviors so that security analysts can investigate further. By cutting down on possible candidates, TraceAI has reduced cognitive load and investigation fatigue by many orders of magnitude. TraceAI can also detect outlier behavior to flag groups of users who are not explicitly responsible for a known attacks, but are exhibiting suspicious behavior and not being like the rest of the users. Analysts can also dig into the outlier groups shown as “blue” circles, analyze few of these users, and then as a batch put all these users under a watch list. By working at the level of a group, multiple users can be tagged/flagged/watched without having to deal with each user separately.

    Summary

    Traceable combines the power of Distributed Tracing and TraceAI technologies to protect next generation attacks on Web Applications and APIs. By choosing the right machine learning technology, and focusing on addressing API security issues Traceable is pushing the boundaries of API security.

    We would love to talk to you further and demonstrate how our technology addresses API security issues in your environments.

  • Safeguarding Composable Architecture Applications Based on API-enabled Components

    Safeguarding Composable Architecture Applications Based on API-enabled Components

    The use of composable methodologies for application development is growing rapidly. The reason: It offers many benefits that speed the development process and opens up application creation to developers of all skill levels. However, the speed and ease-of-use benefits, via the reuse of pre-built components, can introduce new security risks that traditional security management solutions might not be able to handle.

    The rising interest and adoption of composable architecture seems to be a matter of the right approach at the right time. Businesses today are under great pressure to innovate, transform, and offer new products and services. The pressure is coming from both inside organizations and from customers. Those within need applications, tools, and services to increase productivity, boost efficiencies, and cut costs. Customers want fast service, improved engagement, and quick responses to any queries and questions.

    A composable approach to application development helps businesses deliver the needed solutions at the pace of modern business change. It accomplishes this by using composable entities that offer self-contained business capabilities. These elements make use of APIs and can be assembled and combined into larger applications.

    Bolstered by other industry trends

    Another reason for the popularity of composable application development is that it is a good match and complements other application development trends.

    For example, its usefulness is enhanced by low-code/no-code development methods. Low-code/no-code saw great adoption during the pandemic. Businesses realized they needed to be more responsive to fast marketing changes, and their at-home workforce needed easy-to-use solutions.

    The surge in their use continues this year. The low code development technologies market is projected to grow by 23% this year over last.

    Many of the reasons companies cite for moving to low code are similar to why they use composable application architectures.

    Namely, professional developers work faster, and they can spend more time on higher-level development problems. And both low code and composable methodologies let individuals and business groups with limited or no development expertise create their own powerful applications.

    So, in many ways, the two technologies go hand-in-hand in many organizations.

    Similarly, many of the underlying rationale and principles for using composability align with the other cloud-native methodologies. Specifically, with a cloud-native approach, applications are broken into loosely coupled microservices and container elements that are then assembled into a larger application. Specific elements in a cloud-native application, such as a front-end application or a business process, can be standardized and made available as a composable component in a cloud-native application.

    What’s needed for security?

    Enabling development using composable elements centers on APIs. Specifically, with respect to composability, Gartner notes that businesses “seeking to kick-start efforts to turn an organization into a composable business” should:

    • Enforce composable application design by ensuring application development teams use available external and internal API products
    • Educate teams about how to exploit existing applications and platforms for composability by using application APIs and low-code development and integration platforms.

    Hence, security efforts must change from traditional approaches to ones that are more API-centric. Solutions must observe all user activity and API interactions, then act on unexpected user and API behaviors.

    Solutions that address composable application security must offer infrastructure, services, and code-level threat analysis in a single platform to facilitate collaboration and expedite threat resolution to meet the needs of modern DevSecOps approaches to application development and security.

    Such capabilities are critical given the complexity of modern cloud-native applications. In many cases, when creating applications with composable elements, hidden inter-dependencies can arise. Traditional security solutions often will not be able to detect such issues or trace the source of problems down to the composable element level.

    Furthermore, while each element of an application may be secure, the interplay between the composable elements and the data exchanged between them can introduce risks that need a more API-centric solution which understands the greater application context. 

  • Use the OWASP API Top 10 to Secure Your APIs

    Use the OWASP API Top 10 to Secure Your APIs

    The tools, languages, platforms, and methods used to build applications have changed drastically over the past decade. Application security practices have to change with them; otherwise, security professionals will be playing constant catch-up with attackers and cybercriminals.

    What Is the OWASP API Top 10?

    The increase of microservices and application programming interfaces (APIs) has given rise to a new set of threats against applications. The OWASP API Top 10 documents the risks associated with API development.

    Here are the vulnerabilities highlighted in the most recent OWASP API Top 10:

    1. Broken Object Level Authorization (BOLA)
    2. Broken User Authentication
    3. Excessive Data Exposure
    4. Lack of Resources and Rate Limiting
    5. Broken Function Level Authorization
    6. Mass Assignment
    7. Security Misconfiguration
    8. Injection
    9. Improper Assets Management
    10. Insufficient Logging and Monitoring

    Why Is the OWASP API Top 10 Necessary?

    Large monoliths are giving way to small, nimble microservices. Kubernetes, containers, cloud-native architectures, and API gateways are the new hotness. This shift has also led to new threats.

    Let’s take a look at the differences between traditional web development and API development.

    Authentication and Authorization Look Completely Different

    Three out of ten risks in the API Top 10, including the first two, deal with authentication and authorization issues. These critical security functions look differently with APIs than they do with more traditional web applications.

    In a typical web app, the user logs in and the server grants a session cookie. The browser stores the cookie and passes it to the server with every request, removing the need to re-authenticate. All of the user’s permissions are tied to the session ID.

    APIs are made of several mini web apps all deployed on separate servers, each with its own data store. Creating a session in one server doesn’t matter much. The server receiving the next request won’t know anything about the session stored at the first server.

    This complexity gave rise to the OAuth and OpenID Connect specifications. These specs outline authentication (Open ID) and authorization (OAuth) for distributed systems. Using these techniques correctly helps to keep microservices and APIs safe.

    But even though authentication and authorization have changed for APIs, another aspect of them introduces a new big player in API risks: business logic errors.

    APIs Talk Too Much

    Traditional web applications expose one endpoint, and one executable running on the server contains all business logic. An attacker will have a difficult time mapping out all of the internal business logic of an application. With so much trial and error, it’s easier to go after vulnerabilities based on inputs, such as XSS or SQL Injection.

    On the other hand, breaking an application into microservices, each with its own API endpoint, by default exposes much of the business logic to the outside world. You can watch your browser’s connections to see the individual pieces of the application as a whole. And most of the time, the public interface reveals the essential parameters and unique identifiers of sensitive data objects.

    BOLA is an excellent example of this phenomenon. BOLA occurs when an attacker changes the resource ID passed into an API to retrieve someone else’s records.

    Imagine a medical application that holds sensitive documents. You can view your documents in PDF form. Since APIs are used to serve up your data, the client app passes an ID through the URL. You accidentally (because we know you’d never do this on purpose) transpose the numbers in the URL. All of a sudden, another person’s medical information stares back at you. You’ve discovered a BOLA vulnerability.

    Another example of APIs talking too much is with claims-based authentication. Typically, JSON web tokens (JWT, pronounced “jawt”) are used to send the current user’s permissions, referred to as “claims.” These tokens are easily decoded and updated.

    Imagine receiving a JWT using OAuth and decoding it. You notice that one of the attributes on the token is “admin: false.” Now you know how the application determines your permissions. You change the attribute to “admin: true” and send it back to the application with the next request. If the API doesn’t follow the correct token signing and verification procedures, you’ve now become an administrator and can gain access to all sorts of goodies.

    Make sure your APIs aren’t leaking too much information. Be aware of what your API’s clients see and determine the risks and mitigation of each piece of data.

    “Loose lips sink ships” was a famous security warning during World War II. In today’s world, loose data sinks APIs.

    Microservices and APIs Are (Too) Easy to Create and Deploy

    New development methodologies come with cultural changes within organizations. Developer autonomy and delivery speed are emphasized, leading to many development teams deciding how to implement APIs and when and where to deploy them.

    These methods lead to greater flexibility, agility, and scalability but could also create  API proliferation and increased risk. Number nine on the API Top 10 is Improper Assets Management. Not knowing where all of your APIs are and what they do can lead to serious application vulnerabilities.

    For example, in creating and deploying a new version of an API, an endpoint running the old version could still exist. Should the old version contain a security vulnerability, attackers could exploit it without your knowledge. Building an inventory using API discovery techniques allows organizations to find these endpoints and shut them down properly.

    Businesses need to be agile and responsive. But they must also be aware of the side effects these strategies create and design processes to keep things under control.

    If You’re Building APIs, Don’t Forget the API Top 10

    Building microservices and APIs is distinct from building traditional web applications. Differences in environments, frameworks, and development techniques solve some problems while introducing new ones.

    Get familiar with the OWASP API Top 10 and use it to check your applications. Add it to the regular security checkpoints you already have. Then you’ll be confident your APIs are safe and secure.

    Traceable Defense AI helps protect against the OWASP API Top 10. View a recorded demo to see it in action.

  • API Security by Design

    API Security by Design

    “APIs are nothing new,” said Secure Code Warrior co-founder and CTO Matias Madou, but they have recently become more widely used.

    And where they were once a local mechanism, they are increasingly used in a distributed manner, partly because of changes to application architectures. Another reason is that users are increasingly likely to access systems from outside the organization, whether they are customers, suppliers or employees working at home.

    Potentially anyone and anything can access an API, so developers and architects should therefore assume that APIs are exposed, and treat requests accordingly.

    This means addressing issues such as authentication and authorization, and generally ensuring that the only data exposed by the API is the data that’s supposed to be exposed.

    So assume every API call is malicious, suggested Madou.

    Start at the Beginning

    Achieving API security starts with the design and architecture, so jumping in and writing code immediately is a mistake. Unfortunately, starting with a completely blank slate is unusual, and some code will likely already exist. In that case, it is especially important that the design makes provisions for possible weaknesses.

    If you want secure APIs, then ensure that everyone working on the project – architects, developers, testers and so on – are “very security savvy,” said Madou.

    The need to improve skills is often triggered when the company or one of its competitors experiences a problem.

    So teams should work to identify any existing problems, realize they need to proactively avoid the underlying issues, and undergo appropriate training, he says.

    The trouble is, “security and developers are not often the best of friends,” Madou said. So, developers tend to think that security is the responsibility of their security colleagues. But there should be a common goal: making reliable and secure software.

    “Security needs to help developers,” he said. One way of achieving this is to appoint a ‘security champion’ to act as a bridge between the security and development teams. An embedded security person can help developers realize that security is an enabler, not a blocker.

    Help When Help’s Needed

    Embedding communication from the security team into developers’ workflows is another part of the process. Slack is one possible conduit. Security people need to be wherever developers discuss issues. Then, they can take advantage of opportunities to say things like, “it looks like you’re having problems with SQL injection. Here’s some training material that might help.”

    Developers live in their IDE, so that’s where integration should occur. But design such systems to help developers, not to control them. “Developers are people, not robots controlled by machines,” Madou warned.

    Another consideration is that it’s important to avoid unnecessarily interrupting developers. Such systems should therefore predict what a developer is about to do and deliver appropriate guidance.

    For example, if someone codes a database connection, the system could offer the statements that securely retrieve information. Then, the developer can copy and paste them instead of starting from scratch each time. Using new code every time carries the risk of introducing vulnerabilities.

    “It’s tricky to make these systems,” Madou admited, but he predicted they will become increasingly common in the coming years.

  • Salt Security Enhances Developer Insights on Industry’s Only Full Lifecycle API Security Platform

    Salt augments existing “shift left” features to provide more remediation insights earlier in the API lifecycle to help organizations better secure their API-driven applications 

    Palo Alto, CA – May 12, 2021 – Salt Security, the leading API security company, today announced that it has updated its next-generation Salt Security API Protection Platform with additional “shift left” security capabilities including API security posture insights and automated OpenAPI Specification (OAS) analysis and reporting. These latest capabilities enable Salt Security users to harden the full application lifecycle — build, deploy and runtime – identify risks and vulnerabilities in APIs before they are exploited, and make it easier to report on OAS standards to improve their API security posture.

    The new capabilities in the Salt platform enable companies to identify these vulnerabilities before they can be exploited. Because Salt provides both runtime protection and developer insights, companies can ensure their vital data and services are immediately protected against attacks while they work with developers to harden their APIs.

    “From a security standpoint, today’s application dependence on APIs changes the source of risk – it’s not just the front end under siege from traditional attacks and recon activities that map out backend processes,” said Mike Rothman, president of security analysis and consulting firm  Securosis. “APIs have quickly emerged as the most attractive and least protected target within today’s new applications, since they have access to critical data and services.”

    New features in the Salt Security API Protection Platform include:

    • Posture insights – enabling companies to identify risk and vulnerabilities in their APIs before they can be exploited. The Salt platform highlights actionable insights on exploitable vulnerabilities such as potential data leaks and security misconfigurations, before any actual attack has occurred. These insights help customers continuously improve their security posture and reduce their attack surface.
    • OAS accuracy – ensuring accurate documentation to enhance organizational efficiency and simplify compliance. The Salt platform provides a dynamic comparison between OAS documentation and the APIs and sensitive data the Salt platform discovers. On average, customer evaluations reveal 40% to 800% more APIs in use than companies have in their documentation and 10x to 20x the number of parameters.
    • Automated alerting and documentation – providing real-time feedback on non-compliant APIs and generating OAS documentation. Salt sends real-time alerts whenever the APIs and exposed parameters it discovers do not match OAS documentation. Organizations can export the full discovery of APIs and exposed data as updated and accurate OAS files, ensuring documentation is complete before APIs are published and simplifying compliance.

    The Salt platform has long used attacker behavior to identify security gaps in APIs – effectively using attackers as pen testers, with their small successes, before the Salt platform shuts down the attacker, highlighting areas where APIs can be improved. These new capabilities identify such security gaps well before they can be even partially exploited. Salt integrates with DevOps tools such as Jira and Slack to efficiently route remediation details to the right development team and can help track tickets to ensure remediation fixes are implemented. Salt taps the vulnerability learnings from its customer environments to enhance its ML and AI models, improving remediation insights for all its customers.

    According to the Salt Security State of API Security Report, Q1 2021, API security concerns are significantly inhibiting business innovation. Identifying vulnerabilities in APIs early in their lifecycle is crucial to protecting companies’ vital assets so they can focus on business operations instead of risk. Because APIs are unique to each business, every API vulnerability is a zero-day vulnerability.

    “The misconception persists that WAFs and API Gateways are sufficient for protecting APIs against vulnerabilities and attacks and that developer documentation provides all the information an organization needs about its APIs,” said Roey Eliyahu, co-founder and CEO, Salt Security. “But API attacks easily elude WAFs and gateways, which can protect against only known attacks, and today’s application environments are too complex and too dynamic for manual documentation to keep up. APIs are among the most vulnerable parts of the modern application stack. Salt Security’s latest capabilities make security more effective across the full application lifecycle — something no other company in the API security market provides  — identifying the zero-day vulnerabilities and protecting them from attacks in runtime.”

    For more information on the Salt Security API Protection Platform or to request a demo, please visit: https://content.salt.security/demo.html.

    About Salt Security

    Salt Security protects the APIs that form the core of every modern application. Its API Protection Platform is the industry’s first patented solution to prevent the next generation of API attacks, using machine learning and AI to automatically and continuously identify and protect APIs. Deployed in minutes, the Salt Security platform learns the granular behavior of a company’s APIs and requires no agents, no configuration, and no customization to pinpoint and block API attackers. Salt Security was founded in 2016 by alumni of the Israeli Defense Forces (IDF) and serial entrepreneur executives in the cybersecurity field and is based in Silicon Valley and Israel. For more information, please visit: https://salt.security