Skip to main content

Security Policy

Overview 

Simtech Solutions Inc is a cause-driven technology services provider with a passion for developing innovative technologies to help people experiencing homelessness.  Founded in 1998, Simtech Solutions has a depth and breadth of experience working with Homeless Management Information System (HMIS) data and is well-versed in all the concerns around securing and protecting the personally identifiable information (PII) of the clients we are intending to help serve. Security is a primary focus for Simtech Solutions when designing and building software and systems that aid communities in their work of ending homelessness.  By utilizing practices such as role-based security, principle of least privilege, and encryption both at rest and in transit, we can be confident data stored in our system remains secure. 

 

Role-Based Security 

While other systems may require separate hosting environments be set up for each data source, the framework of our products, including Counting Us, Show The Way, the Regional Command Center, and the HomelessData warehouse, enables data access to be limited based on the designated role of each user. Roles can be assigned different levels of permissions to grant them access to different levels of functionality in the system. Roles are then assigned at various levels to allow for fine-grained control of who can access what data in the system. User roles and permissions are defined in the professional services agreement. 

Principle of Least Privilege
By default, users of all Simtech products are set up with a minimal role that grants them zero access to data in the system. This requires the user be explicitly granted permission to access data as needed. For the HomelessData warehouse, the one exception to this rule is a user, provided they been given the “Upload Data” permission, can always view and run reports over data they have uploaded.  

Table, Row, and Column Security
All access to the underlying database is done through our backend API (Application Programming Interface). As no direct database access is allowed, this allows our application to control which tables, rows and columns can be accessed for any given request.  

  • Table Security – Our system performs a permissions check on every call to the API, which first ensures the user making the request has been authenticated, and then determines whether they are authorized to access the resource they are requesting.  
  • Row Security – Any requests for data are done within the context of user, ensuring the API will limit the response to only those records the user requesting the data has access to.  
  • Column Security – Each request only returns the columns relevant to the task at hand. For example, our report drilldowns do not show the Social Security Number of the clients that make up a report value. Instead, they show any fields relevant to that particular value, in addition to the client’s system ID. 

 

Encryption in transit and at rest 

While we have tight controls on who can access which data in our system, we feel it is important to use encryption as an additional safeguard to protect client information. We encrypt our data both in transit and at rest, at both the application and hardware level. 

 

  • Encryption in transit – All requests to our backend API are only allowed via Secure Socket Layer (SSL) encryption. This prevents any malicious actors to view the data while it is in transit between the server and client. Additionally, we rotate our SSL certificates every 90 days to ensure maximum security.  
  • Encryption at rest, application level – When a zip file containing CSV data is uploaded to our system, it is immediately encrypted using AES encryption before being saved on the server. It sits in this encrypted format, and is only decrypted in memory when being validated, processed, and inserted into the database.  
  • Encryption at rest, hardware level – All data is hosted on Amazon Web Services (AWS) cloud infrastructure. We use the Relational Database Service for hosting the database, and additional storage services (i.e., CSV uploads, temporary files, etc.) will be provided by one or more of the following: Simple Storage Service (S3), Elastic Block Store (EBS), and Elastic File Store (EFS). A description of each is provided below; please see the AWS website for the latest information: https://aws.amazon.com/.  
  • Relational Database Service (RDS) – Amazon RDS provides the ability to encrypt the databases using keys managed through AWS Key Management Service (KMS). On a database instance running with Amazon RDS encryption, data stored at rest in the underlying storage is encrypted, as are its automated backups, read replicas, and snapshots. 
  • Simple Storage Service (S3) – Amazon S3 supports both server-side encryption (with three key management options) and client-side encryption for data uploads. 
  • Elastic Block Store (EBS) – Amazon EBS encryption offers seamless encryption of EBS data volumes, boot volumes and snapshots, eliminating the need to build and manage a secure key management infrastructure. EBS encryption enables data at rest security by encrypting data volumes, boot volumes and snapshots using Amazon-managed keys or keys you create and manage using the AWS Key Management Service (KMS). In addition, the encryption occurs on the servers that host EC2 instances, providing encryption of data as it moves between EC2 instances and EBS data and boot volumes. 
  • Elastic File Store (EFS) – Amazon EFS offers encryption for data at rest and in transit providing a comprehensive encryption solution to secure both stored data and data in flight. Data at rest is transparently encrypted using encryption keys managed by the AWS Key Management Service (KMS), eliminating the need to build and maintain a key management infrastructure. 

 

Audit Trails/Reporting 

Security practices help ensure the confidentiality and integrity of the data is maintained, and audit logs help ensure the security practices are working as expected, as well as discover mis-use or abuse of the system.  

 

  • Session Auditing – All logins to the system are tracked, including a unique session identifier (“token”) as well as the user’s identifier within the system, and the source IP address. This logging includes both the start time as well as the end time. 
  • Password Reset Auditing – All password reset requests are logged, again logging the IP address, and for which user the reset request is for. The date and time requested is stored, and, if completed, the date and time the reset was completed.  
  • Report Auditing – All reports are linked to the user who generated them. This information is timestamped, and it is maintained even if the report itself is removed from the system. 

 

Authentication and Authorization
With the exception of public facing portals (which generally either allow for data submission only (i.e., Show The Way’s public role for requesting help), or contain de-identified aggregate data (i.e., HomelessData’s published dashboards), all access to the system will require a user account. These accounts will be granted and maintained by Administrators. User Accounts utilize an email address and a password, which is selected by the user. All passwords are run through a one-way hash algorithm before being stored in the database. Password resets are handled using the industry standard practice of sending a special one-time use link to the email address associated with the user, allowing them to create a new password.  

 

Last Updated July 8, 2021 

Close Menu