devopsy.kinsta.cloud

Tag: inventory

  • Fear of the Unknown

    Fear of the Unknown

    We IT folks are pretty fearless. Because it is newer technology, and change in IT is easier than in areas like heavy manufacturing, we are regularly thrown new tools, products and methodologies and expected to be able to master them. And we do. And it works. If your career is more than a couple of years old, you are not doing what you started out doing. DevOps and Agile have made this process more pronounced because they increased the rate of change, but this phenomenon has been going on since the PC became readily available. Someone somewhere is currently developing your next toolset. And when they do and it gets thrown at you, you’ll figure it out and run with it.

    The problem is that our architectures are never black and white, and we should fear the unknown more. The unknown residual cruft that is all over our networks. Doesn’t matter if “networks” means data center, cloud or both, there’s residual cruft on it. Some organizations even have a full-time position finding cloud instances and services no longer in use and eliminating them. But it is much more broad than cloud instances; there is garbage all over your network and it is time to try to clean it up.

    Most of us believe that we can’t possibly get a handle on everything that is out there. Oh, zombie containers and VMs are relatively easy, but the modules and libraries we loaded up and then, through the natural evolution of the software, stopped using, or whatever was bundled in with the OS chosen for that particular project, but was never used—it’s all over, it’s hidden and lots of it isn’t easy to find. That doesn’t even touch on the software that one employee from accounting absolutely had to have—but that employee is long goneand no one in accounting is willing to remove the software, either because they’re unaware of its existence or because they are unaware of what purpose it might be serving.

    There are tools to help with some of this, like SBOM generators for excess software on instances, and application maps that work much like network maps to help you understand what is interrelated. But they’re not perfect. They can’t be. You’ve been building this spaghetti application infrastructure for years; it’s going to be tough to work out. Get a list of what’s deployed, tag a person as responsible for it–that app in marketing? The person who requested it is responsible for it (or their manager is, if the original person is gone). IT is responsible for cataloging and, in some orgs, managing the app, but the business unit can explain why it is in use, and if it is still necessary.

    It’s a ton of work and, as a former enterprise architect, I can confidently say that it won’t be easy getting names attached to apps. Some apps you might have to turn off to see if they are still in use … and the work will likely never be complete because the infrastructure is changing non-stop as you work.

    But it’s worth it. It saves the org money; it reduces IT footprint and it reduces security exposure. It may even save IT staff time, which is one of the most precious commodities your organization currently has. So, start wrangling. Start with one business unit and ask them to help you–after all, they are almost guaranteed to have running apps or SaaS that IT is unaware of. The goal is not to take control of those apps and relationships, but to inventory them so that when they’re no longer needed they can be cleaned up. A side benefit is that if four business units are using similar software outside of IT’s purview, it may be possible to merge those solutions for a corporate approach … But that’s a blog for another time.

    Meanwhile, keep rocking it! Just remember there is more on the cloud and in your data center than are dreamt of in your architecture plans (many apologies to Shakespeare). And keep solving the business’ problems.

  • Strengthen API Security With These Tips and Patterns

    Strengthen API Security With These Tips and Patterns

    If you haven’t noticed, digital organizations are building more and more APIs. ProgrammableWeb tracks more than 23,000 public web APIs at the time of writing, and the API market is estimated to be worth $5.1 billion by 2023. Building with APIs increases internal interoperability, reduces development time and can extend product functionality tremendously. In short, the value of APIs is rising. However, opening up with APIs brings security caveats that, if not addressed, could result in serious breaches that negate these benefits.

    I recently spoke with Roey Eliyahu of Salt Security to get his take on the top security concerns for API-enabled companies, and how organizations can safeguard their services. In short, he recommends thoroughly cataloging and understanding your API inventory, designing for legal challenges and mitigating OWASP’s top 10 API security vulnerabilities.

    Challenges for API Security

    APIs have been called “the next frontier in cybercrime.” Rightly so, as API breaches continue to pop up nearly every day. Take the recent API vulnerabilities at Cisco Systems, Shopify, Facebook, U.S. presidential campaign apps, and GCP as evidence. The most infamous was likely the Equifax breach—not enforcing formats on incoming API calls resulted in a massive data breach, which cost the company a $700 million lawsuit.

    So, why have API breaches increased recently? Well, a few years ago, there were simply fewer APIs. And, these older services exposed less sensitive data. Nowadays, companies typically have many more APIs. Banking applications, for example, might expose hundreds of highly valuable endpoints that are very appealing to hackers.

    Companies also build APIs for different audiences: A 2020 study by SmartBear found 72% of companies develop both internal and external-facing APIs. These APIs could easily hold hundreds of parameters, and with every new method added, a company’s potential attack surface grows considerably.

    3 Steps To Secure APIs

    To mitigate the above API security issues, Eliyahu suggested three main steps: Understand your API inventory, audit against privacy policies and data privacy regulations, and track the most pressing API vulnerabilities like a hawk.

    Know Your API Inventory

    “You need a great inventory of APIs to know your attack surface,” said Eliyahu. Many API providers document their APIs with OpenAPI definitions. But, these files don’t always match the production realities—they may be manually generated or leave out certain methods. “In every organization, there is up to a 40% gap between APIs that are actually deployed versus what has been inventoried,” he said. By maintaining a clearer API inventory, organizations can avoid unprotected shadow IT.

    Include Legal Auditing

    A change to an API could result in a change in how it collects user information. Updates involving sensitive data could break privacy policies or regulations such as GDPR. “After you have an inventory, you need to map all parameters manually,” said Eliyahu. He recommended performing a legal audit against your API inventory and establishing a repeatable testing process that plugs into a continuous delivery pipeline.

    As API teams release new updates, they must consider security and legal implications earlier on in the development flow. “Now, with CI/CD, these changes have to happen very frequently,” he noted.

    Watch the OWASP API Security Top 10

    There are many known API security gaps. For example, there may not be proper authorization in place, keys could be exposed, unexpired tokens could be hijacked and so on. Thankfully, OWASP has compiled a resource of top API security vulnerabilities, which Eliyahu and many others in the API economy have rallied behind. “The world should move to adopt the OWASP issues,” he said. These vulnerabilities are as follows:

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

    Using AI To Go Beyond ‘Whac-A-Mole’

    Plugging these above holes is a good start. However, these are only defensive measures against known patterns; they aren’t helping you keep guard for nuanced attack types. Ideally, security systems should stop cyberattacks before they even get started.

    Yet, Eliyahu recognizes a big gap in how APIs are monitored. Organizations “don’t have proper tools to know who is looking for vulnerabilities,” he said. “Tools are typically not that advanced. They mainly look for injections and known patterns.”

    Imagine a hacker probing an API. They will likely do so by trial and error, testing undocumented endpoints, sending malformed requests and so on. “They need to probe for hours or days before they find something,” said Eliyahu. If an AI could detect these odd attempts in minutes or seconds, IT could significantly reduce risk.

    Security solutions should thus leverage big data and AI to create baselines of typical behavior, then deter malicious activity the millisecond any nefarious probing begins. Eliyahu said such a security AI must consider dozens of behaviors such as, How is the API being accessed? What parameters are being used? What are the relationships between parameters? What is the flow of API calls? What type of data can be exposed?

    Instead of waiting for a breach to occur, an AI-enabled API security monitoring could instantly pause behavior deemed “out of the norm” by referencing a knowledge base that’s constantly refined using machine learning. Because, if you are only blocking malicious actors without knowing how you need to improve API security posture, “you are just playing Whac-A-Mole,” said Eliyahu.

    DevSecOps Requires API Security Forethought

    Mark O’Neil, analysis at Gartner, predicted that by 2021, 25% of organizations with public APIs will have discontinued or rebooted their public API strategy, citing security concerns as a common breaking point. APIs are now at the core of many application developments. Yet, without the proper DevSec proposition, teams risk wasted efforts and costly breaches.

    To summarize, here are our tips on API security:

    • Ensure everything is well-documented: API inventories cannot be audited if undocumented. Shadow APIs increase the likelihood of an attack.
    • Watch the top 10 OWASP vulnerabilities: These points are foundational to API security. Though not a cure-all, they present a starting point.
    • Build a security and legal review process: Ensure APIs are never deployed without the proper security review. Create validation systems that plug into continuous development processes, so new versions are never breaking privacy policies.
    • Each API is unique: Another thing to keep in mind is each API is unique. Therefore, API security monitoring also requires more context into unique business logic.
    • Continuously monitor your APIs: Continuous search for anyone looking for vulnerabilities.
    • Remove deprecated APIs: Remove old API versions. “You need a mechanism to identify and remove old API versions.” Otherwise, “zombie APIs will bite you!”
    • Learn from the attacks you block: Don’t just play Whac-A-Mole. “You need a mechanism to learn from attacks you block.”