Configuring SSL/TLS security for the Web/REST Service

While SSL/TLS security configuration for the FTPS protocol is entirely self-contained, Server!’s Web/REST service relies on Windows’ HTTP.SYS subsystem, which is the same subsystem IIS is based on, and therefore its security configuration has to be made at operating system level.

In order to ease the process we recommend Natarc’s IISCrypto, a free and powerful utility that helps achieving the task with just a few mouse clicks. Continue reading

White paper: a solution for healthcare

This totally free White Paper discusses the needs of healthcare providers and institutions, debunks some myths, and explains how to achieve the required levels of security and compliance.

Feel free to download it and use it under the CC BY-NC-ND 4.0 license.

Download “Solution-for-Healthcare-Complete.pdf” Solution-for-Healthcare-Complete.pdf – Downloaded 98 times – 732 KB Server! v4.0.6 released

We have just released version 4.0.6 of our Server! software. This version features the following improvements:

  • Two distinct PCI-compliant configurations to prevent backward compatibility issues
  • Better support for Internet Explorer (still not the recommended browser though)
  • Fixed an issue with self-signed X.509 certificate serial numbers

As usual you can download this new release from our website.

Understanding the security “preset configuration” Server! version: 4.0.0+

In the new Server! v4.0, there’s a quite handy feature that allows a one-click configuration of many security settings at once, depending on the virtual server’s intended usage scenario.


Here’s a brief explanation of what each preset configuration means and what to expect when you apply it: Continue reading

PCI and HIPAA compliant administrative logs Server! version: 4.0.0+

Another requirement found in the latest versions of both PCI-DSS and HIPAA regulations is the necessity to keep an “untamperable” log of all configuration operations performed by any administrator.

Digitally signing every single log line is not enough, as the disloyal employee could simply delete some log lines entirely. Therefore each line should have a numeric incremental ID (to make it easier to spot “holes”) and each line’s digital signature should “roll over” and be calculated including the previous line’s digital signature in the signed data. This way an administrator cannot delete one (or several) log lines without being spotted.

Furthermore, to make log analysis even easier, each log line is not actually just a “line of plain text”, rather it’s a JSON object that can be easily queried. Here below you can see a typical “log line” showing a call to a configuration REST API and the relative response and signature: