About Magic Suite Security

This page provides an overview of Magic Suite / ReportMagic security and covers:

Dataflows
Our colocation facility
Electronic service access
Electronic management access
Code quality assurance

Some details of system architecture are omitted to protect platform security. For a general discussion about the ReportMagic platform architecture, please contact us.

Dataflows

ReportMagic transforms customer input data and Report Templates into Report Output Files via "Report Batch Jobs", either ad-hoc basis or according to a Schedule.

Report Batch Jobs:

Read Report Template files
Take input from a number of Remote Systems via secure "Connections"

Where the Remote System provides a public API, the data flows based on the Remote System's security model. Most Remote Systems use HTTPS for the secure API transport layer.
Where the Remote System provides a private API (e.g. behind your firewall), we provide a "ReportMagic Agent", which we securely communicate with using outbound HTTPS (from Agent to our API).

Process data in-memory
Write the output to one or more File Systems

We prefer that we write directly to your secure SharePoint system. This ensures that no report output exists at rest within our systems.
If you prefer, we can write instead to our secure File System. In this case, the report output exists at rest within our secure Colocation facility OR Microsoft Azure (this is region-dependent).

This dataflow is shown in the diagram below:

The system is configured, normally via the Web User Interface (UI), through this may also be achieved via the OData REST API direct.
This configuration is stored in the config database
The Scheduler is informed of any Report Schedules
When Schedules are configured to run (or on an ad-hoc basis via the UI / API), the Scheduler instructs one of the Workers to execute the Report Batch Job via the API...
...This causes the next free Worker to execute the Report Batch Job
The worker starts with the Report Template and determines what data should be obtained from:

SaaS systems, such as LogicMonitor, AutoTask PSA, ServiceNow, Dynamics 365 and many more
Direct-access databases

The output files are optionally sent to:

ReportMagic's file store
E-mail destinations
The Customer's SharePoint system. This is the preferred destination.

Colocation Facility

We operate our own Virtual Private Cloud (VPC) in the Maidenhead Pulsant Datacenter, a facility which meets industry best practices and the EU Code of Conduct specifications. Details, including certifications are available here.

IP address range

All ReportMagic services are hosted in the range: 46.249.212.128/27

Dimensions

5 data halls totalling 23,500 square feet on 2 floors
711 total rack capacity

Credentials

ISO/IEC 27001:2013 Information Security Management
ISO 9001:2015 Quality Management
European Data Centre Code of Conduct Participant
PCI-DSS Compliant

Building Security

Swipe card & PIN for access, with access recorded
CCTV with 90-day retention
Security fencing
Intrusion alarm system

Power

2MW Single incoming supply to dedicated on-site substation and transformer
Total UPS provision of 1.8MW in N+1 configuration
1.5MW generators in N+1 configuration
Single or dual 16A or 32A feed to racks

Environmental

24×7 environment monitoring
Total capacity of 1.5MW DX cooling in an N+1 configuration
Double-knock and Vesda systems, with FM200 fire suppression systems
Raised flooring
Connectivity
Multiple diverse-routed resilient Internet site backhaul.
Telecommunications provision with 8 carriers

Electronic access – service

HTTPS access

Remote electronic access to the VPC is limited purely to:

inbound HTTPS for services
a Cisco-secured VPN for management access

The Production system (the sole place where customer information resides) is limited to the two URLs:

https://docs.magicsuite.net/
https://api.docs.magicsuite.net/

Other environments are also present in the VPC, accessible on other HTTPS URLs:

Beta: Early access to new features (Enterprise customers only)
Staging: Staged testing of imminent released (Enterprise customers only)
Test: Panoramic Data Limited access only

Each environment is logically separated and each operates with the same security and access procedures as the Production system.

We maintain a QualSys A rating for HTTPS security, verifiable here:

https://www.ssllabs.com/ssltest/analyze.html?d=docs.magicsuite.net
https://www.ssllabs.com/ssltest/analyze.html?d=api.docs.magicsuite.net

