Cryptographic controls

Cryptographic Controls

Cryptographic controls are implemented for the protection of collected, stored, processed, and/or transmitted sensitive information when security requirements specify and/or mandate the use of such controls or when the use of such controls is a balanced approach to mitigating risks.

The primary datastore for Foundry is AWS DynamoDB. DynamoDB offers fully managed encryption at rest. DynamoDB encryption at rest provides enhanced security by encrypting all your data at rest using encryption keys stored in AWS Key Management Service (AWS KMS). This functionality helps reduce the operational burden and complexity involved in protecting sensitive data. With encryption at rest, you can build security-nosensitive applications that meet strict encryption compliance and regulatory requirements.

DynamoDB encryption at rest provides an additional layer of data protection by securing your data in the encrypted table, including its primary key, local and global secondary indexes, streams, global tables, backups, and DynamoDB Accelerator (DAX) clusters whenever the data is stored in durable media. Organizational policies, industry or government regulations, and compliance requirements often require the use of encryption at rest to increase the data security of your applications.

Because each clients encryption needs are different Thinglogix evaluates each clients needs as follows:

• Production databases and applications storing sensitive data are encrypted according to the requirements of the Foundry customer.
• Pre-production databases and applications storing sensitive data have encrypted or have sensitive data obfuscated, masked, or redacted according to ThingLogix's customer requirements
• Information and/or information system owners responsible for applications and/or systems that collect, store, process, and/or transmit sensitive information shall document the following during the deployment of the system:
  • Overall strategy for adequately securing the sensitive information.
  • Explanation for the establishment or absence of specific cryptographic controls.
  • Technical details regarding the implementation and ongoing maintenance including key management.
• Access to keys are restricted to root user of the AWS account
• All cryptography solutions, or justified reasons for their absence, will be reviewed and approved by the customer and ThingLogix prior to Foundry installation (desired) or prior to move to Production.
• File transfers containing information deemed sensitive by the Thinglogix customer must be encrypted using an encrypted protocol approved by Information Security.
• SSL or IPSEC with strong keys shall be utilized when transmitting sensitive information across open networks.

Application Development

Data In-Transit Security & Connected Devices/Assets or Network Communication Security

All interactions with Foundry for data transportation to/from Foundry over public networks must utilize standard open encryption method HTTPS communications. All interactions with external devices/assets must utilize standard MQTT over TLS encryption with X.509 certificates as an option for device authentication. Alternative methods of communication with customer devices/assets must be approved by the customer and must include some level of encryption of all data in transit.

Data At-Rest Security

Foundry default is to not utilize encryption at the database level unless required by the Customer to store specific sensitive or private information. The only exceptions to this include the following:

• Foundry User Passwords are stored in RDS using the MD5 hash

If a Customer requires encryption of private or sensitive data in storage, the following are the approved encryption alternatives the customer can choose from:

• RDS (note that RDS must be setup as encrypted upon creation, and cannot be re-configured after creation) can utilize encryption services that are specified at: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html
• DynamoDB supports encryption as previously stated above
• If anything is stored in S3 buckets, there are multiple encryption options that exist which can be found at: https://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html

Foundry API Security

All Foundry API's developed should utilize the AWS API Gateway service and utilize the AWS Cognito and IAM services for user/role access control. Foundry API's should only be accessible via SSL encryption enabled connections (e.g. HTTPS). The AWS API Gateway must be configured utilizing an access key and secret access key for programmatic calls to the Foundry AWS API services, or for CLI or SDK access.

Application Audit Logging

For any code that generates application logs, no username/passwords combinations should be included in any logs.

API Logging via AWS CloudTrail

For customers that want to record Foundry API calls they may turn on AWS CloudTrail in the AWS account where Foundry is installed. The customer should store these log files in AWS S3 bucket that is encrypted using an approved AWS S3 encryption method (see https://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html ). Additionally, customers should restrict access to these log files by establishing appropriate IAM roles which are granted to only authorized users who should view the logs.

Personally Identifiable Information (PII) Encryption

Foundry itself is a platform, so customers have to choose to collect PII information. If they choose to do so, we recommend encrypting that data in storage using the methods indicated as approved for AWS services elsewhere in this wiki.

If customers are concerned about the potential for storing PII information, then the Customer should enable and turn on the AWS Macie service to scan any logs from Foundry stored in S3 buckets, such as API logs, which should be encrypted as specified elsewhere in this wiki. More information can be found at: https://docs.aws.amazon.com/macie/latest/userguide/macie-setting-up.html

Foundry User Passwords

Foundry User Accounts, which are setup and managed by our Customers in their AWS Foundry account, should have passwords stored in RDS using MD5 hash.

Key Generation

Keys must be created using cryptographically strong algorithms per Amazon Web Services.

Key Distribution

Keys must be encrypted when transmitted over communication lines. The exchange of keys must employ encryption using an algorithm that is at least as strong as the one that is used to encrypt the data protected by the keys, and access must be strictly limited to those who have a need-to-know.

Key Storage and Protection

Keys and their associated software products must be securely maintained for the life of the archived data that was encrypted with that product. Keys must conform to the maximum standards available in AWS. Keys should be stored in AWS Key Management Service.

Key Recovery

AWS Key Management service is recommended for this purpose because it is reliable and secure. The Key Recovery process is as follows:

• The request for key recovery is initiated in FreshDesk
• CTO approves or denies the recovery request
• CTO executes the recovery via AWS Key Management Service

More information on Cryptographic Controls can be found at:

• https://csrc.nist.gov/CSRC/media/Publications/sp/800-57-part-2/rev-1/draft/documents/sp800-57pt2-r1-draft2.pdf