Application Security

Software applications are susceptible to a wide variety of threats from internal and external actors.  Cloud applications are at higher risk of falling prey to security related issues due to factors such as geographic separation between the application and the actual users, geopolitical aspects and overlapping or conflicting laws and practices.  Security related issues may impact a software application in different ways, ranging from unwanted data leakage to data destruction.

Application security deals with putting appropriate measures in place to prevent security issues from impacting the normal working of an application.  This page details the measures put in place within the Platform to secure application users from potential security threats.

Our approach towards application security is depicted in the diagram below.

» Prevent

We firmly believe in the adage Prevention is better than cure.  Therefore, when it comes to application security we put great emphasis on preventing security related threats.  Security is one of the primary focus areas throughout the Software Development Lifecycle (SDLC) for us and emphasis is given at every stage of the SDLC to ensure that security related issues do not creep into the applications.

» Monitor

The application security landscape changes constantly.  Security thus becomes a moving target, one that has to be continually monitored and assessed.  We therefore have various monitoring and assessment mechanisms in place to ensure that the applications remain free of security related issues.

» Defend

Modern business applications are extremely complicated and built on top of a plethora of software.  This includes operating systems, networking software, programming languages, software libraries and many more.  All of these need to be combined together in a meaningful way to develop an application.  The outcome is a software that adds some business value.  The flip side however is that all of these components are designed and developed by different parties and inadvertently, some combinations may have security related loopholes that a malicious party may discover and try to exploit.

Our policies and procedures are fully geared towards the constant threat of cyber-attacks, enabling us to defend our applications quickly and comprehensively, should a security related issue be discovered.

» Improve

Learnings from monitoring and defending are constantly fed back into the overall process to improve the quality of not just the existing software but also future pieces to be developed.

» Secure Web Application Development Practices

We use the latest guidance and information provided by the OWASP Top 10 Web Application Vulnerabilities Project ^{(external link)} while designing and deploying application features.  The table below summarizes the specific vulnerabilities that are guarded against in the application's design.

» User Authentication and Authorization

All applications running on the Platform are closed in nature.  Users may gain access to an application's features only after asserting their identity (Authentication) and verifying their access to the feature (Authorization).  Users are authenticated using a combination of a unique identifier such as an email address or phone number and a secret such as a password.  Users are given access to specific functions by their legal entities and users may not access a function unless they have been expressly authorized to access that function.

» Role-Based Access Control (RBAC)

Authorization is enforced using a design framework whereby each function is tied to one or more specific user role.  Only users having a role mapped to a function are allowed to access that function.  This framework, known as Role-Based Access Control (RBAC) requires the following design activities to be carried out for every function/ feature:

• Identify which role(s) should be able to access that function/ feature;
• If the function/ feature requires a new role, define the role;
• Identify all sub-functions/ sub-features that will require the same role.

The actual enforcement of RBAC controls is done at the time of writing the source code.

» Auditing

All critical user actions are audited.  The date and time of the action is recorded along with the action.  This information is presented later to auditors so that any malicious user activity can be reviewed and corrected if necessary.

All of the design level considerations described above are implemented during the development phase of the SDLC.  Additionally, the following activities are also undertaken during this phase.

» Version Control

All source code for the Platform is kept in a protected version control repository, accessible only to authorized application developers.  This allows history management, comparisons between multiple versions of the same code or concurrent versions of different parts of the code, traceability, root cause analysis and a common code integration area.

» Coding Standards

Our software developers use a common coding standard for writing all pieces of code.  Security best practices are included in the standard so that all developers follow them consistently.  Developers are trained on these best practices as part of their induction on the team so that they are thoroughly aware of the impact of security related issues before they start development activities.

» Reviews

All changes to the code are reviewed for quality and adherence to coding and security best practices before being added to the version control repository.  Security related reviews are carried out by competent experts for all critical pieces of code.  Important observations from reviews must be addressed before adding the code to the version control repository.  This ensures that code used for testing and future deployment to end users is certified to be free of security related issues.

» Defect fixing

We give higher priority to defects (deviations from expected application behaviour) compared to new application features.  All defects are immediately assessed for impact and risk (process of triaging) and assigned a priority.  High priority defects are attended to immediately and fixed at the earliest possible.  Security vulnerabilities are treated as defects and therefore get triaged immediately.  High priority vulnerabilities get looked at and fixed immediately to minimize the window of impact.

» Spot checks

Every 3 months, a part of the code is selected randomly for in-depth security review and testing.  Any vulnerabilities identified are treated as defects and major ones get addressed immediately as part of the defect fixing process.

» Automated testing

Automated tests are developed for all security related features and code components.  These ensure that parts of the code that have implications for the application's security are tested regularly without human intervention.

» Continuous integration

All automated tests developed for testing the application's security are part of a continuous test integration process.  This process runs any time any change is made to the code.  This ensures that security related features are tested every time even the minutest change is made to the code.  This step also acts as a safety net in ensuring that security related defects do not slip by the developers.

» Firewalls

The servers hosting the Platform are protected against direct unauthorized access over the Internet using firewalls.  The firewalls are configured only to allow incoming HTTP and HTTPS traffic to the servers.  All other access, including access to all TCP and UDP ports other than those for standard HTTP (port 80) and HTTPS (port 443) is completely blocked.

» Intrusion Detection

The hosting environment utilizes an Intrusion Detection Device for monitoring the incoming requests.  This device is installed before the firewalls so that it gets to see the entire traffic destinated for the servers.  All access to ports other than 80 and 443 are reported in real time.  Repeated requests from the same IP address or IP subnet are then blocked at the firewalls to proactively restrict suspicious activity.

» VPN access for management

We access the hosting infrastructure over an encrypted Virtual Private Network (VPN).  This VPN has a destination endpoint fixed in the AWS data center and the source endpoint fixed in our corporate office.  This arrangement ensures the following:

• Only our staff can access the hosting infrastructure, since the VPN is accessible only from our corporate office;
• All management traffic is fully encrypted and stays away from prying eyes.

» Alerts

All applications generate log messages for any suspicious user activity such as a user attempting to bypass authorization checks.  These log messages are routed in real time to our application support staff for review and action.

The picture below shows our network design.  VLAN stands for Virtual Local Area Network.  Each VLAN is a logically separate local network that allows only incoming or outgoing network traffic of certain kind.  The type of traffic is controlled by software firewalls on both sides of the VLANs.