Hosting, Security and Monitoring

Audienceware provides managed hosting and support for websites, CRM platforms and related digital systems, primarily for not-for-profit and purpose-driven organisations. Our hosting model is designed to provide a practical balance of reliability, performance, security and affordability.

This page explains how we host client platforms, the security and monitoring measures we commonly use, and the important assumptions and limitations that apply, especially where older or legacy software is involved.

Our hosting approach

Audienceware hosts and manages digital platforms using cloud infrastructure, server-level configuration, application-level maintenance, monitoring tools and support processes.

Our role may include:

hosting websites, CRM systems and related applications;
configuring and managing server environments;
applying server-level security patches;
maintaining backups and recovery processes;
configuring CDN and WAF services where appropriate;
monitoring server availability and performance;
reviewing logs and security signals;
responding to support tickets and incidents;
advising on upgrades, risk reduction and platform modernisation.

The exact scope for each client depends on the agreed engagement, support plan, hosting arrangement, statement of work, managed service agreement or other commercial terms.

Server-level security configuration

At the server level, we apply a layered security model. Depending on the platform and hosting arrangement, this may include:

operating system patching and package updates;
web server configuration and hardening;
PHP/runtime configuration appropriate to the hosted application;
database server configuration;
SSL/TLS certificate configuration;
firewall rules and access restrictions;
file ownership and permission controls;
separation of application code from writable cache, log and upload directories where practical;
prevention of executable files running in upload or media directories where compatible with the application;
disabling public directory indexes;
protection of sensitive administrative paths;
server-level bot blocking or IP blocking where required;
backup and recovery configuration.

A key security principle is that the web server should only be able to write to the areas it genuinely needs, such as cache, logs and upload directories. Application code, configuration files and templates should not normally be writable by the web server process. Where practical, Audienceware applies file ownership and permission rules to reduce the risk of a compromised web process modifying application code.

Server-level hardening needs to be implemented carefully. Some older CMS platforms require write access to particular directories, rely on legacy URL structures, or behave unexpectedly if standard modern restrictions are applied. For that reason, configuration changes must be tested to avoid impairing production functionality.

Application-level security

At the application level, security depends heavily on the software stack.

For supported platforms such as current versions of Drupal, WordPress, CiviCRM and common plugins, modules or extensions, Audienceware may apply routine maintenance, including:

core CMS updates;
plugin, module or extension updates;
compatibility checks;
security patches;
configuration reviews;
issue resolution where updates cause unexpected behaviour.

Where available and appropriate, we may also use application security tools such as Wordfence for WordPress or equivalent platform-specific protections.

Application-level hardening may include:

restricting administrative access;
enforcing stronger user roles and permissions;
protecting login and password reset paths;
disabling or restricting plugin and theme installation through the CMS user interface where appropriate;
disabling or controlling automatic updates where they may conflict with managed maintenance processes;
limiting user-generated content areas;
preventing uploaded content from becoming executable code;
protecting forms from automated abuse;
applying reCAPTCHA or challenge rules to suspicious requests;
reviewing logs and adjusting application-specific protections over time.

Application-level security works best when software is current and supported. Current software benefits from vendor security advisories, community reporting, patch releases, public documentation and a broader ecosystem of defensive knowledge. This is one of the main reasons we recommend upgrades and rebuilds when platforms become too old to maintain safely.

CloudFront, CDN and WAF

Audienceware commonly uses AWS services as part of its hosting architecture.

AWS CloudFront may be used as a content delivery network to improve performance and reduce load on origin servers. CloudFront can also integrate with AWS WAF, giving an additional security layer before requests reach the application server.

AWS WAF is not just a static firewall. It allows hosted platforms to benefit from AWS-managed security intelligence, including known suspicious behaviour patterns, known bad bots, IP reputation data, anonymous IP detection and common exploit signatures.

AWS WAF protections may include:

SQL injection detection;
cross-site scripting detection;
known bad IP reputation rules;
anonymous IP rules;
bot control rules;
rate limits;
country or region-based restrictions where appropriate;
detection of malformed or suspicious requests;
managed rule groups maintained by AWS or trusted security vendors;
custom rules based on observed traffic patterns.

Audienceware may also add client-specific and application-specific WAF rules, including:

