Secure by design

At Managed Functions, supporting your operations is our number one objective. To do that, we have a responsibility to maintain high standards of security and operation resilience.

To communicate how we achieve these standards, this whitepaper describes our:

  1. infrastructure,
  2. operating model,
  3. customer data management and
  4. security summary.

Note that the target reader of this whitepaper is an IT professional so we haven't made an effort to explain terminology commonly in use in the IT community.

1. Our infrastructure

Viewed from a technical perspective, Managed Functions creates pipeline infrastructure from code.

By pipeline infrastructure we mean a software system deployed to a cloud provider that performs an automated workflow task such as converting PDF Insurance Quotes to data and pushing this data into an underwriting system.

To accomplish the task of creating and deploying this pipeline, a Managed Functions pipeline developer writes the integration pipeline code and runs a build process (which we call Publish) that creates the production pipeline on our cloud infrastructure or our customer's cloud infrastructure. The diagram below shows this in action - with a diagrammatic view of the code on the left and the deployed infrastructure on the right.

tech-stack
The code is stored in Github and built and deployed using Github Actions when the code is committed to the Github repository.

The above process means that Managed Functions has three surfaces it must secure.

  1. Development environments
  2. Github repositories
  3. Production deployments

Our development environments are secured using robust password management practices (12 character passwords with a combination of letters, numbers and special characters; no re-use of passwords and enforced use of password managers). Each developer has a unique identity on our systems and we maintain access logs indefinitely on all infrastructure).

We follow Github's best practice guidelines for securing our Github repositories.

Our production serverless deployments are secured following the best practices set out by each cloud provider. For example we have adopted AWS's Well Architected Framework for our AWS deployments.

2. Our operating model

Operational roles and responsibilities are split into four types:

  1. Governance
  2. Development
  3. Third-party experts
  4. Support

1. Governance

Each pipeline is assigned an executive responsible for ensuring proper development and deployment of pipelines. From a governance perspective, it is their responsibility to ensure that the managed function pipelines fit within our defined development and deployment practices whereby all code resides within Github and all functions are deployed to the production environment using Github Actions. This is important as it ensures that all code passes through Github's automated code review checks and all libraries used in production are continuously monitored for security issues.

The executive responsible for governance of a pipeline is also the single point of contact for that customer. This ensures that our customers deal with the person at whom the buck stops rather than getting passed around a support queue dealing with support staff who may not know the full picture.

2. Development

Pipeline developers build and do the initial deployment of the pipelines. They build each pipeline component in a Jupyter Notebook (a literate computing environment) that makes it easy to test and easy to update when the incoming data or outgoing data changes.

jupyter-notebook-to-lambda

3. Third-party experts

The vast number of systems we integrate with means we cannot be experts in each of them. To help our developers quickly scale the learning curve for a new system we use a build process that creates a stand-alone Github repository and isolated cloud storage. Our developers can provide a third-party expert with access to that repository so they can build the notebook that connects to the system they have expertise in. Once the third party expert has completed the work the code is automatically moved back to the pipeline repository and all infrastructure used by the third party expert is destroyed.

4. Support

Once a pipeline is developed, our support team takes over responsibility for the Github repository. When a customer requires a change to the pipeline the support team pulls down the repository, makes and tests the change and then redeploys the pipeline. Each component can include a test and production deployment option so it easy for the support team to shift workloads from one to the other.

In the event of processing failures our support team is immediately notified. Our architecture ensures they are able to quickly and accurately resolve the issues. Almost all issues encountered by the pipelines are the result of unexpected data coming down the pipe. For example, a remittance processing pipeline with a machine learning model trained on certain remittance documents may fail if a sufficiently different type of remittance is sent down the pipe. To fix this issue our support person simply pulls down the notebooks from the repository, runs the notebook (because this is exactly the same as the production pipeline it immediately encounters the error), makes the changes required to cater for this type of data, and redeploys the pipeline.

3. Customer data management

Managed Functions primary role in supporting your operations is to move and transform your data. As a result, security of your data is critical to our business.

We have designed our infrastructure and operating model so that each customer has a dedicated storage area for their data. There are no shared databases with other clients. Your data sits on cloud infrastructure in a bucket that contains only your data. This architecture supports and enforces good, secure data management practices.

4. Security summary

At Managed Functions, security is not an afterthought. It is baked into our infrastructure and operating model. By following our operating model we can be confident that we are treating our customer's data with the care and respect it deserves.

  • Each pipeline has a person responsible for governance
  • Well structured process for building and deploying pipelines
  • Use of automated industry-best-practice tools such as Github's automated code assessment tools
  • Strong password management practices
  • Extensive logging of all production systems
  • Isolated environments where third-party code input required
  • Immediate notification of issues in production pipelines
  • Easy rectification of issues
  • Every customer has an isolated environment for their data which is not shared by any other customer.