TMI Tech: How to Stop Vulnerable Software from 'Oversharing'

We are more connected than ever — but far less so now than we will be: There will be 3.6 network devices for every living person in the world by 2023, up from 2.4 per person in 2018, according to the Cisco Annual Internet Report. The number of networked devices will rise from 18.4 billion to 29.3 billion within that time. The number of machine-to-machine (M2M) connections will increase from just over 6 billion to 14.7 billion.

As a result, we will grow only more reliant on software to make everything work. The performance of application programming interfaces (APIs) greatly affects software’s overall effectiveness. Whether we’re online seeking a weather update, participating in an industry webinar, sharing docs with colleagues, or calling up medical lab test results, APIs enable two software components to talk to each other to both make user requests and respond to them.

But, in this case, it’s possible to have too much talking between APIs which, like gossipy chatterbox co-workers in our offices, will overshare “too much information” if we let them. We call this “TMI tech.”

By design, APIs open the floodgates for communication between apps. When the risk-mitigation measures of their access control are lax, APIs will reveal too much information or — even worse — expose themselves through a vulnerable app backdoor. Too often, developers over-permission APIs for functions so they don’t have to keep changing access rights with every program build. However, attackers are well aware that this is happening, so they take over APIs and leverage their powerful permissions to breach networks.

As a result, oversharing APIs are emerging as frequently targeted, low-hanging fruit: The Salt Security State of API Security Report indicates that one-fifth of organizations have experienced a breach due to compromised APIs. Malicious traffic accounts for 2.1% of all API traffic, growing from an average of 12.22 million malicious calls per month to 26.46 million calls. The Open Web Application Security Project (OWASP) lists broken access control as the top Web application risk — over cryptographic failures, injections, and misconfigurations.

Recommended Best Practices

So, how do security leaders and their teams avoid these issues? We recommend the following best practices:

• Upskill developers to cultivate a “security first” culture. It’s critical to educate developers about the nuances that differentiate a poor coding pattern from a good one, to help them focus on building safe software from the start. When security teams strengthen their communications and relationships with developers, those developers learn how to use the right tools for protection and even maximize their value. Hands-on/person-to-person training proves essential here. Computer-based training by itself comes with too many limitations, often lacking the ability to verify the security skills of participants.
• Practice real-life scenarios. All training programs must include this. Developers benefit the most by experiencing the real-world scenarios and consequences of broken access control – it’s the most potent way to both verify and improve skills.
• Extend zero trust (ZT) to APIs. We typically consider ZT in terms of user access. But we should apply it to APIs as well to eliminate over-permissioning and enforce role-based controls. If an API is supposed to perform a specific function, then security teams must work with developers to restrict permissions to solely that function.
• Contain API “phone privileges.” In further incorporating ZT, security/developer teams should limit the calls APIs are allowed to make, so these calls are strictly conducted based upon context-centered requests. Subsequently, attackers will encounter difficulties in modifying them for criminal purposes.

Training Is Key

Whether dealing with real people or software, we should take oversharing seriously. Those gossipy chatterbox co-workers could cause very real damage in the office, after all, which is why HR needs to sit down with them to firmly enforce what is appropriate to discuss and what is not. In the same office, we don’t allow Sara from accounting to snoop around freely in the legal department and download whatever documents she wants.

Similarly, we have to train developers on “security first” while subjecting APIs to least-privilege ZT policies. With this, software will share only what is necessary to perform set tasks, and the elimination of TMI tech will firmly seal off our office “door” — and the network and all digital assets — from attackers.