Securing apps is vitally important.
Your users are trusting you with their data and transactions and you can’t afford to betray that trust. Worst yet, you yourself can’t go down due to malicious actors. You need to make sure your process secures your app from the frontend to the backend and everything in between.
Know all the interfaces, all the access vectors, tools, people involved.
Using that, create an inventory and go through each item one by one and analyze all possible attack vectors in-house, external, etc.
When you research every single of those interfaces, let your team know that you're doing that right.
A company should ensure these interfaces constantly communicate with each other, they ID each other and make sure that only the necessary amount of information flows through those interfaces.
The entire system has to be up to date and constantly checked regarding exposure to the internet, vulnerabilities, scams, and attacks.
The device is the weakest link. You have the least control over it. You can’t know if the app was installed correctly if it is on a jailbroken device if the OS is up to date etc.
In case the device is compromised or stolen, make sure username/password credentials are not stored on the device.
Every bit of data exposed at an endpoint needs to be there for a reason. You don’t want someone using that data for anything else.
One example is how someone used information available on Amazon to trick the Apple support into resetting an ID.
You can try to obfuscate as much as you want, but at the end of the day, obfuscation is not security.
There's not much point in hiding the API. It is public-facing, people need to know how to onboard the app and understand what the app is doing and what kind of calls the app is sending to what endpoint.
This is why it's good to just focus on making sure it's a secure connection making secure communication to a controlled setup while exposing as little as possible in the API.
There are many ways to secure HTTP communication and prevent Man in the Middle Attacks and make sure you are talking to the right endpoint.
There is SSL pinning and other methodologies. It's a very established and value researched environment which makes it very secure. It is also a well-known and understood protocol.
This also increases the risk so you need to obfuscate and also know which protocol you are using and why. It's very hard to prevent someone from sniffing network traffic using Charles Proxy and it's also difficult to prevent someone from downloading the APK (if its an Android app), disabling certificate pinning (or changing to the desired certificate), and compiling it again and there you have a jailbroken device.
(Even jailbreak detection can be skipped by manipulating the execution of the application at run time). By having tight security protocols, API Data frugality, and obfuscation in place, you create a much more secure system.
Supply chain attacks appear in the news frequently, whether it is the SolarWinds or the Kyesa attack that took down half the supermarkets in Sweden.
The best way to deal with it is to be aware of the need to assess vulnerabilities of your vendors, your libraries, and your third-party integrations and applications that you use in the context that might have access, or might be able to have access to your system.
This also includes the dependencies used in GitHub. You need to have a way that when these vulnerabilities do come up, they come to your attention. Because often, as in the case of a vendor attack, you nor your vendor knows until you are locked out!
You need to have multiple layers in protection in place anyway. What is your first layer? Second layer? Etc. It goes without saying that you need to have a good backup strategy. A good backup strategy entails:
Include Coach Reviews, Porter Requests, and Checklists.
Security needs to be on everyone's mind throughout the development cycle - not just for those on the cyber specialists.
This will help raise awareness about security and ensure security has been scrutinized throughout.
Automated checks using tools should be a continuous part of the CI/CD system.
Some tools provide static code analysis as well as tools offered by cloud providers to detect vulnerabilities in both dependencies and images. The information generated by these tools should be constantly checked and reported to the right teams.
It is valuable when an external party reviews the code infrastructure and conducts pen-tests.
Just being from outside the organisation allows for a different viewpoint and also background and experiences. The yearly pen-test is partially automated, but also quite manual in its attempt to break the system.
Frequent system audits (conducted externally) also make sure there is no regression. Sometimes just getting this external assistance is a huge help as, especially in small companies, the CTO is bogged down in so many other areas, having someone with more headspace conduct these audits on their behalf is helpful.
It is helpful that someone aware of what is being discussed in the hacker community reviews your code.
This article was based on an alphalist.cto podcast episode featuring Andreas Schranzhofer, CTO of Scalable Capital. The alphalist podcast is a podcast for busy CTOs, VP Engineering and other technical leaders. The alphalist podcast features interviews of CTOs and other technical leaders and topics range from technology to management. Guests from leading tech companies share their best practices and knowledge.
This article was first published on Alphalist.cto