Security Overview for Martus

Introduction

This document lists important information about Martus Solutions’ security policies and procedures. If you have additional questions, please create a ticket through the Knowledge Base if you are a direct Martus customer, or contact your Martus reseller if you are supported through one of our Martus partners.

User Access 

Access to Martus applications is controlled by a username.

• Access to the Martus application is controlled by the customer Admin users.
• Access to data within the Martus database (for customer users) is very granular and controlled at the user level by the customer Admins. 
• Users are automatically logged out after a defined period of inactivity.
• Martus password policy for users who log in directly to Martus requires that passwords be at least 8 characters long, have at least one upper case letter, one lower case letter, one special character, and one number. If five invalid attempts are made, the account is locked for five minutes. 
• Martus does not expire passwords or prevent passwords from being reused. 
• Martus supports the use of a security question for users who log in directly to Martus.  A client-level setting can be used to require all users who log in directly to Martus to configure a security question and answer.
• Martus supports multi-factor authentication for users who log in directly to Martus.  A client-level setting can be used to require all users who log in directly to Martus to use MFA. 
• For additional controls on customer user access, we support SAML2 for clients to use their own SSO provider and implement any desired password and access requirements. 

User Privacy Policy

• Martus requires an email address and name in order to register a Martus user.  The user then provides his/her consent for Martus to collect this information. Martus uses the information provided to create a unique Martus identity. Martus may send transactional emails related to activity within Martus. Martus may also send emails related to the app and the services provided to your organization, including release notes, newsletters, status updates, webinar invitations, and customer-success activities.   
• The full User Privacy Notice can be found on our website.
  
  

Customer Data 

Customer data is stored in cloud service providers. US data is stored in US-based servers, Canadian data is stored in Canadian servers, and Australian/South African data is stored in Australia-based servers. 

• Sensitive data such as passwords and connection information is hashed and encrypted within the application. The database and blob storage is always encrypted, in transit and at rest, including all backups. Transparent database encryption performs real-time I/O encryption and decryption of the database, backups, and logs.  
• HTTPS is used when connecting to the application from the browser. Traffic between the web and database servers is encrypted.
• Database backups are stored in encrypted cloud storage platforms. Encrypted point-in-time database backups are available for 35 days at 10-minute intervals, weekly backups are kept for 26 weeks, monthly backups are kept for 24 months, and a yearly backup of week 52 is kept for 10 years.  Encryption keys are managed by our secure cloud storage providers.

Martus employees and contractors also have access to customer data. Employees and contractors sign confidentiality agreements related to Martus intellectual property and customer data. 

Martus administrators use two-factor authentication in their administrative roles when accessing customer data.

Martus has successfully completed the SOC2 Type 2 audit. The SOC2 is a report based on AICPA’s existing Trust Services Criteria. For SOC2, the scope of assessment covers Martus’ information systems and controls related to Security.  

Martus Application and Infrastructure

The Martus application and data center are hosted by Microsoft Azure.

• Databases are deployed in Azure data centers, and data backups are automated and managed by Azure processes. Data and backups are maintained georedundantly in multiple data centers.
• Azure hosts Martus web applications using IIS running on Windows servers located within multiple data centers. Servers are managed, patched, and hardened by Azure.
• Martus services were designed with the assumption that certain controls would be implemented by subservice providers, including Azure.
• Physical security and monitoring are supplied by our cloud provider. System, application, and data backups make use of the standard backup and resiliency provided by our cloud provider. databases are deployed in Azure data centers, and data backups are automated and managed by Azure processes.
• Azure Security Center constantly monitors server, database, and data configurations for vulnerabilities and offers threat protection and intrusion detection. Azure also monitors employee access to hosts, data stores, and other resources.

Martus uses industry-standard secure coding practices. Additionally, as part of our development process, Martus uses Static Application Security Testing (SAST) tools to analyzes source code to help find security flaws. Martus contracts with outside security firms for application vulnerability scanning and penetration testing including OWASP scans.

Software is versioned and prior versions are retained at each deployment. Martus’ Change Management Policy requires review, testing, and approval prior to deployment. Deployments of approved updates are managed from source control through an automated pipeline via Azure DevOps.

Martus’ transport layer security controls allow only TLS 1.2 Strong cipher suites.

Martus recommends that all customers use modern, updated web browsers to access Martus. Martus supports Edge, Chrome, and Firefox. Martus does not support Safari.

Martus Control Environment

Martus Solutions operates in a defined system to provide the Martus cloud-based budgeting and reporting tool and associated services to its customers. The system includes policies and procedures, governance structure, support functions, and application systems. 

• Policies and Procedures provide guidance to employees regarding the processes to be followed for providing services and help ensure the consistent implementation of those processes.
• The defined processes for information systems include Access Management, Incident Management, and Change Management. These guide how service is provided to Martus Solutions’ customers.
• The governance structure establishes the structure for operating the system and demonstrates Management commitment to the defined processes. 

Internal controls at Martus Solutions include these five components. These components are linked and synergistic, forming an integrated system that reacts dynamically to changing conditions. The internal control system is tightly integrated with Martus Solutions’ operating activities and exists for fundamental business reasons. 

• Control Environment
• Communications & Information
• Risk Assessment
• Monitoring Activities
• Control Activities

Customer Responsibilities

Martus services were designed with the assumption that certain controls would be implemented by customers, the user entities of the Martus product. These controls should be in operation at user entities to complement Martus Solutions’ controls.

