Securing APIs from becoming the New Shadow IT

In our previous blog, we tracked the history and trajectory of APIs and how they came into being. 

APIs define the roadmap of an application and become direct contact for sharing data. The exposure to vulnerabilities via the grained access have multiplied with time with developers creating an open architecture for sharing the functionality to meet the need for scale. The increased dependencies soon became a habit. And as we know, old habits die hard. 

As predicted by Gartner, the largest source of data breaches will arise from APIs by 2022.

This brought APIs the ill fame of becoming the new Shadow IT since security was being ignored in the whole process of leveraging APIs. It was impacting organizations in terms of entrusting them with critical information. 

In this blog, we will address the rise of Shadow IT, how APIs impact the security and how you can avoid the security breach. 

What is Shadow IT?

When a piece of information related to technology is utilized or managed without the knowledge of IT departments within the organization, it is termed as Shadow IT. It is considered as an act of taking actions on behalf of the knowledge/IT team. In recent times, people adopted cloud services and the growth of shadow IT accelerated, i.e., users downloaded the services without prior expertise or technical know-how of the product. 

Departments like marketing, finance, and sales started coming up with their own solutions and software that could assist them in their work. 

CEB estimates that 40% of all IT spending occurs outside the IT department.

The visibility of the organization’s data increased with each new application that enabled access without the IT team’s involvement. Also, the lack of a standard security check was found missing upon intervention. On the positive end, shadow IT seems to be helping the businesses in becoming more competitive and employees more productive. For instance, using SaaS applications improved the communication systems within the organizations without needing IT department’s help. 

Can API Security Impact Enterprises?

2018 saw a lot of cases where the illegally extracted data or security breaches listed APIs as the prime culprit. 

As we know, the metrics used to secure the web doesn’t work the same way for securing the APIs. They are fundamentally different and possess different risk factors that need to be managed by the enterprises. 

Also, there are often undiscovered APIs that pass the traditional security mechanisms and run on ephemeral infrastructure in the public cloud. There had to be a new path of solutions.

Thus, the business-critical data that is used to build an API need to be tightly protected with the best of security tools and practices. 

Solutions

Here are some tips for organizations to help keep their APIs secure:

#1 Sanitisation of Parameters

Keep your APIs free of germs(bugs) throughout the implementation. 

The process of sanitization makes the data schema restricted and permissible for only a certain kind of inputs. This can be done with hand-built schemas that are using typing, ranges, sets and explicit whitelisting. Constraining the structure with limited inputs further helps in developing APIs that are not prone to potential threats. You can either use the XML schema language or the JSON schema description languages, the latter being simpler to compose and understand, making it simpler to secure.

#2 Put yourself in the shoes of a Hacker

Staying one step ahead of the potential hackers is the key. Think how a hacker would try to breakthrough to access your data. If organizations put into context this guiding principle, they can build APIs with minimum data and highest of security right in the development of the interfaces.

Designers and developers often get trapped into opening gateways to hackers by wanting to create more and developing faster APIs. The design should be the most crucial part of the process where the focus on security is maintained throughout while designing a web interface. 

The infamous British Airways data breach case where 380,000 card payments of 45 million passengers were leaked, was a disaster on the API systems’ end. 

It is a learning lesson for the companies that deal with such critical cases and are endowed with user-sensitive data. 

#3 Think about Access

Prepare in advance about the degrees of access for users. Determine the exact kind of access for developers too. 

In the case of Twitter, a bug in the API exposed user’s private messages to third-party developers. One minor bug affected about three million active users and brought their privacy under threats. 

Therefore, enterprises should look into use cases and their vulnerabilities while building APIs and creating security. 

#4 Mandate Security Training 

Invest in the training of developers from the very beginning to build a proactive team that is diligent to minimize security threats. 

Many enterprises do not want to spend on training due to employee retention cases. However, it is for their own long term benefit. It is better to invest in the training than afford a security breach of business-critical data at a later stage. 

Maintaining a continuous monitoring process during and after the completion of an API can also help in leaving no loopholes for hackers to breach your security walls.  

#5 Other Threats

Apart from the schema threats, there are common attack signatures, like SQL injection or script injection attacks. 

Also, there is a network-level denial of service (DoS) assaults. Since they follow a common pattern, it gets easy to spot omissions via scanning the raw input. 

DoS attacks are capable of exploiting parameters. DoS consumes resources on an API server affected due to very large messages, heavy and overly complex data structures. 

Organizations can invest in virus detection services that protect risky encoded content. 

#6 Make SSL a Rule 

When established as a mandate, the SSL/TLS will serve as a basic requirement. It will effectively defend your APIs against the risks and provide integrity on the exchange of data. During a transaction between a client and a server, the SSL/TLS will authenticate it with certifications too. 

#7 Tested Solutions 

The method of inventing the wheel doesn’t work when it comes to security. There are many already existing API security frameworks available at your disposal. Creating your own will only increase the cost and time for the enterprise. 

Start with logically separating the implementation of the API from the security of APIs by segregating them into different service tiers. This provides the developers with a narrowed focus completely dedicated to the application domain, designing the API and its integration between different applications. As for security, that’s a domain for experts focusing on threats and data breach issues. 

Security via API-led Connectivity

On a different note, enterprises can adopt an API-led connectivity approach for managing a defined connection and exposing assets with APIs. 

In this approach, the asset itself becomes a managed API and is discoverable through self-service. It will secure the design as the nodes are connected via standardized and well-defined APIs. Debunking the point-to-point connection, the security measures actually happen in each service developing group.  

When teams build products on the already existing networks of APIs and reuse them for connectivity, they contribute to the API nodes which in turn secure your critical assets. 

Conclusion

Organizations need to learn and constantly adapt to the advancing technology. In the rush of developing APIs, the importance of security often gets neglected. There is a dire need to recognize how API might turn into the new shadow IT and it starts with the identification of any kind of potential breach. IT can only help you till you help it with the accuracy of data and by adopting the best of industry practices.

Share your views on our social channels: Twitter, LinkedIn, and Facebook.