API Documentation

Info Management & Security Recommendations

Suggest Edits

🚧

These are recommendations, not requirements.

This page lays out our InfoSec recommendations, but keep in mind these are not requirements.

Some things to keep in mind as you begin building your app:

Definitions

PII (personally identifiable information): Any representation of information that permits the identity of an individual to whom the information applies to be reasonably inferred by either direct or indirect means

❗️

Encryption

Private keys and some personally identifiable information (PII) should be encrypted.

Encryption

  1. Implementing encryption/decryption routines in your application to target specific types of data is preferable.
  2. Stored Data:
    • Acceptable encryption, generic hashing, and password hashing algorithms include: AES (key length of 256 bits or greater), SHA3, RSA (key length of 4096 bits or greater), ECC (key length of 384 bits or greater), bcrypt, scrypt, SHA-2, PBKDF2, Argon2id.
    • PROHIBITED: Older algorithms including MD5, MD4, and SHA-1
  3. Transporting Data:
    • Acceptable standards include TLS 1.2 and TLS 1.3.
    • PROHIBITED: Older standards including TLS 1.0, TLS 1.1, any version of SSL or unencrypted HTTP.
    • A useful tool for evaluating the security of your HTTPS implementation can be found [here] (https://www.ssllabs.com/ssltest/ ).

What data needs to be encrypted.

Social security numbers, app and user private keys, passwords*, bank account numbers as well as all customer documents should NEVER be stored in plain text in your database. Sila requires all customers to apply rigorous encryption methods upon these items if they are stored in your database.

Names, date of births, addresses, phone numbers, and email address don’t need to be encrypted at the column level, but they do need to be treated securely and protected by limiting access to the database. Your database NEEDS to be protected, and access to data within your database should be granted on a need only basis. Refer to database access requirements below.

🚧

What data should I encrypt

Social security numbers, app and user private keys, bank account numbers, as well as all customer documents must be encrypted if they are stored in your database.

*Passwords are required to have one-way encryption.

Hosting Data

  • If your server is locally hosted a SOC-2 Type II audit certification is required for production access.
  • Otherwise, the application needs to be hosted by a provider that can provide a SOC-2 Type II report upon request. Such as; AWS, Google Cloud, and Azure among others.

Key Management Store (KMS)

Sila requires the use of a Key Management Store for private keys.

  • User private keys must never be generated client side (meaning the end user should not have access to their private key) without explicit approval from Sila.
  • User private keys must not be communicated over any network unencrypted (meaning encryption of the private key needs to happen immediately after key generation).
  • You must be able to demonstrate how user private keys are stored and retrieved with the use of a KMS.
  • Approved KMS providers include AWS-KMS, Hashicorp Vault, Google Cloud Key, Azure Key Store, and Very Good Security.

Logging Data:

It is important that you keep sensitive data out of your logs.

  • You need to identify if your logs have sensitive information in them and then take action to protect that information. Keep in mind that error messages may include some private data.
  • You will be expected to either secure your logs or implement a solution to prevent secure data from getting into your logs.
  • Keep this in mind as you will be asked what actions you take to prevent sensitive data from being captured in your logs.

Database Access:

You are expected to adhere to the principles of least privilege as limiting access to your database helps keep the risk of exposing sensitive data low.

  • You will be asked to specify what individuals and companies/firms have access to your data and the level of access (read or write).

Secure Data Disposal:

Securely disposing data also helps keep the risk of exposing sensitive data low.

  • You should only keep data as long as you require it. Therefore, it is important to think through how long you really need to keep a users data. Once the data is no longer needed you need to have a plan to delete it.
  • At some point you may have a user who wants you to remove their data and you should have a plan in place that ensures you are able to securely dispose of their data.
  • Sila does not require you to have this plan implemented but we will ask you to tell us about your secure data disposal plan.

Security Integration:

Important questions to consider:

  1. How do you identify threats and vulnerabilities?
  2. What risks have you identified, and what is your plan for mitigating each of them?
  3. What process (if any) do you have in place to identify, resolve and record security incidents?
  4. Have you evaluated your application against the OWASP Top 10 Web Application Security Risks and made adjustments where necessary to mitigate unaddressed risks?
  5. Do you have a plan and schedule for correcting any unaddressed web application vulnerabilities? When do you plan to complete that work?

Need a better sense of how the Sila API functions?
Watch the Sila App Demo to experience the Sila API in action.

Ready to start building?
Check out Entities to see how to start the Sila API flow.

Updated about 21 hours ago