• Ensure that appropriate user authentication controls are in place
• Restrict access to Martus to authorized users, with user access rights and roles that are commensurate with their job responsibilities
• Mandate that usernames and passwords for Martus are not shared and are kept confidential
• Restrict access to add, modify or inactivate Martus user accounts to appropriate personnel
• Communicate changes to contacts in a timely manner
• Adhere to confidentiality requirements and commitments in accordance with service level agreements and contractual obligations

Service Upgrades, Interruptions, Outages, and Disaster Recovery 

The application is upgraded at least monthly. Those upgrades are transparent to end users and do not typically require service interruptions.  Feature upgrades are always accompanied by release notes.

In the event of a planned interruption of service, we would notify customers in advance via email and via the application. In the event of a significant unplanned interruption, we would notify customers via email.

Martus has defined emergency procedures. In case of an unplanned outage, the public-facing status page on the Martus website at martussolutions.com/status is updated with status announcements. Customers may be notified by in-app announcements and/or email.

In the event of a catastrophic failure, we would switch to secondary servers or restore new servers from backups. Martus’ recovery point objective is one hour, and the recovery time objective is 24 hours.  

Martus has a defined Security Incident Response Plan that is reviewed and updated annually. It is the responsibility of all users of Martus to promptly report any suspected security vulnerabilities, incidents, or breaches to Martus Solutions at security@martussolutions.com. 

We have system monitoring and recovery in place. Martus as a defined Breach Response Plan. Should Martus ever have a data breach incident, we would notify our customers via email. 

Our disaster recovery plan would restore servers and databases from backups. Servers are backed up daily. For data, we can do a point-in-time restore at ten-minute intervals. Our disaster recovery strategy is tested regularly. 

SSO - Single Sign-On

SSO is available to all Martus customers (all subscription tiers). Martus supports SSO access via the SAML2 protocol. Your IT staff can configure your company portal to allow this with IDPs such as: Azure Entra Okta G Suite With SSO, your organization can enforce its own security policies such as multi-factor authentication, etc. Even with SSO in place, you still need to set up users within Martus, because that controls their software permissions and privileges within Martus, along with their dimensional access.

To set up SSO, give this information to your IT staff

For clients in the US:

Endpoint: https://login.martus.app/saml

Entity ID: https://martus.app

For clients in Australia:

Endpoint: https://au.martus.app/saml

Entity ID: https://martus.app

For clients in Canada:

Endpoint: https://ca.martus.app/saml

Entity ID: https://martus.app

Requirements to receive from the IT staff

• SSO XML metadata file
• Login URL for your SSO provider

Enabling SSO

1. From within Martus go to Setup > SSO.
2. Browse for and select the XML file.
3. Paste the login URL into the Login URL field on the SSO page.
4. Note: The client entity ID and certificate fields will be filled in once the XML metadata file is uploaded into Martus. 

Removing Passwords to force SSO

• One at a time: 
  1. Go to Setup > Users
  2. Click the Edit button next to the user
  3. Click the Clear Password button
• All Users
  1. Go to Setup > Users
  2. Click the Clear All Passwords

Notes

• If a user is logging in and they have multiple clients that have SSO enabled, they will be presented with a list of clients from which to choose.
• Once the SSO setup is confirmed to be working, be sure to remove the passwords from all users within Martus. 
• Any Martus user with a password would be able to bypass the SSO security and log into Martus directly!  
• Martus Support generally cannot provide instructions for how to configure the  SSO provider selected by your IT staff. However, you can use these instructions to configure SSO within Azure Entra.
• Send the Martus logo file below to your IT staff. It has been tailored for use on the "Martus" button they create in your portal for users to access Martus.
• As an Administrator you can allow specific users to bypass SSO but sending those users the "Set up password" email. This is helpful if you need to add users to Martus who do not have access to the domain utilized for SSO.

Microsoft Entra ID (formerly Azure AD) Setup for SSO Access to Martus

Below you will find the steps for configuring Microsoft Entra ID (formerly Azure AD) for SSO access to Martus. Note that these are guidelines only. For more information, refer to Microsoft documentation. 

Setting Up Microsoft Entra for SSO Access to Martus

Step #1.  Go to the Azure Portal

Step #2.  Go to Entra

Step #3.  Go to Enterprise applications

Step #4.  Click on New application

Step #5.  Click Create your own application

Step #6.  Enter the app name.  Use the name of your choice. This is only shown in the Azure Portal and Office365 App List, and does not impact Martus. In this example, we use “Martus App”.

Step #7. Go to Single sign-on and click SAML.

Step #8. You will be shown the SAML configuration screen.

Step #9.  The Basic SAML Configuration panel will have values that are required.  Click on the Edit Button.

• The Identifier must be: https://martus.app
• The Reply URL must be: https://login.martus.app/saml

Step #10.  Download Federation Metadata XML. You will upload it into Martus on the Setup > SSO screen.

Step #11.  Click on Properties to obtain the User access URL. You will need to paste the User access URL into the Login URL field on the Setup > SSO screen within Martus. This is used by Martus to automatically send a user configured for SSO to the Azure portal for authentication when they try to log in to Martus directly.

Step #12.  Go to Users and groups to give your Azure Entra users access to the Martus Budgeting Application. Note that all users must also be set up in Martus, as their settings determine their permissions within Martus. 

The End User’s View from Office 365

Go to https://www.office.com

Click on Apps

If you are already logged into Office, then you can click on the 9 dot menu as illustrated: