Photo by NeONBRAND on Unsplash

What is the security assessment about?

Anything can happen when your app gets released to the public.

As we don’t know what we don’t know, it’s important to ensure that proper measures are in place to mitigate the risks and application vulnerabilities — through a security assessment and audit.

What does the security assessment and tests cover?

The coverage of the security assessment and tests vary across projects, but they would generally cover the following areas:

Mobile and web application penetration tests: OWASP Top 10 20XX vulnerabilities
Infrastructure audit: OS hardening and vulnerability; access controls, auth configurations, security logging

What is the process like?

I will be sharing my experience — at a high level — from an infrastructure engineer’s perspective.

For mobile and web application penetration tests, the application’s IPA and APK files are sent to a security vendor, whereby manual and automated tests will be conducted to discover vulnerabilities.

Infrastructure audit can be slightly different, considering that my project was using a cloud provider to host and manage most of its services.

If your project is similar, you would have to adhere to the cloud provider’s rules of engagement and obtain a permit to perform penetration tests on the infrastructure.

My project eventually adopted a manual IT security audit for the infrastructure component, which required me to go through a comprehensive compliance checklist.

As for automated tests, approvals have been obtained from the leads to waiver the automated tests in the cloud with the consideration of the cloud provider’s comprehensive compliance coverage of the ISO standards.

After the security vendor has completed the security tests, a report will be generated for the project team to rectify the issues or have the project/client accept the relevant risks.

What are the five key considerations to take note of?

Security audit checklists are often exhaustive and not all the items may be relevant to your project. These are the top five that have stood out in my project:

OWASP Top 10 assessment and mitigation measures: compare the list against your application controls and establish mitigation plans for each of the list items.
User access management and controls: appropriate roles and access are assigned to each user with processes in place to manage user onboarding and exit.
Application logging at multiple layers: incorporate logging software within mobile applications e.g. Crashlytics, ELK for backend applications, and cloud audit logs for infrastructure.
Data management and disaster recovery: categorize and configure sufficient backups for your data and cater for negative events which could affect your application’s availability.
Network and communications management: ensure that each of the open ports apart from 80/443 are justified with access restricted to a whitelisted IP range; and communications between mobile/web and backend are secured e.g. via SSL pinning.

I will delve slightly deeper for each of the abovementioned items and attempt to provide some examples.

#1. OWASP Top 10 assessment and mitigation measures

The OWASP Top 10 20XX is a standard awareness document for developers and application security — representing a broad consensus about the most common and critical security risks to applications.

You can protect your application from majority of the threats on the Internet by running through the list of 10 top common vulnerabilities and establish mitigation measures for each of the items.

A sample list is provided below.

#2. User access management and controls

System access roles are often granted to users who require access privileges to manage the systems and applications. Access management often involves authentication (2FA/MFA login) and authorisation (permissions/policies).

The principle of least privilege should be adopted as a good practice to ensure that the impact is contained should a user account become compromised.

User account administration can be managed through processes and documentation. While there are many approaches to administering user accounts, a simple example is provided for you below for reference.

General roles of the system:

Owner has full access to all resources and are allowed to delegate access to other users
Contributer can create and manage all resources but cannot grant access to others
Reader can view all resources but not create and manage them

An overview of the account roles across environments:

An overview of the account roles and users for the resources:

Additionally, there should be a process in place to manage the lists above whenever a new user is onboarded or removed from the project. The process could be included in an employee’s onboarding and exit checklist.

#3. Application logging at multiple layers

Logs provide you with an indication of how your system is being used — which allows you to identify potential red flags on malicious usage and behaviour.

From a security and audit standpoint, alerts can be configured to detect anomalies in logs which suggests suspicious activities

e.g. large traffic originating from a specific IP address (app backend layer), changes in resource configuration (infra layer), etc.

Below are some examples that showcase the logging tools and capabilities for the various layers.

Mobile application logging with Fabric:

API gateway logging with Azure APIM:

Application logging/SIEM with ELK:

Infrastructure logging with Microsoft Azure:

After implementing logging at the various layers, there should be a process in place to review the logs on a monthly/quarterly basis to ensure that there are no unauthorised activities that could compromise the system.

#4. Data management and disaster recovery

There could be data regulatory requirements e.g. PDPA that your application has to comply with, especially if users’ personal information are captured.

It is important to take stock of your application data and classify them into the various categories e.g. confidential, restricted, and public, etc. so that each category can be managed separately.

Some examples of public data are information brochures (PDF) and application image files — which can be stored in a file server accessible to the general public.

Restricted and confidential data can be managed separately through authentication and authorisation.

Cloud providers like Microsoft Azure provides out-of-the-box data classification and management capabilities which allows you to effectively manage your data in the cloud.

Data management also covers data retention period and storage capacity threshold management, which you may also want to explore to ensure that your application is sustainable when the data scales.

As for disaster recovery, you may want to consider implementing backup options and recovery time for the respective data categories to make sure that your application is available in the event of an unforeseen circumstance.

#5. Network and communications management

Large applications often require complex network configurations and security policies to govern access to various different services; the purpose is to shield against unauthorised access and interruptions to application services at the IP/port/network level.

In Microsoft Azure, a Network Security Group (NSG) is used to control access to backend resources at the network level using inbound and outbound rules.

As good practice, ports apart from 80 and 443 should have restricted access to the public.

There should be a document/section to indicate the purpose and justification of each open port, coupled with periodic reviews, to ensure that there are no unnecessary open ports which can be potentially exploited by attackers.

Below is an example of a document that provides users with an overview of the application’s network rules.

Also, the communication between the web/mobile applications and backend API gateway should be properly secured to prevent man-in-the-middle attacks via software i.e. Charles, Proxyman, etc.

You would want to make sure that your applications are communicating directly to your backend and not through a proxy whereby information is clearly visible to malicious users.

For my project, we have adopted TrustKit to deploy SSL public key pinning to ensure that the mobile application is communicating correctly with our backend services and not through a proxy.

Other important considerations

Apart from the five mentioned, here are some additional considerations to facilitate a smooth release:

Prepare a go-live checklist: keep track of the communications, support and training plan involving the various stakeholders before, during, and after the application goes live by referencing a checklist.
Ensure proper documentation: highlight technical configurations using relevant diagrams, incident management procedures, and common issues/troubleshooting FAQs, etc.
Provide adequate technical support: have the appropriate channels and points of contact for users to raise issues with clear indication of the conditions to escalade issues to the subsequent levels.