devopsy.kinsta.cloud

Tag: data leakage

  • What Are You Securing?

    What Are You Securing?

    Every once in a while, I think it is important to look at the available technologies and tooling and ask, “What are we trying to do?” In the case of information security, we need to ask, “What, exactly, are we trying to protect?”

    The answers to that question are seriously limited. Availability, reputation, data. Since reputation is a business mapping of the other two, that leaves us with availability and data. Of the two, data is more important. Our systems being down absolutely costs us money, but leaking customers’ private data or our corporate secrets, like source code or technology designs, is worse in the long run.

    The problem with these observations is that if we are here to protect the data, and data is the more important piece of security, then why do we have far better application security than data leak prevention? Almost all of you have policies and processes to run an application through the wringer and get an “as secure as possible” result at the end. But data? The purpose of applications is to expose it. And in the process, we risk exposing too much of it or allowing tons of it out of a valid endpoint. I remember in the early days of login-based websites, there was a spectacular leak that let an attacker get hundreds of valid user credentials per page submission (there were a surprising number of these for a couple of years there; this one was at a college). We are facing much the same thing via APIs these days or even via pages meant to make access easier for users.

    Locking all of this behind logins is a useful step, but to use one of the many phrases we’ve stolen from military science, it is only a part of ‘defense in depth.’

    Once it is agreed that data is one of the two key things we need to protect, then the focus should be on how to do so. There are some amazing DLP products, both standalone and integrated into other technologies, that are worth looking into. There are also some great advances in automated response under the guise of AI/ML that should be watched closely because they are changing rapidly. Limiting the maximum number of responses allowed from a query is almost mandatory for application stability and for data leak prevention. And it isn’t that hard to implement.

    I assure you that ne’er-do-wells—particularly state-sponsored and corporate espionage hackers, but also amateurs—are using AI to make attacks more successful and less detectable. The least you can do is respond in kind, with some of the tools that can now do things like notify you about low-and-slow data leak attacks.

    Keep focused on what the goals are. Reiterate them often, and keep rocking it. That’s a lot of data splashing around the organization that your team is responsible for; make sure it’s as safe as possible.

  • DevSecOps May Be Key to Prevent Data Leaks

    DevSecOps May Be Key to Prevent Data Leaks

    Data leakage has become something of a norm in the digital realm, despite the fact that cybersecurity budgets are growing and more engineers are assigned to these very issues. Nowhere does this seem more true than in the realm of health care, where breaches that expose sensitive patient data are, sadly, a fairly common occurrence. 

    A recent report by Approov illustrates how severe the problem has become. According to Approov’s  All That We Let In research report, many of the mobile healthcare applications in use today are leaking sensitive patient data through APIs, potentially compromising millions of patients. 

    The study tested 30 popular mobile health (mHealth) apps, and the research estimates that some 23 million mHealth users are exposed, at a minimum. The average number of downloads for each app tested was 772,619. Analysts expect that the total number of users exposed by the 318,000 mHealth apps now available on major app stores is likely far greater. Among vulnerabilities detailed in the report:

    • 50% of the records accessed contained names, Social Security numbers, addresses, birthdates, allergies, medications and other sensitive data for patients.
    • 50% of the APIs tested allowed users (medical professionals) to access the pathology, x-rays and clinical results of other patients.
    • 50% of the APIs tested did not authenticate requests with tokens.
    • Of the 30 popular apps tested, 77% contained hardcoded API keys, some of which don’t expire, and 7% contained hardcoded usernames and passwords. Seven percent of the API keys belonged to third-party payment processors that warn against hard-coding their secret keys in plain text.

    “Look, let’s point out the pink elephant out in the room,” said Alissa Knight, researcher and author of the report. “There will always be vulnerabilities in code, so long as humans are writing it. Humans are fallible. But, I didn’t expect to find every app I tested would have hard-coded keys and tokens, and all of the APIs to be vulnerable to broken object-level authorization (BOLA) vulnerabilities allowing me to access patient reports, X-rays, pathology reports and full PHI records in their database. The problem is clearly systemic.”

    The report helps to illustrate a critical point: Sloppy code can lead to data leakage. “These findings are disappointing, but not at all surprising. The fact is, leading developers and their corporate and organizational customers consistently fail to recognize that APIs servicing remote clients, such as mobile apps, need a new and dedicated security paradigm,” said Approov founder and CEO David Stewart. “Because so few organizations deploy protections for APIs – that ensure only genuine mobile app instances can connect to backend servers – these APIs are an open door for threat actors, and present a real nightmare for vulnerable organizations and their patients.” 

    For organizations deploying apps using a DevOps methodology, it becomes very clear that much more must be done on the cybersecurity side to prevent data leakage. However, the general consensus is that data protection falls under the purview of CISOs and cybersecurity teams in the enterprise. Perhaps there is no better argument for adopting DevSecOps than the data leakage problems caused by insecure code and sloppy APIs. The report echoes that sentiment and offers several recommendations for developers creating and organizations using mobile applications. In other words, organizations should take several key steps to protect their customer data and sensitive resources, including:

    •  Address both app security and API security: Recognize that synthetic traffic to the API is an issue, and arises from bots and automated tools, not from genuine apps and legitimate data requests.
    • Shift left and shield right: Secure the development process and harden apps, but ensure that runtime protection is also in place.
    • Protect against X-in the middle attacks: Certificate pinning is critical, but often left undone because expired certificates can block apps and impact customer experience. However, when done correctly, certificate pinning does not impact either performance or availability.
    • Improve visibility into controls: Organizations and developers need to monitor the effectiveness of the controls they implement and adjust them easily – both for compliance with legislative mandates and to sustain data security and privacy.
    • Continuous testing: Penetration testing and static and dynamic code analysis should be performed regularly.

    Interestingly, those recommendations fit squarely into the role that DevSecOps should take in the DevOps process. 

  • 6 Common Pitfalls to Avoid While Building Out Your AI Tools

    6 Common Pitfalls to Avoid While Building Out Your AI Tools

    Enterprise-level companies, with thousands of employees across the globe, can have their AI framework replicated by B2B companies of nearly any size. In fact, even without access to a ton of proprietary data and immense computational power, you can build out effective AI tools.

    To begin with, you can introduce publicly available datasets from movie review websites, e-commerce review sites and elsewhere to train your system. When doing so, be sure to double check the license details of such publicly available corpuses, as some will not allow commercial usage. Then, during the preprocessing stage—after removing swear words, jargon and other irrelevant elements from your corpus—you can add noise and slightly alter your existing data to create even more relevant data points in your corpus. 

    After this, you can build a semi-supervised learning algorithm through techniques such as tri-training. In tri-training, we essentially train three different neural networks over binary classification data. Once two models agree with one another, the data is introduced to the third network and then re-trained until all three models are in agreement. However, before your AI tools are up and running, it’s important to be mindful of the following common pitfalls.  

    Overfitting AI Models

    It may seem counterintuitive, but you really do not want your AI model to be too accurate. If your cross validation score is anything above 100, then you might need to reconsider deploying the model, since it might be prone to overfitting. If your training data is overfit, one small change can render the entire model useless. Your model should be accurate. However, it cannot be too accurate, as it needs to be adaptive. 

    Class Imbalance

    When training your AI tools, it sometimes makes sense to include a disproportionate amount of your target variable. For example, perhaps you’re training your computer vision AI tool to recognize planks of wood in a warehouse. Even if planks of wood only account for 1% of your total inventory, you’ll want to oversample the minority class. In this case, you’ll likely want 60% of your sample to be planks of woods. You really want to amplify this number to ensure you have the right class balance. 

    Data Leakage

    Another common misstep is the failure to capture data leakage, which can occur in any number of ways. A common instance occurs when an element used to test the model slips into the training data. This generally causes your model to appear to be performing well. However, its predictions might not be as good when deployed in production. To rectify this, it is vital that you keep track of any changes to your AI tools. In addition to your organization’s code reviews and configuration change reviews, you should have data set reviews to ensure your AI engineering is being done properly. Any parameter change within your AI tools needs to be fastidiously documented. 

    Concept Drift

    All AI tools are dependent upon the shape of the data that comes into your system. For example, perhaps your AI model was trained for response times being between 1-100 seconds, and all of a sudden the response times are between 1-1,000 seconds. In this case, your model will likely fail to capture the new data points. It’s important to be aware of such an occurrence, so that you can retrain your model accordingly. 

    There are many techniques that can be used to identify instances of concept drift. Rather than waiting for feedback from your customers, you can set up anomaly detection in a way that it identifies concept drift on incoming data and automatically updates your AI model.

    Using Personal Data

    With the CCPA and GDPR in place and a federally mandated U.S. data privacy law on the horizon, organizations are wary of using their customers’ data to train their AI tools. It’s prudent to train your AI system with anonymized data; this way, you won’t set yourself up for problems down the road. 

    Failing to Ensure All Your AI Decisions Are Explainable

    Most AI-enabled decisions are enacted upon by teams rather than individuals. Hence, it’s vital that your AI model’s recommended courses of action come with explanations. Additionally, these explanations should have confidence intervals, making it easier to interpret results. 

    During root cause analysis and remediation, it’s often unclear which team is ultimately responsible for the issue at hand. If the AI’s suggested course of action comes with an explanation, this helps immensely during the remediation process. For example, if the starter event is a network build-up, the issue likely lies with the engineering team. Alternatively, if the starter event is a network configuration change, the network team is the likely culprit. By closely monitoring your AI tools’ performance and ensuring that all AI decisions are explainable, you can quickly solve issues and course correct.

  • GDPR and Data Leakage: How Semantic Graphing Can Help

    GDPR and Data Leakage: How Semantic Graphing Can Help

    Many of the hallmarks of modern application development that drive efficiencies in the software development life cycle (agile, CI/CD, microservices, cloud infrastructure, open source libraries and third-party APIs) also create significant data leakage risks. Meanwhile, the EU’s General Data Protection Regulation (GDPR), which took effect May 25, creates a need to protect more types of data than ever before and comes with the strongest penalties for non-compliance: €20 million or up to 4 percent of a company’s global revenue.

    Preventing Data Leakage Getting More Difficult

    There are three primary reasons why data leakage has become more challenging for developers: complexity, speed and external services.

    Applications themselves have become more complex as organizations adopt microservices architectures. While this enables developers to be more efficient, it also often leads to more siloed views of the application while the data flows become more complex. For example, how many organizations understand  every entry point, exit point and handling of variables across every microservice in their broader application? And, organizations that adopt open source to increase efficiency by not having to reinvent non-differentiating code often fail to comprehensively understand the third-party code in depth. This makes understanding data flows even more difficult.

    The increasing pace of releases exacerbates complexity issues. Many organizations now release monthly, weekly or even daily. With less time to focus on anything beyond meeting feature deadlines, mapping data flows often becomes an afterthought. Furthermore, even if an organization is able to thoroughly map their data flows for any given point in time, the rate of change makes it impossible to stay on top.

    As organizations adopt third-party services for key functions such as code repositories, logging, databases and analytics, the consequences of leaking data become severe. For example, Uber leaked AWS credentials into GitHub, from which bad actors were able to initiate an attack that lead to 57 million records being compromised—simply by logging in.

    Why GDPR is Different

    GDPR is a significant expansion of previous data protection regulations in a number of ways. Unlike the Health Insurance Portability and Accountability Act (HIPAA) and Payment Card Industry Data Security Standard (PCI DSS) in the United States, GDPR applies globally and across industries. Any company that holds or processes data on an EU resident is subject to the regulation. Cloud-based software is inherently more global, and many U.S. or Asian-based organizations have users that are EU residents.

    GDPR expands the definition of what needs to be protected in a big way. HIPAA and PCI DSS formalized rules around protecting healthcare and credit card data. However, GDPR expands data that must be protected to include anything that can be used to identify a person—anything from a name, a photo, an email address, bank details, posts on social networking websites, medical information or a computer IP address.

    And GDPR has real teeth. Companies can be fined up to 4 percent of their annual global revenue or €20 million for major breaches and 2 percent of their global revenue for minor breaches. Given the global nature of modern cloud applications, the potential impact of GDPR is far-reaching.

    Traditional Approaches to Preventing Data Leakages

    Traditional approaches to preventing data leakage have been focused primarily on acting as a proxy between the application and the rest of the world. In such a position, the proxy can attempt to filter data and look for patterns. These approaches are outside-in. They do not attempt to understand the application itself; rather, they inspect traffic flowing from the application without context.

    First, let’s clarify that despite the similar sounding name, preventing data leakage is not the same as data loss prevention (DLP). Traditional DLP vendors such as Vontu (now Symantec) and cloud access security brokers (CASBs) are solving a different problem. They are an IT-centric solution to preventing malicious or accidental data breaches that are typically driven by end-users moving documents via email or file sharing. These tools aren’t designed to prevent the applications themselves leaking data and they are of little use to developers.

    The more application-specific attempts to identify data leakage have been via web application firewalls (WAFs). As proxies, WAFs often employ pattern matching techniques such as looking for 16-digit numbers on the assumption it may be a payment card, keyword matching, fingerprinting and other statistical content analysis techniques. In practice, these methods are ineffective because they create far too many false positives. Furthermore, encryption is problematic in that the WAF either can’t inspect the data or a man in the middle decryption must be set up, which is computationally expensive and can add latency. Latency may not matter for traditional DLP solutions monitoring email, but it’s vitally important to developers managing cloud applications.

    One traditional method for identifying data leakage that does take and inside-out approach is taint tracking, which evaluates pre-existing binaries. In reality, taint tracking is impractical because of excessive performance costs and numerous false positives due to taint proliferation (transitively from application to web framework to kernel).

    Taint and information-flow analysis approaches track the flow of data through the program, assuming that the data originated from untrusted sources. Sources are where such data flows enter the program, and sinks are where they leave the program.

    Several publications define sinks informally as “data that leaves the system,” which is too imprecise to train a machine-learning based classifier; such classifiers are only as good as their training data.

    Dynamic taint tracking by plain instrumented emulation is extremely expensive and tend to slow systems. Such a slowdown is unacceptable in practice and significantly hinders the adoption of dynamic taint tracking systems for everyday use. Such taint proliferation can substantially impair the performance of the running system.

    Mapping Data Flows with Semantic Graphing

    To truly prevent data leakage, you must first map data flows. You must understand the building blocks of the application, including its security DNA. However, the difficulty comes from balancing comprehensiveness with speed. Simply put, to account for all possible leakages in a rapidly evolving application you must automate.

    Semantic graphing is based on a simple observation: There are many different graph representations of code, and patterns in code often can be expressed as patterns in these graphs. It is a graph of graphs that, for the first time, enables automatically creating profiles that understand the context of an application. Semantic graphing is language-neutral intermediary representation designed for code querying, which focuses on what the program is designed to do, what it is not supposed to do and how it functions. Because semantic graphing identifies which variables are sensitive and how they flow across each microservice, it then becomes possible to visually represent data paths and identity leakage/violations.

    In this instance, we seek to understand data flows and prevent leakages. However, the ability to understand an application’s context in code is fundamentally the foundation for DevSecOps. AppSec remains manual primarily because humans must apply the application’s context either through configuring rulesets or wading through false positives, both of which are impossible tasks. Beyond just data leakage, semantic graphing has the potential to deliver security at the speed of DevOps.

    — Chetan Conikee