As seen on Hospitality Net.
Buying an airline ticket, hotel room or car rental today involves a network of APIs that connect everything together. Customer expectations and newer digital business practices demand that hospitality companies provide more seamless and frictionless experiences with visibility and accountability. APIs have long been a staple for hospitality technology, enabling the rise of travel portals and booking sites, along with enabling loyalty programs or connecting various services together. Think of Application Program Interfaces (APIs) as connectors or conduits between systems, sites and applications. APIs have also been a vital bridge between Revenue Management Systems (RMS) and Pricing Management Systems (PMS), enabling processes and planning or implementation to work hand-in-hand based on real-time or near-real-time information.
Besides the existing linkages between applications and services, today’s customers are expecting up-to-the-minute status information, one-stop accountability, speed and ease. All of these factors directly tie to customer experience and can be strategic factors in ensuring competitiveness, loyalty and fostering positive word of mouth. In ensuring these experiences, multiple partners may be responsible for delivering a unified result, such as through a collaboration of a hotel, an airline and a touring company.
While previous use of APIs has shouldered risk, it has generally been considered low and not a major concern for security or risk teams. Many APIs connected internal systems and have been fully under the control of the business. Some third-party partner systems have also been connected, but these have often been considered cases of sharing specific, selected data between trusted partners so were assumed safe.
Because these APIs are given to specific known and vetted entities and strong authorization and authentication methods are used to manage them, most hospitality firms trust their proper usage. Such blind faith is increasingly misplaced, since APIs can be misused and even abused by authorized and unauthorized parties. Just because APIs are designed for a particular usage does not guarantee that they will always be used in that way. The most famous case of this is the way that Cambridge Analytica misused APIs from Facebook for their own purposes. But it seems that every day we hear about another vulnerable API used to scrape data in a low and slow attack. API data scraping is the new data breach.
Sometimes misuse may not involve any malice or criminal intent. Doing something other than what was prescribed may seem helpful, harmless or inconsequential by a partner. The original intention for an API may be difficult for a security team to ascertain, making it hard to differentiate valid usage from more subtle misuse. Other cases may involve malevolence or intentional fraud. A rogue employee at a partner site may take advantage of the access they have. These APIs can also be used by external attackers as a new—and potentially far more valuable—part of an organization’s attack surface.
Regardless of the activity or intent, few hospitality companies have the means to monitor what goes on within an API. Misuse, abuse or fraudulent activity would go unnoticed until the actual result is evident. It is also possible that some unauthorized activities may never be discovered.
Most hospitality firms do not even know about all the APIs they have in use. Some may be put in place by a department, business unit or outside consultant in the interest of advancing some business initiative and done without the knowledge or involvement of security, risk or IT teams. Some may even come as the result of application development that makes use of underlying software components, or microservices, to add functionality, lower costs and speed production. Many or most modern applications are built using microservices, and, by definition, APIs connect these building blocks of code to each other and to the overall application and the resources it uses.
Knowing which APIs exist is the first challenge for hospitality companies. Likely, existing technology is inadequate to uncover less than half of APIs actually in use. Even API gateways, API managers and application firewalls are not equipped to find business-to-business APIs in use. New technology solutions on the market can perform this task, but it should be coupled with new procedures to prescribe what kind of review process should be put to newly discovered APIs. In addition, it is important that hospitality companies maintain an up-to-date inventory of all APIs. New ones are constantly being added, and existing ones may change in significant ways.
Next, companies should implement the means to monitor activity within business—or at least high-value APIs—for unauthorized activity that might be undesired, abusive or fraudulent. Again this needs to be accomplished through a combination of technology and procedures. Fortunately, a good level of automation is available. It may also be possible to procure such monitoring and analysis as a managed service. Investigation may be necessary for some anomalies. In addition, companies will need to establish the means and procedures to terminate API usage when necessary.
While business APIs are increasingly important, and risks are only now starting to increase, it is good for companies to gain visibility and monitoring of them sooner rather than later. The threats of data scraping or a data breach are just a few of the damaging results directly possible through unmonitored, blindly trusted APIs.