Security Policies
      Back to home
      1. Help Centre
      2. Technical & Security
      3. Security Policies

      Application DevOps

      The processes that FMI Works uses for patching, monitoring, updating, scaling and securing its applications.

      This article is for IT and security professionals

      The FMI Works system can only be as strong as the underlying infrastructure.  To ensure that the application and the hosting environment are both operating at their best, FMI runs a modern DevOps environment.  In this environment, the development team is not only responsible for the operational environment, but changes and updates to the environment are implemented electronically, not manually.  This is often called "infrastructure as code".

      Patches and Updates

      As all applications rely on the underlying system, keeping good system hygiene is important. FMI Works ensures it's environments are updated as follows:

      • Operating Systems (i.e. Windows) are patched regularly using the managed OS image provided by Azure.  Patches are applied when available and any required restarts are handled through the normal High Availability model.
      • The virtual machine image used by FMI is designed and managed by Microsoft as a securely hardened image designed for web workloads.  Amongst other security measures, these only allowing HTTP and HTTPS traffic.
      • Database Management Systems (i.e. Azure SQL Database) are patched regularly using the managed database provided by Azure.  
      • No public access is available on to any other system in our infrastructure, with firewalls blocking access to all ports (except HTTP/S as described above).
      • All servers run Microsoft Defender antivirus software and have their rulesets updated on Microsoft's schedule.
      • Updates are typically timed with the Microsoft "Patch Tuesday" cadence, or more frequently at their discretion.

      Application Updates

      The creation of new client environments and updates to existing clients are performed on a schedule using a rigorous automated continuous integration / continuous delivery (CI/CD) process.

      • Application updates are automated through a gated continuous delivery (CD) process.  This follows the continuous integration (CI) process that creates artefacts that are held for our monthly release window.
      • Application frameworks (i.e. .NET) are updated in the development process through the NuGet package management system.  The framework version is bundled with the release artefact and is re-deployed on every release night.
      • Application dependencies are updated during the development process and are routinely kept up to date.  The exact version of each dependency is listed in the build definition, so all developers, test systems, and production instances run the same versions.  See Vulnerability and Penetration Testing for more information on how FMI secures these packages against threats.
      • Database schemas are applied automatically using machine generated migration scripts that are testing in both our local, development, and testing environments before being promoted to production.

      Application Monitoring

      FMI actively monitors applications to ensure that systems are responsive and secure.  This includes:

      • Monitoring server utilization for both CPU and I/O, with excessive usage triggering auto-scale-out events to ensure the application stays responsive.  See High Availability and Disaster Recover for more information.
      • Monitoring of database utilization across an elastic pool, allowing databases to scale-up if required.
      • Error logging and reporting, correlated across all systems to facilitate debugging and support requests.
      • Auditing of database activity to be able to provide forensic analysis should a regulatory need arise.
      • Monitoring of network traffic, identification and remediation of denial of service attacks through Microsoft DDoS mechanisms.

      Developer Hygiene

      In addition to our deployed applications, it is also important that the development toolchain that is used to create those applications is also maintained.  This includes:

      • Updates of operating systems on development systems.  Most development systems us Windows and are updated as part of Microsoft's Patch-Tuesday process.  Mac systems are updated with the latest available from Apple.
      • Application frameworks are routinely upgraded to the latest version. This will either be a Long Term Service (LTS) release or the latest available depending on features and a risk assessment.
      • DevOps rights are granted on an as-needed basis.  This follows the principle of least-privilege where only DevOps engineers that require access to a service are granted access.  For example, our monthly release process requires two DevOps engineers to have access to change our application infrastructure.  This is granted at the beginning of our UAT process and is revoked afterwards.  Further, the roles of User Access Administrator are maintained separately from the Contributor role to help ensure multiple people need to collaborate to make changes to the system.
      • Each DevOps engineer has access to their own Azure subscription with credits to allow for experimentation and development work without requiring access to production Azure resources.
      • Internal security policy disallows shared accounts and no passwords in any of our systems, all access is through name accounts, preferably with SSO and MFA.