Category: Traceable Microsite

  • 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. 

  • What Runtime Application Self-Protection (RASP) Doesn’t Solve

    What Runtime Application Self-Protection (RASP) Doesn’t Solve

    RASP, or Runtime Application Self-Protection, is a modern security technology that protects web applications from attacks during runtime. The technology is an important complement to defense systems that focus on the perimeter, but RASPs also have weaknesses that can introduce their own vulnerabilities.

    What are RASP’s strengths and weaknesses in protecting against modern security threats? Are there better solutions that offer more in-depth insight into attacks as well as detect suspicious behavior?

    A deeper dive into RASP

    Gartner defines RASP as “a security technology that is built or linked into an application or application runtime environment and is capable of controlling application execution and detecting and preventing real-time attacks.” Many IT organizations already deploy them, often in conjunction with other security solutions.

    An ideal RASP promises:

    • Deeper-rooted code-level visibility into applications
    • Passive and active incident response features such as monitoring/alerting and blocking modes
    • Configurable options to log, alert, challenge, or block malicious behaviors
    • Support for many languages and execution platforms
    • Autonomous operation without manual tuning
    • Coverage for a broad set of vulnerabilities, including OWASP top 10
    • Integration with secure software development lifecycle (SSDLC) and monitoring tools.

    RASP fills the security gaps left by a perimeter defense model like Web Application Firewall (WAF), which protects both legacy and modern applications. Based on these promises, RASP may look like the necessary missing piece of your security stack. In practice, however, it has weaknesses. Let’s dive deep into RASP to understand its advantages and shortcomings.

    RASP advantages

    Watches rather than predicts

    Similar to WAF, Runtime Application Self-Protection works by blocking malicious behavior but does so without extensive need for preset rules and tuning. Rather than building a trained model or predicting behavior, RASP watches the application at runtime to see that those actions are actually performed. For example, a request call to a database occurred, a shell command is executed, or that a file is opened.

    DevOps-centric attack visibility with better SSDLC integration

    RASP provides visibility into how an application is being attacked, providing better intel and alerting security personnel and developers to the exact vulnerable code. Developers can use this information to modify the codebase and eliminate security vulnerabilities. RASPs may also offer the option to integrate directly with the application development lifecycle to pinpoint vulnerable code based on attacks observed in the production environment.

    No training required

    An ideal RASP doesn’t need to be taught what bad behavior looks like. That’s because it is tied to the application stack, so knows what the application should and shouldn’t be doing. When the application’s behavior changes, it’s no problem for RASP to adapt because the security is based on the application and not on a set of predefined rules and educated guesses.

    Provides time to fix vulnerabilities

    Programmers are responsible for developing and releasing new applications and features, and subsequently developing updates and patches as vulnerabilities and bugs are discovered. It can take organizations months to apply patches which creates a window of opportunity for hackers. Because RASP protects against incoming attacks, it provides the engineering team time to fix vulnerabilities free from the pressure of working during a crisis. It is synonymous with WAFs’ virtual patching.

    Cloud agnostic

    The RASP protection design is rooted in modern software engineering techniques such as instrumentation, dynamic hooks, and secure SDKs. It works by implanting sensors in the existing application code to monitor and control critical execution points in real time. Utilizing these techniques, RASPs become part of the application, allowing them to remain protected independent of their deployment environment. RASPs may not require network calls and work in any deployment architecture, including on-premise, cloud, and containers.

    RASP disadvantages

    Confined context

    Purely from a technical viewpoint, since RASP sits within the application framework, it may look to be a smarter alternative to perimeter defense solutions like WAF. Practically, however, no application is self-contained;  they interact with a multitude of other services and components. Consider that each application module can be deployed in different endpoints, further limiting the RASP’s visibility and capabilities.

    Use case abuse

    We frequently hear about large companies breached with modern application attacks like Broken Object Level Authentication (BOLA). Attackers substitute their resource ID in the API call with a resource’s ID belonging to another user. The lack of proper authorization checks allows attackers to access the specified resource resulting in BOLA. Since the input remains consistent with what the application received before, RASP finds no reason to inspect and will let it pass through. Attackers can abuse similar use cases like Broken Function Level Authorization (BFLA) without RASP suspecting the intrusion. Protection for such attacks requires building broader business context from the application, which RASPs lack.

    Normal API request by Robby to fetch his profile BOLA Attack: Robby changes his user id in the
    request and reaches Ava’s profile
    <code>
    REQUEST
    ===============
    GET /customer/
    12548
    /profile
    Host: shop.store
    Cookie: session=
    5015ee5d-6133-cab4874b
    Accept: application/jsonRESPONSE
    ===============
    HTTP/1.1 200 OKContent-Type: application/json{“id”:
    12548

    “fName”: “Robby”

    “lName”: “Saxton”

    “phone”: “202-555-0128”

    “ssn”: “987-65-4325”

    “address”: “3454 Crummit Lane,

    Omaha, NE

    68114”
    }

    </code>

    <code>
    REQUEST
    ===============
    GET /customer/
    12549
    /profile
    Host: shop.store
    Cookie: session=
    5015ee5d-6133-cab4874b
    Accept: application/jsonRESPONSE
    ===============
    HTTP/1.1 200 OKContent-Type: application/json{“id”:
    12549

    “fName”: “Ava”

    “lName”: “Rose”

    “phone”: “340-5556-577”

    “ssn”: “449-26-2109”

    “address”: “4702 Gordon

    Street, Chino, CA

    91710”
    }

    </code>

    Missing distributed protection

    Since RASP only has visibility for the current application context, additional application-level Distributed Denial of Service and Bot protections cannot be efficiently solved by RASP. A perimeter defense solution can completely isolate that traffic, absorb it, and take defensive action even before the attack hits the application stack.

    Intrusive deployment

    RASP requires an intrusive deployment model and is highly dependent on the platform and codebase used for the application to be beneficial. It has to be deployed along with the application in the application stack. Some organizations may not feel comfortable deploying RASP for critical services, thus needing to invest more in other security solutions that add cost and maintenance.

    Deployment challenges

    Conceptually, RASP can do more in-depth protection sitting within the application stack. But there are practical challenges in managing and updating a RASP component deployed at every endpoint. RASP adds additional performance overheads not just on the application execution but also on the dedicated effort required to deploy, tune, and monitor itself and the runtime environment. And to determine proper placement that protects all assets, RASPs may need you to gather internal information about the application and trace data flow.

    Unintended consequences

    Though RASP’s goals are noble, its deployment can create unintended consequences that produce pain points. For example, situations may require the rewriting of software execution at the last minute, introducing risk from a support/incident response perspective, particularly as applications are modularized and supported by distributed teams.

    Performance degradation and impact on service level agreements

    In today’s high-performing environments, where availability is expected to be at least four 9s, downtime could severely impact SLA’s, resulting in lost revenue and damage to the company brand. RASPs might impact the application functionality even in monitoring mode as they wrap over existing essential library functions. Since RASP does not learn the business context, it may predict that a perfectly valid use case is malicious. Allowing RASP to stop code running in production amid an attack may pave the way for an effective (and self-imposed) Denial of Service (DoS) engine.

    Too much reliance

    RASP should be considered as another layer of control, but human behavior can lead to too much reliance on RASP for application protection. This behavior can generate a pile of vulnerabilities that attackers can use in conjunction with other techniques to exploit the application. For in-house-developed proprietary libraries, RASP tools are still not substitutes. The Secure Software Development Lifecycle needs to be followed with other formal methods such as source code reviews and automated tools, like static application security testing and dynamic security application testing, to identify and remediate vulnerabilities in both the source code and the application.

    You deserve better

    RASP is not a plug-and-play technology; it requires a full cycle of validation with existing applications to ensure functionality and performance are not adversely affected. What RASP makes up for in some areas it lacks in others.

    There is a need for a better solution in the application security world that can provide more in-depth insight into attacks as well as detect anomalous behavior. Traceable provides this hybrid approach by combining distributed tracing with intelligent analytics to build a complete picture of your microservices and protect them. Don’t just cover one part of your application; defend it all.
    ‍

    If this sounds like a smart approach to detecting and treating modern security threats, then we should talk. View a demo of Traceable in action.

  • Security Risks With No-Code/Low-Code Tools

    Security Risks With No-Code/Low-Code Tools

    As the popularity of no-code and low-code tools grows, so, too, do security concerns

    The demand for new applications is growing at a rapid rate. Many individuals and business units will not tolerate delays. As a result, citizen developers are stepping in, some of whom may be sanctioned by the company while essentially operating as shadow IT.

    Common to both groups is that they increasingly are aided by the wide availability of no-code/low-code development tools and platforms on the market today. Such solutions abstract away many coding tasks, offering developers a visual studio or palette to create applications by dragging and dropping software components and smaller apps.

    No-code/low-code tools offload tedious chores from professional developers, allowing them to work more efficiently. For those without that expertise, these tools enable people who have intimate knowledge of the business create their own applications and automate processes.

    Development is not only faster but less structured. As such, these technologies in the hands of those not trained in security can introduce risk.

    There are many ways citizen developers can expose a business to cyber risks. One common issue in many companies is that citizen developers (like their professional counterparts) do not want to reinvent the wheel. If they can find an existing or open source component to an application, they might freely use it when developing an application. For example, rather than hard coding a front-end mobile user interface for different platforms, they may just take existing ones and use them for their new applications. Similarly, if they want their application to perform real-time analytics, they could use an open source events stream engine. And if they want to create an interactive chatbot, they might use open source cognitive apps. The problem is that they select these no-code/low-code apps with very little vetting of the code components they’re using.

    Another common issue is that a citizen developer might ignore built-in security features in a component that makes up their composite application. For example, they may choose not to password-protect a database to simplify its use. Or they may decide to forgo best practices and send data across public networks unencrypted.

    There are many choices like these where attention to security is needed. Yet, most citizen developers do not even know to be on the lookout for potential security weaknesses.

    Layering in Security Before, During and After Apps Are Created

    Obviously, citizen developer applications must be tracked, vetted and fixed before potential vulnerabilities are exploited by attackers.

    To do that, security needs to be integrated throughout an application’s life cycle. It is no longer enough to only test for vulnerabilities after an application is developed and let it operate unchecked forever. Additionally, security must be real-time instead of reactive. It must constantly examine the elements of an application as they operate and are modified.

    Cobbling together components using no-code/low-code techniques introduces additional issues. While the individual components may be trusted, the use of several components together might expose data or provide a weakness that can be exploited. Additionally, a composite application that is secure today may no longer be so if a new vulnerability emerges for one of the software elements within the application.

    What many organizations are finding is that they need to marry DevOps and security. Hence, the growing focus on DevSecOps in the industry. DevSecOps is increasingly necessary to find weaknesses and vulnerabilities in modern applications composed of loosely coupled components.

    The constant refreshing, updating and replacement of applications dictate that security must be an integral part of the entire life cycle of an application. Again, another reason to bring security into the application life cycle, just as DevOps does for development and deployment.

    And the complexity of applications built, even when using low-code/no-code methods, means security needs to be more sophisticated to understand hidden dependencies in today’s loosely coupled applications. Any security solution cannot be passive. Simple scanning for known vulnerabilities is not enough. A solution must understand the way components of a citizen developer application change over time and interact with one another.

    The bottom line is that cybercrime protection must be implanted at the code level, and secure coding practices must be instituted, especially when citizen developers are driving application development.

  • 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.

  • Why Businesses Need to Transform From DevOps to DevSecOps

    Why Businesses Need to Transform From DevOps to DevSecOps

    The need for modern applications to support continuous integration, delivery and deployment spawned the need for DevOps. Increasingly, as cyberthreats evolve and grow and application development methods and time frames change, security now needs to be an integral part of today’s application life cycle. As a result, businesses should move from DevOps to DevSecOps.

    DevSecOps is needed to address security implications introduced by changes in the way applications are now developed, deployed and updated. Some of the main drivers for moving to DevSecOps include:

    The speed and frequency of new apps creation and updates: It is no secret that developers are under great pressure to create new applications and features in faster time frames than ever before. Some industries such as banking and financial services are being challenged by nimbler FinTech organizations offering innovative services and better customer engagement. The same is true in retail versus online competitors. And most other businesses are in the midst of a digital transformation. All of this necessitates the development of more apps in shorter time frames.

    As the industry knows from DevOps, app development is just one part of the more extensive application lifecycle work that needs to be done. Here again, there is a change from tradition. Beyond the customary needs to update, patch and maintain applications, today’s users are accustomed to quick actions on their demands. They have an app store mentality. When they point out a flaw or suggest an enhancement, they expect these things to be addressed immediately.

    They want the same responsiveness in their business applications. It is no longer enough to put items in a Jira or some other project tracking solution for later consideration; actions must be taken immediately.

    In both the building and enhancing of the apps, the need for speed can overlook security issues.

    Cloud-native architectures: Many modern apps are built using cloud-native architectures based on loosely coupled microservices and containers. The architecture lets developers quickly build and update applications. The approach typically makes use of third-party and open source code to build a larger application. For instance, a loan processing application might include an open source decision engine, an outside financial institution’s credit rating service and a commonly used mobile app user interface.

    Another advantage of using a cloud-native architecture is that changes can be made quickly. Rather than writing a monolithic app from scratch or recoding an entire app when small changes need to be made, changes only need to be made to impacted elements. If a new feature needs to be added to a front-end mobile user interface, that’s the only element of the app that must be changed.

    These conveniences that make cloud-native so well-liked in the development community, again, can mean that security issues are overlooked.

    Low-code/no-code and composable applications: New technology such as low-code and no-code platforms abstract details about the code from developers. And they enable citizen developers, who certainly do not have an eye for security, to build their own apps. Composable techniques further simplify application development via the reuse of components.

    Bringing Security Into DevOps

    The implication of these industry changes is that security needs to be entrenched in the process throughout an application’s life cycle. It is no longer enough to test for vulnerabilities after the fact.

    Specifically, security operations must be integrated at every step of application development, modification, and deployment. It must be real-time instead of reactive. Security can no longer wait for a breach or attack; it must constantly examine the elements of an application as they operate and are modified.

    Additionally, DevSecOps is increasingly needed to find weaknesses and vulnerabilities due to hidden dependencies in today’s cobbled-together applications. The bottom line is that implementing cybercrime protection at the code-level and secure coding practices are lower cost, more efficient and more effective than trying to patch security holes in a finished application.

  • Security Observability: Why Tracing?

    Security Observability: Why Tracing?

    Detecting a cyberattack can take more than 200 days. During this time, attackers might be exploiting your system while you are completely unaware. Cyberattacks can cost affected organizations as much as $13 million per year.

    What if we could reduce the time to detect a cyberattack all the way down to zero? How much money could you save by detecting and stopping an attack while it is still happening?

    And what if we could do even better than that? What if we could detect security vulnerabilities before an attack even occurred?

    Security observability is critical to achieving these goals. Let’s take a look at what security observability means and how distributed tracing, which is one part of observability, can help to defend your business from cyber security threats.

    What Is Security Observability?

    Knowing what is happening inside software is the best way to learn how to defend it. Observability refers to the ability to see the state of a system at any time. It’s like opening up a watch and watching the gears turn.

    Applications and services constructed using APIs and microservices have an advantage over other systems because you can more easily observe what’s happening inside of them. You add hooks to the APIs and microservices and use additional tools to collect the details.

    This presents us with an opportunity to better secure applications and services against cyberattacks by allowing us to see exactly what is happening inside the system.

    The Three Pillars of Observability

    Three types of data are needed to make a system observable. These are commonly referred to as the “Three Pillars of Observability:

    • Logs: Raw data, recording every activity that happens in the system
    • Metrics: Aggregated performance metrics, such as CPU load and memory usage, collected as min, max, average, number of counts, and so on
    • Distributed traces: The complete path a request follows as it flows through the microservices
    • Data analysis/visualization tools (sometimes referred to as the “fourth” pillar).

    Yes, that makes four, but this item isn’t data. The above data is too complex to digest directly, making these tools paramount to achieving observability.

    Figure 1. Sending observability data from the microservices to their respective collectors.

    The three pillars are shown in the diagram in Figure 1. Each microservice in the diagram contains additional code that sends logs, metrics, and traces to their respective collectors. These collectors gather the data, store it, filter it, and pass it forward to analysis and visualization tools that make the data usable by humans.

    Traditional security tools, such as SIEMs, make use of logs and metrics to secure a company’s assets. However, these tools fall far short of protecting applications.

    Limitations of Logs and Metrics for Protecting Apps

    Logs and metrics begin to paint a picture of what is happening inside your APIs/microservices. But the picture is incomplete. Logs and metrics can help developers ensure that the system is working properly and they can help with solving problems during debugging. But they do not provide enough information to protect the system from cyber attacks.

    Logs: Just the Facts

    Every time a microservice is called or a request is generated, a message describing that activity is sent to the log collector.

    Code Snippet 2. Example of a log message, indicating that Service A has received a GET request.

    This message contains information about what has happened, but it is in a very raw form.  You can think of a log as a fact. It doesn’t provide any real understanding of what happened in the system.

    If this GET request was the first step in an attack, we can’t tell that from looking at the logs alone.

    Metrics: Adding Insights – What Happened

    Metrics are aggregated data collected from microservice activity. Metrics may include things like CPU usage, memory usage, execution time, number of calls or requests per unit of time, and so on. Each metric is associated with the microservice that recorded it.

    Figure 2. Metrics example, showing the number of calls received for the Login service. What do the spikes reveal? Are they attacks, or are they normal user behavior?

    Figure 2. shows activity over time for a login service. The login activity is usually uniform and consistent, but there are very large spikes that occur occasionally.

    The spikes show that there are bursts of login attempts that are occurring occasionally on a system.  They could indicate that a hacker is sending a brute force attack, attempting to guess usernames and passwords for administrators in the system.  Or they could indicate a hacker is trying to overload the server with a Denial of Service (DoS) attack.

    But these spikes might indicate normal user activity.  Perhaps many users are running an app simultaneously because they just saw a compelling television commercial that was aired during the Super Bowl halftime. Or maybe everybody is contacting Uber to request a ride at the same time because a Rolling Stones concert just ended.

    Another possibility is that these bursts of activity indicate a bug in the system.  Maybe there is some sort of unforeseen infinite loop that is causing an unexpected burst of activity.

    We just don’t know what is causing these bursts. To gain the insight we need to secure APIs, we need to know what happened before this metric was generated. We need the ability to work backward.

    Distributed Tracing: Context and Causality – Why Things Happen

    Distributed tracing can help us understand the reason things happen.  When we know why things happen, we can determine if an attack is underway.

    Figure3. A “span”, or trace, showing the path a request follows through the API/microservices system.

    Distributed tracing is a form of tracing that is specially adapted to microservice architectures.  It allows us to observe each request traveling through the system from its beginning to its end. We can use traces to improve performance and understand what typical behavior looks like.

    But traces also give us the power to identify attacks on our microservices and stop them.

    Traces show the entire path a request followed through the edge API and microservices. They can tell us:

    • If the request went through all of the required services, including authentication and authorization checks
    • If the request called any unexpected services or granted access to unauthorized data
    • Where the request entered the system. (If a request entered without going through an edge API, also known as an API gateway, there may be a problem)
    • The IP address that originated the request
    • And if they are working especially well, traces might even help identify an attacker.

    Data Analysis and Visualization Tools: Seeing What Humans Can’t

    In a real system, there may be hundreds of different paths requests can take, just like the one shown in figure 3. And each request could touch tens or even hundreds of services. While distributed tracing gives us the ability to observe all of these, the complexity makes it impossible for humans to gain much insight.

    Machine learning and data visualization tools can identify patterns in the data, in order to identify normal behavior and abnormal behavior, and can even create alerts when abnormal behavior is detected.

    These patterns of normal and abnormal behavior help us to identify security vulnerabilities and attacks within APIs and microservices.

    Tracing to Reveal Vulnerabilities

    The diagram in Figure 4 shows the combination of traces through a system. We can use this diagram to identify possible security vulnerabilities.

    Figure 4. Possible security vulnerability, indicated by the red-colored trace. The diagram shows that this group of requests may inadvertently grant unauthorized access to the user’s account-info.

    Figure 4 shows a pattern that contains an “Excessive Data Exposure” vulnerability, which is vulnerability #3 in the OWASP API Security Top 10. The pattern shows that when a user views a shopping cart, the API will also return the user’s account information.  This unnecessary information may include personal information, account information, or financial information a hacker can exploit.

    These insights help developers recognize potential security vulnerabilities and correct the code to eliminate them.

    Tracing to Detect Attacks in Real-Time

    Tracing can monitor each request and compare it to established norms. The system can generate an alert if a trace deviates from this expected behavior.

    Figure 5. Possible attack in progress. The diagram shows that a possible attacker may have found a way to bypass a required authentication or authorization step.

    Figure 5 illustrates a pattern that could indicate either a “Broken Object Level Authorization” attack or a “Broken User Authentication” attack, which are #1 and #2 in the OWASP API Security Top 10 vulnerabilities.

    This figure indicates that an attacker has found a way to enter another user’s shopping cart and possibly obtain information for that user, by bypassing either an authorization or an authentication check.

    Typically, tracing allows us to go back in time to find attacks such as the one above. Can tracing help to stop attacks in real-time?

    Yes, tracing provides the information we need to detect and stop attacks in real-time. However, more is needed. A sophisticated AI on top of a tracing mechanism would be able to notice abnormalities humans may miss and can stop abnormal behavior before any damage is done.

    Tracing plus AI gives us real-time security observability. In a future blog post, we’ll discuss how AI takes what tracing gives us and uses it to create real-time protection against attacks.

    Use Distributed Tracing to Defend Your APIs

    Cybercrime is expensive, and it can take a long time to detect an attack. Attackers are creative, and older techniques using logging and monitoring do not give enough insight to recognize an attack when it happens.

    Security observability uses internal states to thoroughly comprehend what is happening inside your API/microservices system with the goal of protecting them from attack.

    Observing your software, using logs, metrics, and most importantly, distributed traces gives you the opportunity to identify attack patterns, eliminate security vulnerabilities, and block attacks before they can cause serious damage. View a recorded Traceable demo to see for yourself.

  • Secure Kubernetes Architecture: Six Factors Essential to Success

    Secure Kubernetes Architecture: Six Factors Essential to Success

    Kubernetes has become the go-to container orchestration tool for businesses.

    Check out these telling stats [source: Enterpriser’s Project]:

    • 84% of companies are using containers in production.
    • Of those, 78% are using Kubernetes to manage their containers.
    • 69% of companies have found security holes due to misconfiguration of their Kubernetes environment.

    Your Kubernetes architecture is like a large house with container “tenants” living inside it. You’ll need to build it with care to make sure it’s a safe and happy place to live.

    Here are six essential factors to get right when planning (or auditing) your Kubernetes architecture.

    Setting the Foundation: Underlying Platform and Control Plane Configuration

    The foundation of a house is a critical first step. A weak foundation leads to cracks over time.

    Similarly, where you install Kubernetes is your first choice. There are several options available, each with pros and cons.

    Kubernetes is a cloud-native tool. Therefore, it makes sense to install it on the cloud. There are two cloud deployment options: Infrastructure as a Service (IAAS) or Platform as a Service (PAAS).

    An IAAS installation involves creating a series of virtual machines in the cloud (for instance, using Amazon EC2) and installing Kubernetes on those machines. You’ll be responsible for updates and configuration of the Kubernetes installation.

    On the other hand, all major cloud providers offer managed Kubernetes services. This deployment model allows you to use Kubernetes without having to handle the infrastructure.

    Even though Kubernetes was made for the cloud, you don’t have to install it in the cloud. An on-prem installation is an option, with many companies choosing to use their virtualization infrastructure to host Kubernetes.

    You’ll find a quick summary of the pros and cons of each choice below.
    ‍

    Your decision depends on three factors:

    • The skillset of your team
    • Your need for control and flexibility
    • Your company’s goals

    Control Plane Configuration

    The Kubernetes Control Plane consists of the services run on the Master node. The cluster store, scheduler, controller manager, and API server combine to create the control plane.

    Plan your control plane security well. If an attacker gains access to your control plane, they’ll be able to control your entire Kubernetes cluster. Use SSH or a VPN / VPC to connect to and use the control plane.

    If you’re using a managed service from a cloud provider, protect your API keys and credentials. Don’t ever store them in a source control system. Losing your API keys would lead to a complete takeover of your cloud infrastructure, not only your Kubernetes installation.

    Finding Good Tenants: Container Security and Composition Analysis

    The wrong tenants can destroy your house. Similarly, dangerous containers can bring down your Kubernetes environment.

    Make sure any containers you bring in from the outside are vetted and configured correctly. Only use trusted registries, such as Docker Hub or Quay.io.

    Finally, scan your containers before using them. You can use open-source container scanners to find vulnerabilities and malware. You can integrate most scanners into your CI/CD pipeline.

    Plan Your Rooms Wisely: Kubernetes Cluster Partitioning

    The rooms in your house each have a different name and purpose. You don’t keep a stove inside your bedroom or a bed in the kitchen. You give tenants private rooms while allowing them to share common areas, such as the kitchen.

    In Kubernetes, namespaces allow you to separate various applications within the same cluster logically. If the cluster is your house, each namespace is a separate room within it.

    Give namespaces to each application within your cluster. This practice produces three benefits:

    • Logically separates applications and environments (Development, Staging, Production)
    • Allows for robust Role-Based Access Control (RBAC)
    • Allows for network partitioning for added security within the cluster

    Kubernetes RBAC Primer

    You can check out the Kubernetes docs for comprehensive explanations of RBAC within Kubernetes. But here’s a quick primer for those who don’t have the time to read it now.

    Kubernetes has Roles and ClusterRoles. They contain rules that represent a set of permissions. There are no “deny” rules, so you have to know what access is necessary.

    Each Role is scoped to a specific namespace. ClusterRoles, on the other hand, have no namespace. In Kubernetes, an object can only be namespaced or not; it can’t be both. Therefore it’s necessary to have two resources, one for each scenario.

    Use Roles to create permissions tied to a specific application. Use ClusterRoles for access to cluster-scoped resources or resources used by multiple namespaces.

    RoleBinding and ClusterRoleBinding is the act of assigning permissions to a specific user. A RoleBinding grants permissions within a single namespace while a ClusterRoleBinding grants access cluster-wide.

    For example, assigning the “pod-reader” Role to the user “jane” in the “default” namespace allows “jane” to read pods in the “default” namespace.

    Roles define a set of permissions. Then users, groups, or service accounts (collectively called “subjects”) are assigned roles to grant access to specific resources within the cluster.

    Define network partitioning and access control appropriate for the business’s needs before deploying any application into your cluster.

    Watch Your Wiring: Inter-Pod Communications

    Shoddy wiring is more than an inconvenience. It can lead to damaging fires or even destroy the entire house.

    Similarly, poor inter-pod communications can bring your Kubernetes cluster grinding to a halt.

    A Kubernetes environment is a small network ecosystem. The same network topologies, protocols, and policies govern pod-to-pod communication as those you’d find in any corporate network.

    A full discussion of Kubernetes networking is beyond the scope of this article. You can read up on it using the Kubernetes networking documentation. But here are some quick pointers.

    You can use Service Topology to define how traffic flows to and from a particular service. For example, a service can specify that traffic should be routed to endpoints on the same node as the client.

    Service Topology is useful in the public cloud. You can use it to keep a service’s traffic in a particular availability zone or region to reduce latency.

    Another useful networking tool is NetworkPolicies. These application-level constructs specify how a pod is allowed to communicate with other entities. This feature is especially useful when you want to control network traffic using IP addresses or ports.

    Finally, you need to have a robust authentication and authorization strategy. We recommend using a service mesh to simplify load balancing, service discovery, encryption, and authentication. For example, service meshes include support for OAuth, which makes service authorization much easier to manage.

    Secure the Front Door: Ingress Architecture

    There’s no point in building a secure home and then leaving the front door unlocked. You don’t want to do that with your Kubernetes cluster either.

    In Kubernetes, Ingress exposes HTTP and HTTPS routes from outside the cluster to your services within it. Ingress is your environment’s “front door.”

    [source: Kubernetes docs]

    Carefully consider which server to use in your Ingress architecture. NGINX is a tried and true web server with all of the security features necessary to protect your services. NGINX now offers an Ingress Controller for cloud-native Kubernetes environments.

    However, you may want to give Envoy a look. It’s an open-source edge and service proxy built by Lyft specifically for cloud-native applications. It tackles the common observability and network debugging issues common in a microservice architecture. Envoy can also serve as a service mesh.

    As the “front door” to your cluster, the choice of an Ingress server also impacts security. You can use it to terminate TLS connections from clients before they access your services. Be sure to include a key management strategy, including a Key Management Service or another secure vault.

    Remember to follow the same security practices for your Kubernetes cluster as you do for any other part of your network infrastructure. Watch for OWASP Top 10 and OWASP API Top 10 vulnerabilities as well as logic-based threats.

    (Hint: Traceable watches for common and logic-based vulnerabilities by learning the business logic of your microservice applications. Check it out for yourself here).

    Finally, make sure your ingress plays nicely with mobile and IoT devices if you serve those clients.

    Install Security Cameras: Secure and Monitor Microservice Communications

    Video doorbells and security cameras are becoming commonplace. Homeowners want to know what is happening in and around their house.

    Securing and monitoring within your Kubernetes cluster is equally critical. Make sure that microservice communications are protected, and you know what requests are being sent between services.

    Consider point-to-point encryption between all microservices. And ensure real-time API monitoring for both REST and gRPC protocols.

    Zero Trust principles not are becoming more popular as new technologies are appearing that support it. Zero Trust is an operating model where no traffic is trusted by default, inside or outside your network.

    Within Kubernetes, implementing this model means verifying every request, client, or object trying to connect to your services. Nothing happens within your cluster unless the user or service account has proven that they have permission to act.

    Zero Trust is essential to cloud-native security. At any moment, dozens or hundreds of services are trying to perform actions and share information. Zero Trust ensures that every request is validated and there are no holes due to the assumption that internal traffic is automatically safe.

    Protect Your House

    The world of microservices and cloud-native architecture unlock countless opportunities for businesses today. But new technologies also come with new dangers; new opportunities for malicious actors to steal sensitive information.

    We’ve discussed six essential factors for securing your Kubernetes architecture:

    1. Choosing the underlying platform and control plan configuration
    2. Vetting and securing the containers running in your environment
    3. Implementing cluster partitioning and access control
    4. Defining inter-pod communications
    5. Choosing your Ingress architecture (protecting your “front door”)
    6. Securing and monitoring your microservice communications

    With these factors in mind, what should your next steps be?

    If you have an existing Kubernetes installation, use these factors as a mini-audit. Review your current policies and see how well they match up in these six areas.

    If you’re planning your first Kubernetes installation, use these factors as a guide to making sure you cover all of your bases. Meet with implementers and make sure you have a plan for all of these factors.

    Then your Kubernetes environment will be a happy home for your microservices.