Remote System “Connections”

In order to access external systems, their APIs are accessed via NuGet packages. All libraries are open source and the source code may be reviewed on Github. Panoramic Data author many of these, including:

AutoTask.Api:

https://www.nuget.org/packages/AutoTask.Api/
https://github.com/panoramicdata/AutoTask.Api

LogicMonitor.Api

https://www.nuget.org/packages/LogicMonitor.Api/
https://github.com/panoramicdata/LogicMonitor.Api/

ServiceNow.Api

https://github.com/panoramicdata/ServiceNow.Api
https://github.com/panoramicdata/ServiceNow.Api/

In order to execute manual and scheduled “Report Jobs” against these APIs, it is necessary to store the following information within our secure database. In such cases, the crucial private credential (* below) are stored with two-way encryption, secured by a long private key.

For example:

AutoTask

Username
Password *
Client Access Key

LogicMonitor:

Access Token ID
Access Token Key *

SalesForce

Username
Client Access Key
Password *

ServiceNow

Username
Password *

The system’s private key is randomly generated and is not accessible to users or staff via any mechanism.

Workers

All Report Jobs are executed using a worker pool separate from the Web UI and API. There is no direct access to these workers by any means, including Panoramic Data staff (other than to start/stop daemons and services). It is only within the workers that access to the remote systems (e.g. AutoTask and LogicMonitor) is performed and always via the Connections and always with short connection lives (connections are not re-used between Report Jobs).

Web access control

User access to configure and report output data can only be made via a single, four-tier security architecture, whether for UI or API:

Initial HTTPS access to the web server is secured by a firewall.
Internal (DMZ) access to the web server is further secured by a separate firewall and mandatory username/password authentication into a secure web session.
Data access is controlled by Role-based Access Control (RBAC).
Databases are secured using per-environment database passwords and per-Tenant data isolation. If using the in-built file system, Files are secured in per-Tenant file stores.

Tenant admins

For secure operations, such as Connection configuration, RBAC administration and user administration, the customer must nominate one or more “Tenant Admin” users.

Only a Tenant Admin may create or modify Connections.
Only a Tenant Admin may create or modify specific other items such as Macro Parameter Defaults
Only a Tenant Admin may configure Role-Based Access Control (RBAC)
Only Tenant Admins can control which parts of the User Interface any given user can access.
Only a Tenant Admin may create/authorise or modify users.
It is not possible for Tenant Admins to review password credentials for connections or users.
It is possible for Macro Parameter Defaults to be set write-only such that values are not visible in the user interface.

Super admins

For support purposes, Panoramic Data operations and support staff can also operate the system in the Super Admin role. In this mode, they have access to the same view as the Tenant Admin. Note that Super Admins do not have higher-privilege access to data – all limitations relating to customer data that apply to the Tenant Admins also apply to Super Admins.

Support for denying Panoramic Data staff Super admin rights to a given Tenant is planned for a future release of ReportMagic.

API access control

API access to ReportMagic functions requires a separate access token, configurable only by Tenant Admins.

File access

Input templates and resulting output reports are usually stored in our secure file store and securely backed-up off site to UK-based Microsoft file store.

At the customer’s option, the file system can be entirely within the customer’s own infrastructure. In this case, the customer must provide their own SharePoint or SFTP credentials. If the customer chooses this option, no customer data is stored within the Panoramic VPC other than connection and user credentials. However, most customers choose to use the system-provided file store in order to benefit from the in-built RBAC features.

If the in-built file store is used, it is possible to configure the system such that groups within a tenant's domain do not have access to each others’ reports. Again, this is controlled by the Tenant Admin.

Password security

User passwords used for system access are stored solely as salted, one-way hashes (so cannot be reverse engineered).

Electronic access – management

Service operations staff have remote access to the VPC management systems via a separate Cisco VPN tunnel for the purposes of platform operation and maintenance only.

