Link to Question 1

There are a number of different salient details here that need some consideration. First of all, there’s the data assets involved. From the problem description, we have some that are explicit in the question (name, medical info, emergency contact info, etc.), but there’s also clearly some other data involved that the devs assumed, but didn’t mention. There’s no mention made here, for instance, of a user authentication system. Presumably there’s some kind of way for users to authenticate themselves to the app. Related to this is the interesting question of user authorization. What access should users have to their own data? Do we, for instance, really need users to be able to read the home address or medical information they’ve previously entered into the app? Or is there a way to mask that data in order avoid disclosure in case the phone is compromised. A good candidate will be able to reason about various tradeoffs here, from both a security and product perspective.

More senior candidates should be able to talk about how to deal with the fact that you have data from people who aren’t the customer (emergency contact details). Are there any additional controls that should be put in place due to the fact that the people represented in the contact details never consented to having their data stored by our system? More senior candidates should also be able to talk about the possible regulatory risk. This needn’t be in depth legal analysis, but they should be aware of what broad regulations will apply to the application in their country. (E.g. would a US company building this app be bound by HIPAA due to the presence of health information?)

In addition to user authentication, there’s also service authentication questions. How will the application authenticate the services it’s communicating with to ensure it doesn’t send sensitive customer information to the wrong endpoints. TLS is one possible solution to this. Good candidates will be able to talk in detail about the TLS configuration would look like. More advanced candidates would also be able to talk in depth about related controls like cert pinning, including the tradeoffs that cert pinning requires for operations and updates. These can get especially tricky in mobile applications. What do you do about the (non-zero) number of users who will install the app, but never update it? Does your proposed authentication system work both for the information reporting (client-initiated) and the emergency push notifications? And does that change depending on the architecture of how the push notifications are triggered?

The interviewee should also be able to take in varying levels of depth about the cryptographic requirements for the data. For Junior applicants, a strong understanding of the cryptographic primitives might be enough, but more senior candidates should be able to talk in detail about what cryptographic controls to use (including identifying appropriate algorithms) and to help design a workable key management system for the application.

Candidates should be able to talk in depth about a data sanitation and validation strategy, as well as well talk about what vulnerabilities might arise from a failure to implement it properly.

Candidates should be able to identify reasonable, actionable risks to the system, including both confidentiality risks to the data, but also be able to reason about data integrity and how it might impact customers. They should also be able to identify negative use cases for application logic and design sensible tests for them. (E.g. what happens if I can insert arbitrary users into the service with spoofed GPS codes using an emulator? What threat scenarios does this bring up in case of an emergency?)

Once we’ve identified several of the risks inherent in the system and the controls required, a candidate should be able to talk about testing methodology. Depending on the role, this might involve walking through a pen test plan, or it might just involve identifying some test cases for the dev team to include in their own QA.

More senior candidates will also have to consider a lot of areas that the devs apparently haven’t, such as Disaster Recovery or Security Operations. In other words: what happens if the natural disaster also wipes out the data center hosting the servers that do the push notifications? How do you deal with disasters that also take down power or knock out the mobile data infrastructure? What do you do when a customer who hasn’t paid their service bill is in a natural disaster where your application might help? What requirements will you have for the team for when their service is breached? What level of access will you recommend the devs to grant themselves? What insider threats do you need to be worried about and what controls can be put in place to mitigate them?

One advantage to the interviewer is that this question, though compact, covers a lot of different areas. This allows the interviewer to dig into areas that are particular to the role being considered. For a Senior Application Security candidate, I’d probably focus a lot on analyzing or improving the design of the application to remove classes of risk, and then drilling in depth into some of the more tricky threats and controls. For a Junior pen test person, I’d probably focus on identifying a bunch of concrete threat scenarios and negative use cases and then ask them to detail how they would test those if they had to pen test the system. This flexibility is why I personally prefer these kinds of described systems problems. They’re easy to generate (especially once you’ve practiced a few of them) and can be easily tweaked, refined, or refocused to the role and level under consideration.