• contact@isoagroup.com
  • (707) 773-1198
  • Building a lasting foundation for the digital enterprise.
May 9, 2024 Cheryl Bertini

Modernization’s Double-Edged Sword: How APIs Drive Innovation and Expose New Cyber Threats

An Interview between iSOA Group's, Brian Silverman, and Tempus Network's, Paul Robinson

Brian: Paul, thank you for joining me today. As the founder of Tempus Network focused on improving cyber security and trust by connecting clients and providers, your clients are keeping you quite busy helping them keep focused on cyber security and the challenges companies face as they grow in the digital economy!

As companies modernize, the more they connect to the cloud, to their customers, to suppliers and partners, they create new opportunities for cyber thieves to attack, steal data and credentials, which can lead to identity theft, ransomware attacks, and more. 

These connections have led to APIs (Application Program Interfaces) becoming the telephone line for the digital age. APIs make it easy for developers to modernize applications within an organization, linking legacy applications to more modern ones. APIs enable organizations to extend their services to their customers and partners and consume external APIs to incorporate their services into their own innovative applications.  

APIs, are the fuel for the new breed of AI, by providing access to the data and information that turns Generative AI into fun chatbots and recipe makers to tools for business that accelerate innovation and customer service. 

As you know, and as Gartner predicted in 2021, APIs have become the top attack vector for cyber criminals. The same connectivity they provide is also a door opening for attacks when not secured properly. 

Brian: Paul, how have you seen the API landscape impacting the companies you work with? Whether in their cyber planning to protect their organization, or their own development of APIs for internal and or external use? 

Paul: Over the last 6-12 months API discussions have increased at a rapid pace. From a functioning perspective the ability to innovate business and improve productivity has organizations clamoring for this protocol. This has proved to be somewhat of a nightmare situation for security teams because of the speed at which API’s are being developed and their lack of visibility into the process. 

Brian: How are you seeing the cyber tools and solutions evolve to protect and support APIs? WAFs and Gateways intend to protect the APIs, but are you seeing more focus from vendors you work with? 

Paul: There are several tools that have come out recently that specifically address API’s, as well legacy tools adding this to their stacks. The challenge inside of this developing piece of the industry is there are several ways to protect API’s in development and production and a lot of organizations lack the strategy to know what they need and what they don’t. 

Brian: I know, professionally, you work with clients looking to strategize and implement cyber strategies and protections.  You have mentioned working with MSPs and other IT providers that are expanding their support for cyber protection for their clients. Are they looking at the risk of APIs? 

Paul: Yes, you are starting to see more MSP’s bring this up in discussions with clients and prospects. The MSP’s that are most successful are guiding their clients through the process and not coming out of gates throwing technology at the problems. 

Brian: APIs are unique, in my mind, we always want the cyber security teams talking to regular IT about the security requirements, but it does not always happen until there is an attack or crisis.  

For internally developed APIs, the cyber team can detect potential vulnerabilities, but it is the actual developers and IT that need to update the APIs.  

Are there best practices in your mind, as how cyber teams can more easily team with their IT colleagues? 

Paul: The adage of you have two ears and one mouth, comes into play here. I have been at many IT and Security meetings where they got very contentious and shouting matches would ensue. In most cases, the application/dev team wants to “go,go,go” and the security team wants to slow down and make sure everything is correct. In the end, both sides want the same thing: The application team does not want their environment to be compromised and the security team wants the application to develop quickly because it usually correlates with business success. The best thing to do in these situations is to listen to what the other side is saying, not to debate but to understand. From understanding comes a meeting of the minds and success.  

Brian: APIs can spread like rabbits. APIs can be developed by rogue IT within an organization to support a particular offering or client. They can be installed with software to be accessible, providing APIs that make it easy for other applications to talk to them.  

Any thoughts on how companies can manage the spread of APIs beyond traditional IT and cyber teams? 

Paul: Process, Process, Process. You are absolutely correct in your assessment on the rapid pace this environment is. When the meeting of minds happens, a key outcome for this is to agree upon rules of engagement and a process that everyone is accountable to follow. Once this is in place and roles and responsibilities have been clearly defined, there are some tools out there that can help automate this process. 

Brian: APIs also come from the outside. It can come from vendors, such as Salesforce and other cloud application providers, it can also come from partners and suppliers as well.  

One example I read about was a WordPress plugin to Stripe which unknowingly exposed a vulnerability in the Stripe API. This was not a path I would have thought of as a potential attack vector, but this certainly would be for skilled cyber thieves. 

Are you seeing best practices or ideas around security and protection from those APIs? 

Paul: You have touched on another real problem in the industry, which is third party risk. Most incidents that take place come from a misconfiguration or a pinhole from a third party. When inviting a vendor into your company, it is important to have a streamlined process to know what potential changes can take place with the technology introduced. Unfortunately, this is not a 100% foolproof solution, however the more attention you pay up front to the potential risks, the less likely you will have problems on the back end. 

Brian: So, the API landscape is constantly changing. As you know OWASP has the top ten API attack threats that they share, and many API Security vendors focus on these at the types of attacks and vulnerabilities to track. To be honest, I wonder what companies can do to keep their eyes open for different API attacks that are not in that “top ten” or will be in next year’s “top ten”? 

Paul: This is one of the most challenging matters to deal with. I would follow reputable cybersecurity news feeds to get the latest news. I would also find trusted peer groups to collaborate. Another measure you can take is to lean on your vendors that are protecting this environment to make sure they are updating their tools, to protect you. As API’s become more popular, the more the criminals will be apt to create zero-days for them.  

Brian: At iSOA Group, our consultants are focused on the full API Lifecycle development, integration, running and security. It seems to me, the only way to ensure security and trust of APIs is to not look at these areas along with security as siloes but look at them together. For Example, if API Security is detecting rogue or unmanaged APIs, to secure them they need to be incorporated into the overall API Management strategy provided by the broader IT organization. 

Do you have any thoughts? 

Paul: I think this could be a case-by-case situation, based on the organization. There are a lot of politics involved in organizations. In a perfect situation, the CIO/CTO and CISO are constantly communicating and working together on this issue. That is not usually the case in most organizations. I think this is an opportunity for many organizations to break down the barriers between the groups and work harmoniously together. 

Brian: It seems that many companies are defending against attacks vs trying to fix vulnerabilities in-house.  There is a Verizon Security report where APIs are hardly mentioned.  If you are protecting against DDOS attacks, phishing schemes, and ransomware attacks, it seems like the tools for defense, including WAFs, Firewalls, and monitoring tools such as SIEMs, are in play more than identifying vulnerabilities within APIs an organization is providing or consuming.  Would you agree?  and is this the right posture? 

Paul: It is a good question to end this discussion, as traditional methods of security can only get you part of the way there. This isn’t gospel and there are various opinions here but the only tools that can work here are purpose built for API’s, that provide end to end protection 

Brian: Paul, thank you for your time. I know you are quite busy as all cyber professionals tend to be. Any last thoughts or predictions for the future of APIs and Cyber? 

Paul: As a security professional, sometimes I, along with my counterparts, point to the negatives when it comes to innovation and growth in technology. The fact of the matter is that growth in the API space is a good thing. It is going to help organizations innovate, grow and help applications flow easier. As with anything, it is important to understand the risk inside of that growth and define what risk the organization is willing to accept. It is all about “safely enabling” business and by doing so it puts everyone in the best possible position for success.   

Brian: As always, I appreciate your insight and thank you for your time and consideration.  I wish you continued success at Tempus Network! 

, , , , , , , , , , , , , , , , , , ,