Security

Security

This section of the document is primarily focused on the development of a secure model allowing for the intelligent access of resources developed and managed by the SlashRoot’s Foundation and/or its subsidiaries. This ensures that data will be:

• Protected from an outside adversary

• Dangerous actions are limited to those internal to the project

• Safely disseminated by approved vendors/users

• Accessible in an auditable fashion

• Protected by an disasters either natural or unnatural

• Remain with a high level of integrity and accuracy

End-User Secure Access

It is recommended that users or applications utilizing the web-services be authenticated using standards such as OAuth spec 1.0 or 2.0 (Brail 2010). This allows a more controlled method of giving and revoking access to rogue users or applications. In order to facilitate OAuth registration it is necessary to provide a separate authentication for users – thus providing a separation of users to the resources and applications utilizing the services.

Detailed logs of user usage must be maintained throughout the project lifetime, ensuring that, information about what the user(s) have done can be presented to the relevant authorities in accordance with the laws of the jurisdiction(s) in which SlashRoots operates. These logs can also be used to identify user(s) with malicious intentions and revoke any accesses granted by SlashRoots.

Developer Engineer Guidelines

Below are some guidelines that all engineers must follow:

• Configuration files must NOT be published to any open repositories as outsiders with sufficient knowledge can compromise infrastructure and services supported by SlashRoots.

• Any action to remove data in an existing dataset must have the approval of a senior engineer

• Storage of access codes must be done utilizing industry standards ensuring information privacy

• At no point must a password be stored or transmitted in the clear

• Utilization of data sanitation libraries must be done in order to prevent database breaches

• The credentials used for database authentication must not reside in the main, executing body of the program's source code in clear text

• Database credentials must not be stored in a location that can be accessed through a web server

All passwords should meet or exceed the following guidelines:

• Contain at least 12 alphanumeric characters.

• Contain both upper and lower case letters.

• Contain at least one number (for example, 0-9).

• Contain at least one special character (for example ,!$%^&*()_+|~-=\`{}[]:";'<>?,/).

Key Management

If an in-house repository is being used, each developer must access this resource through a secure socket layer utilizing his/her pre-shared public key. No other authentication is acceptable for repository-level action. A public key housed on the SlashRoots infrastructure can be removed if the machine is no longer a contributing member of the foundation and/or subsidiaries.

Under no circumstances is a private key to be shared with any external or internal entity. This can compromise the information moved between the owner of the key and any communicating entity – leading to a breakdown of security.

Passphrases

Passphrases generally are used for public/private key authentication. A public/private key system defines a mathematical relationship between the public key that is known by all, and the private key, that is known only to the user. Without the passphrase to unlock the private key, the user cannot gain access.

A passphrase is similar to a password in use; however, it is relatively long and constructed of multiple words, which provides greater security against dictionary attacks. Strong passphrases should follow the general password construction guidelines (SANS Institute 2014) to include upper and lowercase letters, numbers, and special characters (for example, TheTrafficOnThe101Was*&!$ThisMorning!).