Assessment.jpg

Looking For A Fresh Pair Of Eyes On Your Setup?

Let our team take a look under the hood and give you an honest, comprehensive assessment on the state of your setup. Whether you’re looking to spot weaknesses, find areas of improvements, or just want to be sure that you’re up to scratch, we’ll provide you the lowdown on:

  • Servers

  • Application Servers

  • Databases

  • Best Practices

Read our blog post on how a second pair of eyes can aid your setup.


Let’s Do It

Want to learn more? Submit your details and we’ll be in touch.


What Do We Take A Look At?

Servers

We perform checks on all servers in a number of key areas. These include but are not limited to:

OS Support & Patching

  • Is the OS currently supported and receiving security patches?

  • Are systems currently up-to-date with the patches they need?

Logging

  • Are there any outstanding issues in system logs?

  • Are there any issues with the logging setup that could lead to “disk full” scenarios or lost data?

Security

  • Are system logins hardened to industry standards?

  • Will malicious login attempts automatically be banned from the system?

  • Are tools like firewalls and SELinux enabled and setup correctly?

System Performance Metrics

  • Is the system running out of CPU, memory, or disk I/O?

  • Should the system be scaled up/down to save money or ensure good application performance?

Application Servers

These would be checked for a number of application-specific health benchmarks:

High-Availability

  • If the application crashes, will it automatically be restarted?

  • If a server crashes, are there others that will automatically handle application traffic until the

    server recovers?

Logging

  • Are the application logs useful for debugging and monitoring access?

Configuration & Deployment

  • Are secrets used by the application protected adequately?

  • Is the deployment process consistent, and is the version of the application in source control the same as what’s on the server (or have there been manual code changes made in production)?

Statelessness

  • Are the applications storing any state information locally instead of in a shared resource like a database?

Databases

These include but are not limited to:

Backups

  • Do you have a tested database restore procedure?

  • What is your backup retention period?

Performance

  • Is the database keeping up with load from the application servers?

Environment Separation

  • Are the production and staging environments appropriately separated (and there’s no possibility of changes in staging accidentally unsettling production data)?

Security

  • Is encryption enabled at-rest and in-transit?

  • Is the database setup securely?

What Should Your Team Look At?

Best Practices

  • Do you have an APM tool to monitor your application for performance bottlenecks, database metrics, and poorly-performing code?

  • Do you have an external monitoring tool that monitors for outages and external availability of your website?

  • Can you easily search your logs?

  • Do you have a way of viewing system metrics easily and setting alerts to notify you when problems occur?

  • Do only authorized users have access to your environment (be it SSH, AWS IAM, or other credentials)?

  • Is all web traffic encrypted using TLS 1.2+? Do you have alerts for expiring certificates or automated

    certificate renewal setup?

  • Has your environment been built using “infrastructure-as-code” tools and config management to ensure

    that only authorized changes have been made and you can rebuild infrastructure as needed?

  • Is your application sitting behind a WAF or other DDOS-protection tool that prevents an attacker from

    taking down your site? Are the public IP addresses of your servers available for a malicious user to attack directly?