protection for login paths;
protection for administrative paths;
rate limiting on sensitive endpoints;
challenge or reCAPTCHA rules for suspicious requests;
bot and scraper controls;
IP allow/block rules;
exceptions for legitimate callbacks such as payment gateways or trusted integrations;
additional rules based on traffic observed in logs.

WAF is a powerful perimeter control, but it is not a complete replacement for secure application code, current software, correct permissions, safe upload handling, strong passwords, or regular maintenance. Some attacks can only be prevented or remediated at the application or server level.

Custom server and application protections

In addition to WAF, Audienceware may apply custom server-level and application-level rules where required.

These may include:

rules preventing PHP or other executable files from running in media and upload directories;
rules blocking suspicious file extensions in user-upload areas;
controls preventing public browsing of directories;
restrictions around legacy administrative tools;
HTTP rules for suspicious request paths;
IP-based restrictions for sensitive endpoints;
reCAPTCHA or challenge rules for suspicious requests;
protection against automated form submissions;
custom rules for known attack patterns seen in access logs;
file ownership and permission changes to prevent the web process from altering application code;
restrictions on plugin, module or theme installation via the CMS interface where appropriate;
controls on automatic updates where these need to be managed centrally rather than triggered through the UI.

These controls are most effective when they are designed around the actual application. A modern WordPress site, a current Drupal/CiviCRM platform and an old legacy CMS may each require different controls.

For legacy systems, custom protections need to be applied carefully. A control that is sensible for a modern application may break older software if the software depends on public media paths, writable directories, old routing behaviour or legacy administrative workflows.

reCAPTCHA and challenge rules

For suspicious or high-risk requests, Audienceware may use challenge mechanisms such as reCAPTCHA or equivalent controls.

These are most useful where a request may be legitimate but has risk indicators, such as:

unusual request frequency;
repeated failed form submissions;
access to sensitive paths;
automated login attempts;
suspicious user agents;
abnormal geographic or IP behaviour;
requests matching known bot or scanner behaviour.

Challenge rules are not a complete security solution, but they can reduce automated abuse while still allowing legitimate users to proceed.

Monitoring

Audienceware uses multiple forms of monitoring depending on the hosting environment and client arrangement.

Monitoring may include:

server availability monitoring;
server resource monitoring, including CPU, memory and disk usage;
uptime and service checks;
AWS WAF logs and metrics;
web server access and error logs;
Elasticsearch / ELK-based log analytics;
review of traffic patterns, bot activity and suspicious requests;
support ticket monitoring;
BobCares server monitoring and support;
alerts for major server or service failures.

Monitoring helps detect outages, performance degradation, hostile traffic and unusual behaviour. However, monitoring does not guarantee that every compromise, content injection, SEO spam event or application-level issue will be detected immediately.

Some attacks are deliberately designed to avoid detection. For example, a site may show normal content to ordinary users while showing different content to search engines, bots, link-preview tools or specific user agents. These issues may not appear as a conventional outage and may require targeted investigation.

Log monitoring and traffic analysis

Audienceware may use log analysis to identify suspicious behaviour and performance issues.

This can include reviewing:

repeated requests to sensitive paths;
bot and scraper traffic;
failed login attempts;
abnormal POST requests;
requests to upload directories;
requests for known exploit paths;
traffic from suspicious IP addresses;
unusual spikes in traffic;
WAF-blocked or challenged requests;
server errors and application warnings.

Where patterns are identified, Audienceware may respond by adjusting WAF rules, adding server-level blocks, tuning rate limits, applying reCAPTCHA rules, or recommending application changes.

Log monitoring is a practical and scalable way to identify common threats. It is not the same as continuous forensic review of every line of application code or every possible content change.

Software monitoring and security advisories

For current and supported software, Audienceware can monitor security advisories and apply available updates or patches as part of routine maintenance, subject to the client’s agreement and the compatibility of the platform.

This is practical because supported software has an active vendor or community ecosystem. Security issues are disclosed, patches are released, and the recommended remediation steps are generally known.

Outdated or unsupported software is different. Once software is no longer supported, there may be:

no vendor security advisories;
no official patches;
no compatibility testing with current server software;
limited public guidance;
reduced community knowledge;
increasing incompatibility with modern PHP, database and operating system versions;
greater risk that standard security controls will break functionality.

This means unsupported software cannot be monitored and maintained in the same way as current software. We can still apply server-level controls, access restrictions, WAF rules and best-effort hardening, but we do not have the same benefit of vendor advice, patch releases or community-supported remediation.

