Relying on ambient knowledge as you develop mobile systems always carried a risk of surprise. As teams have turned over in the great resignation, development has become fully distributed, and regulators pay more attention, the tacit understandings we relied on must be augmented with more structured and systematic approaches.
Ambient information is the shared knowledge that people have when working together on a project. When everyone was working in the same location, ambient information had more channels through which to spread. was more available visible. People would chat about what they were doing, the projects they were working on, and the problems that needed solving.
When people think of the term “ambient,” they’re probably not thinking about information, software development, or GRC. The dictionary definition of ambient either refers to something existing on all sides or an all-encompassing atmosphere.
Software development projects have a lot of ambient information. The people involved in the project talk to each other to understand dependencies and processes. With remote and hybrid software development teams now the norm, creating secure, compliant software for mobile devices means making this ambient information explicit, or as I like to call it “crisp.”
Moving from Ambient to Crisp for GRC
While ambient information., but it’s never been great for either security or compliance. Compliance requires documenting everything, proving everything, and reviewing everything against various standards. Compliance requires repeatable processes that give you consistent outcomes. Ambient information is great for collaboration and innovation, but its incomplete and inconsistent nature makes it a challenge for compliance.
When software developers work together on a project, they need to put in the work that makes this ambient information explicit. It can be daunting to treat that work like everything else, providing justification and prioritization. However, in the long run, creating crisp, well-documented processes lead to better agile practices that focus on reducing problems at a reasonable cost.
Using Threat Modeling to Get to Crisp
Threat modeling is a way to create a structured, formalized process for having these conversations. It creates a formal place where you can draw a diagram then think about who owns the other services. Then, you can talk to those owners and start analyzing the dependencies.
With software-centric threat modeling, you create a common understanding even before you get to looking for threats because you’re creating a comprehensive model with an explicit list of common assumptions. These lead to a substantial improvement in the components’ security.
Beyond that, this crispness also empowers and uplevels your compliance because now you have the documentation that proves you:
- Reviewed and accounted for threats that can create a risk
- Documented your justifications based on your risk tolerance to prove governance
- Followed best practices as required for secure software development lifecycle requirements found in most compliance mandates
Threat Modeling for Mobile Threats
Between remote work and customer expectations, almost every large organization is developing a mobile app or apps. Companies aren’t able to control mobile device security in a world of Bring Your Own Device (BYOD) so you need to focus on pushing out the most secure mobile app possible.
Mobile app threats are generally similar to traditional software threats. Anyone who can deploy malware and run code on the device can read your files or use the stored authentication data. When you’re developing a mobile app, you can use the same threat modeling techniques that you would use for traditional software.
For example, with mobile apps you still face spoofing threats, like account takeover, if you don’t have the right authentication and authorization controls in place. Even worse, with mobile apps you potentially have two remote spoofing, or phishing, threats:
- Web app level: some users may use the browsers on their mobile devices
- App store level: app falsely claiming to be yours
The threats that we can come up with are broad. No one knows your app like you and so you can assess how your app is under threat. For example, you can consider creating of list spoofing by/of an external entity which could look something like this:
- Goal: Login as a different user
- Technique: Remote Spoofing (phishing)
- Explanation: Browser-based app presents as a different site, including its login page
- Developer mitigation: Implement reputation services such as Google Safe Browsing
- Operational mitigation: Implement reputation services that that search for trademark or brand abuse
With threat modeling, you have a structured approach that reviews potential threats and documents them. You’ve taken that ambient information and made it crisp.
Threat Modeling Leads to Security which leads to Uplevel Compliance
Compliance is not security, yet security leads to compliance. If all you’re doing is checking off audit boxes, you might pass the exam, but you may have only put a random collection of defenses into practice. You need to build your security program to rationally address threats. compliance program on a foundation of best security practices.
Shifting security left means incorporating threat modeling during the software development lifecycle and taking potential threats into account. It also gives you the documentation you need to prove that you’re securing your software and documenting your activities. When you’ve done that, it’s easy to give your auditors what they need so you can pass. And more importantly, deliver safe products to your customers.
