This article provides an overview of SystemWeaver's architecture and application security model. Security must be seen as a total system property, with all mechanisms and routines taken into consideration.

An is Overview of Data Security Features also available.


Architecture Security

The security architecture model should be designed to keep your server safe from cyber threats. This includes components, such as anti-virus and anti-spyware, firewall(s), to block unauthorized access to your network, and Virtual Private Networks (VPNs), to provide secure remote access.



Server Machine

  • Server application
  • Configuration files
  • Database (SQLite)
  • Log files

Recommendations

Requirements

  • Only 2-5 trusted users should be able to access the server. 
  • Only accessible inside the organization.


Backup Server Machine

  • Backup database
  • Backup configuration files

Recommendations

  • Only 2-5 trusted users should be able to access the server.
  • Manage passwords of system accounts.
  • Only accessible inside the organization.
  • Consider physical security of the server.


Clients Inside Organization

  • swExplorer client
  • swAdmin client
  • swArchitect client
  • API applications


Recommendations

  • Restricted access to swAdmin and swArchitect clients


VPN for Secure Remote Access to Inside Organization

  • VPN secures network authentication

Recommendations

  • Require use of VPN to access SystemWeaver when using the clients from outside the office.
  • Do not make open ports public on the internet.

Application Security

The application security model covers data security enforced by the SystemWeaver server and client applications. 


Server Application

  • Ensures authenticity of the connected users. 
  • Ensures that users can only access data they have permissions to. 
  • Ensures that users can only do the operations they are authenticated for.
  • Handles the authenticity and correctness of all API calls.
  • Option to encrypt SystemWeaver system account password in server configuration file.
  • Secure password storage on server using salt and hashing.
  • Encryption option* between client and server applications.

Recommendations

  • Server should be protected by extra firewall, or be on a protected VLAN.

Requirements

  • Only a few trusted users should be able to access the server machine.


swExplorer Client

Recommendations

Requirements

  • Educate users about the need to assign sensitive data to proper library to secure confidentiality.
  • Actively work with groups and user permissions for sensitive data.


swAdmin Client 

  • All calls and credentials are verified by the server.
  • Only Administrators [ADM] can: change username and passwords; add and remove license keys; activate, deactivate and create users accounts; and assign roles to limit or extend access rights.
  • Can set password policy options, i.e., minimum password length, reuse of old passwords, enforce password change, prompt initial password change.
  • Only Root [ROOT] users can modify server-wide security level.

Recommendations

  • Change the system-default passwords for admin, system, and root user accounts.
  • Do not distribute the swAdmin client to non-admin users.

Requirements

  • Set the desired server-wide security level
  • Only a few trusted users shall be provided with the Administrator role.
  • Restrict the Root role to 1-2 dedicated user accounts.


swArchitect Client 

  • All calls and credentials are verified by the server.
  • Authentication using either password or Windows Active Directory/LDAP.
  • Only SW Architects [SWAR] can: modify the meta model, and create, modify, activate, deactivate, and delete configurations.
  • Read-only for non-architects users.

Recommendations


API

  • All calls and credentials are verified by the server.
  • In addition to SystemWeaver password or LDAP authentication, a third option is available to allow clients which are not connected to a domain, to authenticate against the server using the Windows domain username/password. In this case, a two-step identification is used to avoid network sniffing.
  • Protection against command line injection. 

Recommendations


Database 

Database Server (for non-SQLite databases)

  • Authentication and data security handled by the database engine.

Recommendations

  • Consult with internal IT department regarding security best practices for database engine.
  • Change database admin password upon employee terminations.

Requirements

  • Only a few trusted users should have access to the database and the machine.
  • Located in a protected area in the same way as the server application machine.


SQlite Database File

Recommendations

  • Check the possibilities of encrypting the database file on the hard drive if needed.
  • Consider physical security of the database machine.

Requirements

  • Only a few trusted users should have access to the database file location.


Database Backup 

Recommendations

  • Strongly recommend back up of database to protect against data destruction.
  • Document your backup management procedures.
  • Backup routines should never be trusted without proper verification.
  • Regularly assure that the backups can be restored, and that they represent the intended database copy.
  • Consider physical security of the backup database machine.

Requirements

  • Only a few trusted users should have access to the database file location.


 Server Logs

Requirements

  • If you have a detailed log, it could contain product data and should be protected.





* The availability of the encryption option is restricted due to EU regulations. Please contact us for more information.