Keep the Security of Your Projects in Checklist

Especially when there's a bigger team who are working on multiple applications.

1. If we rely solely on security reviews done just before release, we can find vulnerabilities that would require more time or people to fix than the team can fit into the budget or by the deadline set by the client.

2. If developers don’t know that they need to improve the security of their code, they won’t look for the knowledge prepared for them by the security team.

3. Time estimations that the clients receive will not include additional time for security checks and improvements making it much harder to fix things in later stages of the project development.

Preventing issues through finding the best ways of increasing security awareness is our duty as a mobile security team, and to do that we have to plan our work properly.

With limited resources in terms of time and people, we decided that there’s a need for a new tool that will help us to oversee the security status of all the mobile projects in the company.

The solution

We started by listing all the security requirements that applications need or should fulfill depending on the features that are implemented. The list included requirements ranging from basic ones like, “if there’s password input, it should be masked properly and have auto correction disabled” to more advanced issues like jailbreak/root detection in vulnerable projects (e.g., banking or medical apps) and certificate pinning for https usage.

So, how does this help us to increase security awareness? Well, we took this list, added additional fields to help with maintenance and then we presented it to all project teams in the form of a checklist that they can view and fill with us in a periodic process. This provides us with an easy way to check the security status of a project and gives the development team a clean list of small improvements that they can implement. It is also a great way to learn security because developers that implement a more secure solution will remember to use it in their next projects or point it out during the code review.

The checklist structure

We decided to keep the security checklist as a spreadsheet because it’s the easiest format to maintain and fill with data. We also extracted higher-level categories into separate sheets, so we can easily access or remove requirements that do not apply to the project, e.g., no need for HIPAA compliance, only one mobile platform supported, etc.

Information about each of the requirements is presented in a few easy to understand columns:

• Status — represents the status of the requirement implementation, and the row background color is updated based on the status. The list of possible statuses is:

  • TODO — a security requirement must be applied to the project and is not implemented yet.

  • DONE — a security solution is already implemented and described in the comments column.

  • Won’t fix — a solution exists, but cannot be implemented for some reason (tech limitations, client decision, etc.) explained in the comments column.

  • Not applicable — the project does not contain features that would require a given implementation.

• Requirement — this column has a filter to choose the type of requirement, it allows selection of only those requirements that apply to the project, e.g.:

  • Default — applies to every application.

  • Extra — optional requirements that are either connected to very specific security mechanisms like hashing and jailbreak detection or apply to projects from certain areas like banking and payment applications.

  • Email/Video/Upload/GDPR/WebView/Location — requirements of these types apply to applications that make use of a particular feature.

• Feature — specific feature in the application that requires secure implementation.

• Security requirement — description of required implementation for a given feature.

• Solution in app / Comments — description of implemented solution or comment explaining why it cannot be fixed.

• Last updated — date of last change that updates automatically when Status or Solution/Comment columns are edited.

• Priority — indicates how important it is to implement a given solution with Critical meaning it should be done as soon as possible and Low being a “nice to have”.

• Reference — link to detailed guide or article describing how to implement a given solution.

How we are using the checklist

We have all the pieces ready to put it all together into a useful and easy process. Our idea was that it should involve developers from the project team as much as possible, so we decided on periodic status checks. The whole process flow looks like this:

1. A member of the mobile security team is assigned to a project (new or ongoing). They prepare a new checklist document and set up a meeting with the project developers.

2. In the first meeting we try to learn as much as possible about the project, read through and explain all requirements to the developers and select if each of them applies or not to currently implemented features.

3. Depending on the project, we decide how often we'll meet and check the status of all applicable requirements. By default it’s every two months, but maintenance projects that don’t change that much could be set to three months. Highly vulnerable projects (e.g., banking or medical applications) could use meetings every month even.

4. After the first meeting, the project team should create tickets for all applicable security requirements and, based on their priority, include them in their following sprints.

5. In each of the recurring meetings, the assigned member of the mobile security team will check the following things:

1. Ask developers if there are any new features that would require new security requirements.

2. Check progress on the highest priority requirements.

3. Answer any questions regarding security requirements and required implementations.

6. Additionally, we can set up meetings before bigger releases to make sure that the application is as secure as possible.

How you could use the checklist

Yes, you read it right. We have made an effort to make our mobile security checklist fully open-source, so you also can introduce it to your team or organization. And don’t worry if it feels overwhelming at first, we assure you that it is really easy once you get started.

You can head to the checklist repository and check out all the articles and guides that we prepared. You can also go straight to the releases page and download the most recent version of the checklist spreadsheet.

Once you acquire the mobile_security_checklist.xlsx just load it into your local spreadsheet editing software or upload it to Google Drive and you are ready to start filling in information about your project.

Handbook articles

The Mobile Security Handbook is a separate project where we created a series of detailed articles explaining how to implement and test various security solutions. It synergizes so well with the checklist that we decided to connect it and include all the handbook guides in the repository. The goal is to have an article explaining how to implement each of the security requirements, but that requires an enormous amount of work. That’s why for now we provide you with articles on topics that we have chosen as the most interesting or important.

To learn more about our Mobile Security Handbook, check its landing page in the repo.

How to contribute

As we said, the checklist is fully open-source, which means that everybody can contribute their knowledge to this project. We accept various types of contributions, you can:

• Suggest new requirements to be added.

• Add new requirements together with their type, priority, and suggested solutions.

• Add a new Handbook article that describes in detail how to implement a given security solution.

To learn more, we have contribution guides for both requirements and handbook contributions.