Security AWS

SimpleRisk GRC and Risk Management on AWS User Guide

| Product: SimpleRisk GRC and Risk Management | Support by cloudimg

Overview

SimpleRisk is the widely used open source governance, risk and compliance (GRC) platform that organisations run their risk register on. Capture and score risks using the CLASSIC, CVSS, DREAD or OWASP methodologies, plan and track mitigations and management reviews, run compliance audits against frameworks and controls, manage assets, and report on the whole organisation's risk posture from one shared system.

The cloudimg image ships SimpleRisk served by nginx and PHP 8.3 on a hardened, fully patched Ubuntu 24.04 LTS base, together with a bundled local MariaDB server so the appliance is complete and useful on its own. The database schema is loaded and the browser setup wizard is completed and closed at build time, so the application shows a normal login page the moment the instance boots rather than an open, unauthenticated create administrator form. The bundled MariaDB listens only on the loopback interface (127.0.0.1:3306) and keeps its data on a dedicated EBS data volume. No administrator password exists anywhere in the image: a unique one is generated on the first boot of every instance. Backed by 24/7 cloudimg support.

What is included:

  • SimpleRisk 20260519-001, installed from the official upstream release bundle and database schema
  • nginx with PHP 8.3, OPcache and every PHP extension SimpleRisk requires (pdo_mysql, xml, mbstring, ldap, curl, gd, zip, intl, bcmath, apcu)
  • MariaDB bound to 127.0.0.1:3306, with its data directory on a dedicated 20 GiB EBS data volume
  • A first boot service that generates a unique administrator password and a unique database password for every instance
  • The setup wizard completed and closed, so no unauthenticated first run form is exposed
  • An unauthenticated /healthz endpoint for load balancer health checks

Connecting to your instance

Connect over SSH as the default login user for your operating system variant, using the EC2 key pair you selected at launch:

OS variant SSH login user
Ubuntu 24.04 LTS ubuntu
ssh -i /path/to/your-key.pem ubuntu@<instance-public-ip>

Prerequisites

An AWS account, an EC2 key pair in the target region, and a VPC with a subnet. m5.large (2 vCPU / 8 GiB RAM) is the recommended size for most teams; move up to m5.xlarge for large risk registers, many concurrent assessors or heavy reporting. Security group inbound: allow 22/tcp from your management network for SSH, 80/tcp for the application and 443/tcp if you terminate TLS on the instance. The bundled MariaDB is never exposed: it listens on 127.0.0.1 only, so port 3306 stays off the network. Because a GRC tool holds sensitive risk data, restrict the security group source ranges to trusted IPs and put TLS in front before you put the register into use.

Step 1 - Launch from AWS Marketplace

Subscribe to the listing in AWS Marketplace, choose Continue to Configuration and then Continue to Launch, or launch it directly from the EC2 console with Launch instance from AMI. Pick the m5.large instance type, select your EC2 key pair, and choose or create a security group that allows inbound 22, 80 and 443. The image attaches its own 20 GiB EBS data volume for your risk register database, so you do not need to add one. Launch the instance and wait for its status checks to pass.

Step 2 - Confirm the services are running

SSH to the instance as ubuntu and confirm nginx, PHP-FPM, MariaDB and the first boot service are all active. MariaDB is bound to 127.0.0.1:3306 only, while nginx serves on port 80.

systemctl is-active nginx php8.3-fpm mariadb simplerisk-firstboot
active
active
active
active
ss -tlnp | grep -E ':80 |:3306 ' | sed 's/  */ /g'
LISTEN 0 511 0.0.0.0:80 0.0.0.0:*
LISTEN 0 80 127.0.0.1:3306 0.0.0.0:*
LISTEN 0 511 [::]:80 [::]:*

The unauthenticated health endpoint returns 200 for load balancer probes:

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/healthz
200

Step 3 - Retrieve the per instance administrator password

The first boot service generates an administrator password unique to your instance and writes it, along with the address to browse to, to a root only file. Read it over SSH:

sudo cat /root/simplerisk-credentials.txt
simplerisk.url=http://<instance-public-ip>/
simplerisk.admin.user=admin
simplerisk.admin.pass=<your-per-instance-password>
simplerisk.db.name=simplerisk
simplerisk.db.user=simplerisk
simplerisk.db.pass=<your-per-instance-db-password>

The admin.pass value is the web login password; the db.pass value is the internal application to database password and you do not normally need it. Keep this file safe and change the administrator password after your first sign in.

Step 4 - Sign in

Browse to http://<instance-public-ip>/ and sign in as the admin user with the password from the credentials file. SimpleRisk derives the address it uses from the request, so it works on the public IP, a private IP, or a DNS name you point at it, with no reconfiguration.