Legacy software assumptions and limitations

Some clients operate legacy systems that remain important to their organisation but are too old to be updated safely without a rebuild or migration.

For legacy systems, Audienceware may be able to provide:

hosting continuity;
backups;
server-level hardening;
access control improvements;
WAF or CDN configuration where compatible;
bot control or rate limiting;
reCAPTCHA or challenge rules where compatible;
log review;
incident response;
advice on upgrade or replacement pathways.

However, legacy software carries inherent risk. If the core application cannot be patched, the risk cannot be fully removed by hosting controls alone.

In these cases, the realistic options are:

continue to host with best-effort hardening and monitoring;
reduce public exposure, for example by firewalling, archiving or limiting access;
migrate content to a supported platform;
rebuild the application on current software;
decommission the legacy system if it is no longer required.

Bespoke security monitoring

Comprehensive bespoke security monitoring for an unsupported or custom legacy application is possible, but it is a specialist project, not a routine hosting inclusion.

It would require senior developer and security analysis time to:

understand the application’s codebase and architecture;
map normal and abnormal application behaviour;
review upload, login, search, form and administrative functions;
identify what controls can be added without breaking functionality;
create bespoke monitoring rules;
implement application-specific logging;
review logs regularly;
tune false positives and false negatives;
adjust WAF, server and application rules over time;
document known risks and accepted limitations.

This can be done, but it is closer to enterprise-grade security engineering than standard managed hosting. For many not-for-profit clients, the budget required for that level of bespoke review is difficult to justify compared with the alternative of upgrading to a supported software platform.

The most cost-effective security model is usually to standardise on current, well-supported software. This allows clients to benefit from thousands of hours of vendor, community and industry security work, as well as the experience Audienceware gains across its broader client base.

Responsibilities and shared risk

Security is a shared responsibility.

Audienceware is responsible for the hosting, monitoring and support activities included in the agreed scope.

Clients are responsible for:

approving upgrade or rebuild recommendations;
maintaining appropriate user access;
removing users who no longer require access;
using strong passwords and multi-factor authentication where available;
avoiding unsafe third-party plugins or unsupported customisations;
reporting suspicious behaviour promptly;
prioritising security-related tickets appropriately;
approving budget where additional investigation, remediation or upgrade work is required.

Where software is outdated, unsupported or outside normal maintenance pathways, Audienceware will advise on risk and options, but continued operation of that software may involve accepted risk.

Incident response

If suspicious activity is detected, Audienceware will generally follow an incident response process appropriate to the severity of the issue.

This may include:

confirming the issue;
preserving evidence where practical;
reviewing logs and file changes;
checking whether the issue is application, server, DNS, CDN, WAF or search-index related;
applying immediate containment measures;
removing or quarantining malicious files where appropriate;
strengthening permissions or access controls;
rotating credentials where required;
restoring from clean backups where appropriate;
requesting search-engine re-indexing if SEO spam has occurred;
advising on longer-term remediation.

Some investigations can be handled as standard support. More complex investigations, especially involving unsupported legacy code, custom development, SEO spam, cloaking or forensic analysis, may require additional project or senior developer time.

Why upgrades matter

Security controls are strongest when they operate together:

current software;
vendor security patches;
community security knowledge;
hardened hosting;
WAF/CDN protections;
monitoring;
backups;
disciplined user access;
tested incident response.

When one layer is weak, the other layers become more important. When the core application is obsolete and cannot be patched, hosting controls can reduce risk but cannot remove it completely.

For this reason, Audienceware recommends that business-critical websites and CRM systems be kept on supported software, or migrated to a supported platform when their current software reaches end of life.

Summary

Audienceware provides practical managed hosting, monitoring and security controls designed for the not-for-profit sector.

We use a layered approach that may include server-level hardening, AWS services such as CloudFront and WAF, AWS-managed security intelligence, custom WAF and server rules, reCAPTCHA challenge rules, application maintenance, log monitoring, BobCares server monitoring and support processes.

For current software, routine updates and security advisories provide a strong maintenance path.

For legacy software, we can apply best-effort hosting and hardening controls, but unsupported software remains an inherent risk. Comprehensive bespoke monitoring of old or custom software requires dedicated senior technical effort and should be treated as a separate project or upgrade pathway, not assumed as part of standard low-cost hosting.