As a digital lending platform, Moolahsense is focused on protecting the assets of our investors and issuers. We provide comfort to the actors in our eco-system to manage and monitor their investments with peace of mind. Additionally, Moolahsense’s data is one of our core assets, that provides intelligence and insights on our investors and issuers. Protecting our key assets is critical.
The journey to establish a digitally secure platform for our issuers and investors at Moolahsense began through an induction of an information security focused programme labelled “Tech Risk Uplift”. The aim of this Programme was to provide a concentrated effort to define an approach, develop a plan and build relevant infrastructure components across its enterprise digital architecture.
The programme establishes a series of foundational steps based on the following,
Defining Moolahsense’s policies on its digital assets across the following pillars of,
Ownership – What is Moolahsense’s ownership model for these assets?
Usage – How are these assets being used internal and external to Moolahsense?
Collection – What, How and Why is the data collected?
Storage – How is the data currently stored today?
Investigating Moolahsense’s existing web architecture against expected best practices required to establish a secure platform against the foundations of
Package in a programme – establishing milestones or action plans to mitigate risks with the foundations set above.
Defining policies for digital assets
In constructing the relevant policies, for business processes, there were three key considerations that were taken into account.
Core vs Non-Core platforms.
Moolahsense primarily conducts our day-to-day activities through a set of Core platforms; proprietary platforms that enables credit assessment, note origination, investor relations and cash management capabilities vital to its business model.
These platforms are not easily substituted, and warehouse mission-critical data for our business that provides data insights on our investors and issuers alike.
In contrast, the non-core platforms that enrich our internal business processes are substitutable but would cause more of an inconvenience rather than a disruption.
The nature of these platforms provides context to the ecosystem that the policies will need to gear towards, specifically with respect to how data is being classified and protected within the platform’s environment.
Cloud-SaaS first operating model.
True to startup culture, and blessed with a wide range of SaaS toolkit available today, that powers our business processes, it was important that our policies cover scenarios that endorse acceptable use Moolahsense digital assets, remote working, sharing of information internally across web-services.
In order to stay lean and cost efficient, Moolahsense engages multiple partners in its day to day operations. With this, it was pragmatic that outsourcing policies provide guidance to the processes involved from onboarding to risk management in the use of our digital assets.
Throughout this journey, we referenced relevant sources that calibrated the right policy structure that made sense for Moolahsense. These are notable references,
SANS Institute – https://www.sans.org/security-resources/policies
OWASP Top 10, 2019 – https://owasp.org/www-project-top-ten/
Personal Data Protection Act – https://www.pdpc.gov.sg/Legislation-and-Guidelines/Personal-Data-Protection-Act-Overview
Investigating the web architecture
Leveraging on these policies, we defined the activity streams for the Tech Risk Uplift Programme to focus on aligned to the pillars of
Our assessment started with an investigation of existing digital assets taking into consideration Moolahsense proprietary assets On-premise vs Cloud architecture and Software-as-a-Service platforms.
Digital assets; on premise vs cloud
The key objective was to ensure that the ownership and use of either on-premise or cloud assets are managed through a centralized identity provisioning point.
In keeping with our digital first DNA, Moolahsense leveraged Identity-as-a-Service platforms that allows Moolahsense to gain control of our on-premise and cloud digital assets without the need to establish our own on-premise active directory and identity provisioning server. In the market today there are several options for consideration such as Okta, LastPass and
Additionally, with cloud capabilities, Moolahsense has ultimate control, to be able to implement a variety of security protocols such as Virtual Private Network (VPN), Web Application Firewall (WAF), Anti-virus, SSO etc. to be able to establish security layers across access and transportation of data.
For a further in-depth assessment of cloud hosted architecture, Horangi’s Warden and AWS Well Architectured Tool provides some insights against regulatory requirements that proved to be useful to pinpoint potential weaknesses with our existing configuration.
Whilst these platforms are used by Moolahsense to conduct business day-to-day, the approach to enable network security is dependent on the capabilities of these SaaS platforms. In assessing these platforms, as an example, Moolahsense adopted these considerations,
SaaS platforms must have HyperText Transfer Protocol Secure (HTTPS) capabilities.
SaaS platforms must have ability to allow for Single Sign On (SSO) using either our existing Identity Provider or a recognised Credentials ServiceProvider (CSP) such as Google or Azure.
SaaS platforms have multiple factor authentication (MFA) capabilities.
Looking back on this phase of this journey,having a diversified on-premise and cloud architecture requires more in-depth organization of digital assets to adopt a hybrid approach to establishing network security.
In working through developing a digitally secure platform, Moolahsense leveraged on OWASP Top 10 as a guide in our application development efforts.
OWASP Top 10 provides a broad consensus about the most critical security risks to web applications. Through investigation of our code base, Moolahsense then embarked on a developing our CD/CI pipeline to work through the identified gaps. The below gives examples of some of the items in the Top 10 and how these weaknesses can be used.
Cross Site Scripting An actor is able to write a script where a user input e.g textbox to input Investor’s name or Issuer’s name to trigger an unauthorized execution in the server. For e.g. input in the textbox the name, John <script>!-execute this script-<script>.
Broker Access Control An actor is able to access specific URLs can be accessed by the Issuer without logging in through the Home page.
Broken Authentication – Session management – A user session is not logged out even after the user has logout, by using the existing session id
Security Misconfiguration – The headers used in POST/GET and its response messages needs to be configured to include the security headers that will add additional protection to scripting attacks (see Cross Site Scripting)
What is important here is that application development being a continual process requires developers to be exposed to working through security weaknesses in their own code, so that they can embed this new knowledge into their future development efforts.
With data security, it was important that we investigated the ownership, usage, collection and storage within our ecosystem today, with clearly defined a data glossary to identify gaps. Given the vast amount of data that Moolahsense collects, having a sense of how databases are structured, tables are formulated to work in conjunction with the application is critical to map across ownership, usage, collection and storage.
Of note, overlapping security controls established with the Network and Application security activities have created a multi-layered approach to protecting our data assets.
As such we focused on the application of the recently published Personal Data Protection Act as guidance to acceptable practices within the Singapore jurisdiction.
What is clear from the Personal Protection Act guidance is that data security is not just a technology consideration but also a business process consideration. Thus leveraging off the data glossary, we defined a plan of action that relates to not just specific application processes but also internal business processes.
Package in a Programme
With a plan of action defined across these 3 streams, Network, Application and Data Security , the programme of work brings together expertise from DevOps, Product Management, Engineering in order to work through each individual item together, overarched by the Tech Risk Uplift Programme as a steer, with members from within the business unit.
On a monthly basis the Programme engages stakeholder to provide updates against plan, re-baseline plans if required, introduce discoveries to approaches that work vs approaches that needs further consideration.
Minuting these discussions provides context to decision points. On occasion, the Programme also provides an avenue where relevant changes to the operating model with Information Security elements were discussed.
Information Security is a constantly evolving space, and Moolahsense has made headway to constantly evolve with it. Control elements need to re-configured over time, when new threats emerge or when new technology and practices are developed.
Alongside these constant evolutions, there is a need for vigilance to be able to adapt to the environment changes. At Moolahsense, we’ve established the framework to operate continuous governance and development of our architecture, aligned to the interests of our
internal and external stakeholders.
For future product managers, here are some other relevant sources that may be insightful to develop their own path to a digitally secure platform.
OWASP leverage on several elements of NIST https://www.nist.gov/cyberframework/new-framework#basics
Horangi Warden https://www.horangi.com/products/warden/
Common Vulnerability Scoring System https://en.wikipedia.org/wiki/Common_Vulnerability_Scoring_System