OWASP Security Risk #3: Insecure Communication
We’re back, ready to explore another important security threat to edge applications—known, in OWASP Mobile Threats parlance, as Security Risk #3: Insecure Communication.
The form of communication that we’re addressing here is any kind of data transfer between edge applications (software compiled to run on tablets, smartphones, IoT devices, medical devices, etc.) and enterprise data and application services that serve as systems of trust for such software. These communications can involve a range of protocols—think TCP/IP, Wi-Fi, Bluetooth, NFC, audio, infrared GSM, SMS and others. And the data they manifest — sensitive transactional information, private user information, account details and the like—can be dangerous in the wrong hands.
And, yes, the wrong hands can intercept many of these communications—on a local wired or Wi-Fi network, on a mobile carrier’s network, or even using malware installed on the edge device. If the data can also be read—because it’s unencrypted, or because the encryption has been compromised—the risks are significant.
For individuals, the dangers include account theft, identity theft and other forms of fraud. For enterprises, risks include financial exposure, possible legal liability, undermined trust and degraded brand reputation. The danger can arise in a wide range of scenarios. A common example occurs when an enterprise user uses a corporate app, installed on a BYOD mobile device and connects to a public Wi-Fi network, to send and/or receive sensitive data to and from an enterprise data service or application.
Conventional Defense
To protect these kinds of communications, many edge apps use Transport Layer Security (TLS) encryption—but, too often, only use it at the authentication stage, leaving other data exposed. As BYOD and IoT scenarios proliferate, device-focused management has become less practical or even infeasible, forcing many enterprises to rely on app developers to properly implement the necessary security policies by coding it—which consumes valuable time and leaves room for potentially costly errors.
The Blue Cedar Difference
Blue Cedar uses two strategies to secure these communications: access control and secure microtunnels.
- Access Control. We start with the assumption that, if an app is going to touch sensitive enterprise backends, then it must first authenticate end users and check for acceptable device and app integrity conditions (e.g. OS version, device jailbreak state, presence of other apps, etc).
- Secure Micro tunnels. Only if the app passes access control checks will Blue Cedar allow communication with the requisite backend application and data services. Additionally, Blue Cedar security controls implement communication encryption, no matter what, for every potentially vulnerable communication. To achieve this, each Blue Cedar-secured app sets up a secure microtunnel—an app-specific VPN with its own encryption algorithms—for each session where the app connect to high-value and/or high-risk backend systems, be they cloud-based or on-premises.
As always, after Blue Cedar integrates the necessary security policies into the app, after which the app can be distributed via normal channels (public or private app store).
Meanwhile, app developers will have saved days, even weeks of time, excused from the chores of writing encryption-related code (and relieved from the risk of making a mistake). And TOP 10 OWASP Security Risk #3—Insecure Communications—is a risk enterprises won’t have to incur.
We’ve now covered two of the big 10: Insecure Data Storage and insecure Communication. Next, we’ll examine what happens when well-meaning encryption efforts fall short, as we examine Risk #5: Insufficient Cryptography. In the meantime, you can still see a personalized demo of Blue Cedar. Reserve your spot today, and we'll take you through a deep dive of our technology.
