System security overview

Overview

stSoftware designs systems to meet or exceed all aspects of the Australian Government Protective Security Policy Framework PSPF. At stSoftware, we take security very seriously. Our ephemeral workload servers are locked down to be accessed only via bastion hosts; the support team can only access the bastion hosts themselves via secure shell from specific IP addresses. 

stSoftware follows Infrastructure as Code principles for all AWS services.

Network design

Best practice network design for a fully redundant, fault-tolerant stSoftware server cluster has:-

• No single point of failure. 
• Fault-tolerant
• Defence in depth
• Load balancing
• Lowest possible permissions/access for each component
• Health monitoring of each component

Server Lockdown

All Linux servers are locked down to the highest security standards possible. All services are off by default and all ports shut. Only the required services started. 

• Install and run only the services you require.
• Block all ports by default and open only those that are required
• Run servers as low permission user
• Disable direct login to ROOT altogether.
• Block SSH login attempts from unknown locations and machines.

Password Management

The system administrator can configure the system password options to find the correct balance between convenience and security. Job track application administrators can configure the password and login options at the user level also.

Job Track Data Access Layer 

All protocols access the underlying data through the DAL (data access layer). There is NO direct access to the underlying data store, no matter which protocol is used. Each protocol accepts the request to read or write data and then perform the protocols validations and then pass the request on to the DAL to execute the request, which validates the request, checks the user's access, and performs any validations before returning the result.

Standard SQL injection and Cross-Site Script attacks are performed on each component as part of normal nightly unit testing. 

References

• https://www.sans.org/reading-room/whitepapers/detection/identify-malicious-http-requests-34067