Data retention

The raw data as retrieved from the system API only exists transiently in memory within the workers (inaccessible to ANYONE, including us) and is NOT stored in our systems beyond the life of report generation.
The resultant, customer-facing reports e.g. PDFs MAY OPTIONALLY be (in any combination):

Stored in our filesystem;
Emailed to the nominated recipient(s); and/or
Transferred to your own report storage (SharePoint / SFTP) server

Metadata relating to report execution (e.g. when started, whether executed successfully, how long they took to execute etc.) are retained.

ReportBatchJobs (A “report run” e.g. a single monthly run across 50 customers)
ReportJobs (A single customer report within a ReportBatchJob)
ReportMacroResult (A single report macro within a ReportJob – e.g. [LogicMonitor.Graph: <queryDefinition>] or [AutoTask.TicketCount: <queryDefinition>] ). This MAY contain the output from a query (for the benefit of the report developer during report template development), but this is optional and under the report designer’s control.

Version 2.18 onwards allows the automated data aging of customer-facing reports in the file system configured at either the Tenant or Report Schedule level.
As of September 2020 and subject to change, metadata is retained:

ReportBatchJobs: 366 days
ReportJobs: 200 days
ReportMacroResults: 15 days

Metadata is not stored encrypted, but then nor is there any sensitive information stored therein.

Code quality procedures

Secure Design

ReportMagic system architects consult with the development team to ensure that the design adheres to security principles relating to:

Credential storage
Data transfer protocols
Architectural separation of concerns
Data retention security
Data retention timescales

The system architects are responsible for identifying security gaps and threats that designs or changes to the design may introduce and for ensuring that remediations are assigned the highest priority. System architects are responsible for ensuring that the development team have a full understanding of security best practices, as relate to SaaS services.

We conduct threat modelling when designing each application/system. As standard, each application is considered to be at threat of public access, and treated accordingly. As standard, all applications expose only a single incoming HTTPS, meaning that most threat analytics in the SDLC focuses on this attack vector. Additional attack vectors for privileged users are also considered during the design phase.

Secure development

Code quality during development is maintained via:

Automated static code inspection, including:

The latest .NET analysers at compile time
SecurityCodeScan at compile time

These tests must pass before a build is sent to downstream Quality Assurance processes.

Quality assurance

We use industry standard static code inspection techniques to enforce security best practices at development time. We use external security auditors to review code, assess adherence to best practices and actively test the resultant applications/systems.

Code quality is ensured outside of the development process via:

Functional testing, controlled by our Q/A team using JIRA
Integration testing, controlled by our Q/A team using JIRA
Regression testing, controlled by our Operations team

The use of Microsoft Entra ID is mandatory for user authentication.

External protocol security is via HTTPS with an Qualys SSL Labs "A" grade required for HTTPS access. The latest results can be seen here:

https://www.ssllabs.com/ssltest/analyze.html?d=docs.magicsuite.net&latest

Other, non-disclosed external penetration tests are completed to ensure the highest standards of intrusion resistance, and such tools are periodically reviewed. In addition, we subscribe to security advisories from our technical vendors and any such advisory that affects our hardware or software will result in a high priority ticket being created for expedited remedy.

All of the above must pass before a release can be pushed to Production. Operations control the release to Production.

Issue reporting and remedy

Despite best efforts, software defects can occur. Any Panoramic Data staff member or user of the system may use the system’s in-built “feedback” mechanism to:

Raise a defect
Suggest an improvement
Request support

In all cases, the reporter is given a unique ticket ID, which can be used to track the issue. Release notes are available in-product.

All tickets raised by customers are brought to the immediate attention of our Support team. Customer-raised bug reports are always treated with the highest priority. Depending on the severity, we may choose to issue an “emergency patch” to the Production system. Any such patch is limited to the minimal code-base change required to remedy the immediate issue and is peer code-reviewed and tested before Production is patched.