|
|
Security
The Agent Guidance Application is compatible with a number of server and network security technologies.
The Agent Guidance Website is compatible with SSL certificates defined within the IIS binding, enabling HTTPS (SSL) client connections. No configuration within Agent Guidance is required. The Agent Guidance Website is port and hostname agnostic, allowing full flexibility in IIS binding configuration. These configuration items must be carried out post-install within Windows IIS Manager.
As each element of a Agent Guidance System utilises different technologies, a TLS compatibility matrix is provided below:
|
Agent Guidance System Element
|
Connection Endpoints
|
TLS Compatibility Level
|
Notes
|
|
IIS Website
|
User to IIS Website
|
TLS 1.0+
|
Microsoft IIS supports all TLS versions.
|
|
Microsoft SQL Server
|
IIS Website to SQL Server
|
TLS 1.0+
|
Microsoft SQL Server supports all TLS versions when enforced from the server endpoint as discussed in this Microsoft Blog Post.
|
|
Redis
|
IIS Website to Redis Node(s)
|
TLS 1.2
|
Redis support TLS-encrypted communications with some broader considerations, as discussed in the Redis Security Article, and further information can be found in the Redis TLS Support Article.
|
It is advised that a firewall prevents access to the Agent Guidance website and servers from non-user computers and networks. Details on the required access ports for your specific configuration can be found under the Application Layer section.
The Agent Guidance website is built upon Microsoft .NET technologies that if implemented incorrectly can be insecure. While every effort has been made to secure the Agent Guidance website, these technologies will cause it to fail higher level security scans due to potential risks. For this reason, it is advised to firewall the application and insulate it from all high-risk attack surfaces and scanning surfaces.
There are a number of technologies and facilities that exist within the Agent Guidance product to allow Workflow designers to create their bespoke Workflows, and this can have security implications if unsafe behaviour is undertaken.
Workflow designers have the option to utilise JavaScript code while creating Workflows via the default Agent Guidance Controls. This code would run locally within the user's web browser, and so all Workflow designers must consider the security implications of what they code. Special care should be taken if you choose to execute user input directly, e.g. via the JavaScript eval() command.
Agent Guidance Controls will pass all data through to the Microsoft SQL Server database via parameterised SQL stored procedures. However, Workflow designers can utilise Controls like the External Data Source to execute bespoke SQL queries, including Workflow captured data. Care should be taken when writing these bespoke SQL queries to follow appropriate security guideline for your usage case. Typical security considerations include calling SQL Stored Procedures, passing in all data as parameters, and not executing Workflow data directly, e.g. via the Microsoft SQL Server exec command.
There are some points of consideration relating to the Agent Guidance Database and its security.
Data captured in to the Agent Guidance Application is stored in the Agent Guidance Database to facilitate the application's use. Once data is no longer required for the Agent Guidance application, it can be removed via a SQL Database Maintenance process.
The Agent Guidance Application controls access to configuration and Workflow data captured though the Agent Guidance Website. All passwords stored for system configuration are encrypted at rest within the Agent Guidance Database, and as all Workflow captured data is stored natively within Microsoft SQL Server, care should be taken when planning SQL access. Particular consideration should be given to the SQL Access Authentication account and whether Windows Authentication is being used, as detailed below.
The Agent Guidance Application only encrypts system configuration passwords stored within the Agent Guidance Database, but it is possible to encrypt the Agent Guidance Database itself using a SQL Server feature. Only SQL Server's Transparent Data Encryption (TDE) method is supported, with no support for the Always Encrypted (AE) method. While use of TDE is a valid method to manage specific risks, it will require consideration of any potential limitations, such as:
-
Only available for SQL Server Enterprise edition.
-
Only covers the data while at-rest; specifically the actual database files and logs on disc.
-
Encrypts all data within the target database on the server, rather than only specific columns.
-
Backups can't be compressed as much due to being encrypted (randomised).
-
There is a minor performance penalty, and this will apply to all databases located on a server that has any encrypted databases.
-
If the database encryption details are lost, then backups will be unusable.When a Agent Guidance system is running in the Windows Authentication Scheme, there can be additional security implications to consider depending upon the Windows Authentication Configurations at the website and SQL connection levels. These security considerations are most relevant when the Agent Guidance Website is configured to use End-User Impersonation.The account being used for website resource authentication will have the modify permission on the files under the root of the Agent Guidance Website. On a standard Windows server, the Agent Guidance deployment process will not grant any additional network file access. However, any bespoke access policies for the users on the Agent Guidance webserver will need to be configured with this in mind.The account being used for SQL access authentication will have limited access to the Agent Guidance database. This access is restricted to running the SQL Stored Procedures and the limited SQL table access that the Agent Guidance application requires to function. If the end-users have access to the account details being used for SQL authentication, then preventative network or SQL access measures may be required between the end user devices and the Microsoft SQL Server servers to prevent this undesired direct end-user access. These preventative measures can include blocking connectivity to Microsoft SQL Server directly from end-user devices, or only allowing access from the Agent Guidance webserver(s).