The SimpleRisk sign in page with the username and password fields and the Login button

Step 5 - Capture and score your first risk

Open Risk Management in the left menu and choose Submit Risk. Give the risk a subject, pick a category, source and site or location, and choose a scoring method. SimpleRisk supports the CLASSIC, CVSS, DREAD and OWASP methodologies, so you can score consistently with whatever framework your organisation already uses. Save the risk and it enters the register ready for review, mitigation planning and management review.

The SimpleRisk Submit Risk form showing the subject, risk and threat mapping, category, risk source and scoring method fields

Step 6 - Track your risk posture on the dashboard

Open Reporting and choose the risk dashboard to see your open risks broken down by risk level, status and site or location. This is the single shared view of the organisation's risk posture that everyone works from.

The SimpleRisk risk dashboard showing open risks with donut charts broken down by status and site or location

Step 7 - Run reports from the reporting hub

The reporting hub under Reporting gives you a searchable catalog of reports grouped by Risk Management, Compliance, Governance and Asset Management, with a Favorites view for the ones you use most. Use it to produce the risk register, compliance and audit reports your reviews and stakeholders need.

The SimpleRisk reporting hub showing the searchable report catalog with category filters and a favorites section

Step 8 - No known or default credentials

Because a GRC tool holds an organisation's risk register, this image ships with no known credential. A fresh SimpleRisk install exposes an open, unauthenticated create default administrator form on first browse whenever the user table is empty. This image is built past that point: the administrator account exists, so the login page is shown rather than the open wizard, and the administrator password is rotated to a fresh random value on the first boot of every instance. There is no admin/admin and no shared password anywhere in the image.

You can verify this on your own instance. The user table holds a single administrator, and blank plus common weak passwords, including admin/admin, are all rejected by the web login:

sudo /usr/local/sbin/simplerisk-cred-roundtrip.sh
OK per-VM admin authenticates via the web login form; blank + weak guesses (incl. admin/admin) rejected

Step 9 - Verify the stack and where your data lives

Your entire risk register lives in MariaDB, and MariaDB keeps its data directory on a dedicated 20 GiB EBS data volume mounted at /data (bind mounted onto /var/lib/mysql), separate from the operating system disk so you can resize or snapshot it independently.

findmnt -no SOURCE,TARGET,FSTYPE /var/lib/mysql; df -h /data | sed 's/  */ /g'
/dev/nvme1n1[/mysql] /var/lib/mysql ext4
Filesystem Size Used Avail Use% Mounted on
/dev/nvme1n1 20G 202M 19G 2% /data

MariaDB is bound to the loopback interface only, so the database is never reachable from the network:

sudo grep -h bind-address /etc/mysql/mariadb.conf.d/*.cnf | grep -v '^#'
bind-address            = 127.0.0.1
bind-address = 127.0.0.1

Adding a domain name and HTTPS

For production use you should put SimpleRisk behind a DNS name and TLS. Point an A record at the instance, then install a certificate with Certbot. nginx is already the web server, so the nginx plugin configures TLS for you:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d your-domain.example.com

SimpleRisk reads the address from the request, so it starts answering on your new HTTPS name with no further changes. Restrict the security group so that ports 80 and 443 are reachable only from your users, and keep SSH limited to your management network.

Backing up

Your risk register, compliance data and audit trail all live in the MariaDB simplerisk database. Take a logical backup with mariadb-dump, and for whole disk backups snapshot the EBS data volume mounted at /data:

sudo mariadb-dump --protocol=socket simplerisk > simplerisk-backup-$(date +%F).sql

Store backups off the instance, for example in Amazon S3, and test a restore periodically.

Security notes

  • The administrator and database passwords are unique per instance and generated on first boot; there is no default or shared credential in the image.
  • MariaDB listens on 127.0.0.1 only and is never exposed to the network.
  • The includes directory that holds the database configuration is denied from the web, and the database configuration file is never web fetchable.
  • Restrict the security group source ranges to trusted IPs and enable HTTPS before putting the risk register into use.
  • Keep the operating system patched with sudo apt-get update && sudo apt-get upgrade.

Trademark

SimpleRisk is a trademark of its respective owner. cloudimg is not affiliated with or endorsed by the SimpleRisk project. This image packages the open source SimpleRisk software with additional configuration and 24/7 support provided by cloudimg.

Support

cloudimg provides 24/7 technical support for this SimpleRisk GRC AMI by email (support@cloudimg.co.uk) and live chat, covering deployment and initial configuration, TLS and reverse proxy setup, network access hardening, LDAP and SAML integration, version upgrades, MariaDB database administration and troubleshooting. Critical issues receive a one hour average response time.