Zero Trust says “assume breach” and your response plan must cover handling third-party security incidents too. Mobile apps depend on third party APIs, and you need to be prepared to act quickly if a service you depend on has a security incident. This blog discusses what you can do to maintain mobile app service continuity when there is a security incident, especially if it's not your fault.
There is a lot of truth in the phrase: “Hope for the best, plan for the worst”. You need to do scenario planning for when things go wrong and rehearse thoroughly the procedures you will follow if and when there is a breach. NIST helps with guidelines for this. A good example of not being prepared was the recent breach of 23andme - the overall impression was that they didn't have a solid incident response plan in place.
If you have prepared your Incident Response Playbook you will recognize the words in the title of this section. This is the essence of what you need to prepare to do when something goes wrong.
Your playbook must be detailed, and if you have mobile apps, these details must extend to response and recovery of mobile app incidents.
However in the guidelines and advice about incident response scenario planning, you won't find specific information about mobile threats or how to respond and recover from them so you will need to flesh that out yourself.
So what about mobile apps specifically and especially what about when something happens that is not directly under your control?
The most nefarious mobile attacks are when a hacker weaponizes your mobile app and uses it to scale up attacks on the APIs you use. In order to carry out these attacks, all hackers need are API Keys which they can then use in scripts or modified apps.
API keys are notoriously easy to extract from app code or find in on-line code repositories. They can even be harvested via MitM attacks which intercept and inspect requests from the communications channel to your APIs.
You can make it easy for hackers if you have poor discipline about storing these keys in your app code or if the comms channel to the API is insecure and open to MitM.
But let's assume you have taken steps to protect everything under your control: You have taken steps to prevent exposing API keys in your app and you protect the channel by using the most recent encryption and employing certificate pinning. Let's also assume that you give some serious attention to the security of any cloud services and repositories you use to keep your own API keys from leaking.
Even with all this in place, you should still, of course, have a contingency plan for if your secrets are stolen.
So far so good, but you may still have to respond to and recover from bad things happening that you don't control. What about when API keys you use are stolen because of someone else's negligence. What if the certificates you use to encrypt traffic are acquired elsewhere?
This is not a theoretical exercise: next we will look at real recent examples and specific issues - and then we will cover some easy wins to be ready to ensure service continuity if hackers steal secrets.
Our first example concerns DigiCert. On July 29th 2024 Digicert, a leading Certificate Authority, announced that they needed to revoke and replace some certificates due to an issue related to the process used by DigiCert to validate that a customer requesting a TLS certificate for a domain is actually the owner or administrator of that domain.
Digicert announced that this concerned only a small percentage of domains and certificates, but for the unlucky owners of affected domains it meant immediate certificate rotation was required.
Our second example concerns the Dropbox Sign API. Dropbox Sign is a service that allows individuals and businesses to sign, send, and track contracts and other documents using embedded eSignatures. Dropbox announced that on April 24th 2024 they became aware of unauthorized access to the Dropbox Sign production environment and that in fact Dropbox Sign customer information had been accessed.
In the communication, Dropbox told API users - "If you’re an API customer, to ensure the security of your account, you’ll need to rotate your API key by generating a new one, configuring it with your application, and deleting your current one. As an additional precaution, we’ll be restricting certain functionality of API keys while we coordinate rotation. Only signature requests and signing capabilities will continue to be operational for your business continuity. Once you rotate your API keys, restrictions will be removed and the product will continue to function as normal."
Changing and redistributing your mobile app when something bad happens is a disaster for customer satisfaction and service continuity so you need to take every step you can to avoid this when issues occur.
But when your Certificate Authority announces certificates need to be rotated or a critical service you use tells you to immediately rotate API keys what do you do?
You need a plan, processes and tools in place to be able to react when these things happen.
Most important is ensuring service continuity and this should drive your choice of security solutions.
With Approov in place, all secrets are stored securely by the Approov cloud service and are easy to manage dynamically. Certificates, pins, and API keys can easily and immediately be updated across all deployed apps. In this way, if secrets are ever stolen from cloud repositories or acquired through other means, or if a third-party API used by your app changes keys, they can immediately be rotated without any service interruption and without having to update apps.
For the Digicert and Dropbox examples above, Approov would make certificate and API key rotation simple and immediate: your service can continue seamlessly. Your devops team will love this and it also simplifies your Incident Response Plan.
Of course the primary role of Approov is mitigation of risk in the first place. With Approov, every time there's a request to the backend APIs, the Approov SDK checks the authenticity of the app and it analyzes the runtime environment for hooking tools and dozens of other potential threats in the device environment. The Approov service then decides whether everything is OK and passes a token back to the Approov SDK which then integrates that into the request to the back end. All communications are encrypted and pinned and everything is logged and monitored. In addition, rogue devices can be identified and blocked in real time.
Because of the unique way Approov can get attestation information about the device and the application, API keys can be delivered just in time to the application but only when the device and app are verified as genuine and unmodified. In this way, secrets are always secure and never appear in your code.
When incidents affecting your app occur, blaming other parties is not a solution: this will backfire and just draw attention to your own dependence on third party services, and your own lack of rigor and preparedness.
In fact, you must make sure your breach and incident response planning extends to breaches you don't own, and your playbook includes specific information about rotating third-party API keys, as well as any other secrets and certificates your app uses. You should also include procedures on how you can quickly block rogue devices and apps without affecting genuine users.
Finally, always ask how the security solutions you are evaluating will simplify your Incident Response Plan.
Approov are experts on mobile app security. We would love to talk to you about your particular use-case.
