Security¶

Password protocols¶

Password strength is defined by the entropy it has. This is to say how long it takes to brute force your password. If you have a relatively long password you would be fine. However, your passwords entropy, goes down significantly if you use common keywords such as ‘password’ or a birthday date. To ensure that your password entropy is high, a standard has formed around passwords so that they comply with these rules:

• It is at least 18 characters in length where possible, or if a service only allows shorter, you should use the maximum amount of characters.

• It should contain at least one capital letter, one number and one special character (e.g. @,&,-,~,!)

• Do not use certain words in a password such as: Password, Secret, ‘123456’, p@ssw0rd etc.

OR if you are using a passphrase instead:

• It should contain at least 4 words and be over 18 characters long.

Using a passphrase (a collection of words), rather than a password with different symbols and numbers is also possible. The length of a passphrase gives it the necessary entropy to be a viable alternative with the added benefit that you will be able to remember 4-6 words easier than you would 18 randomly generated characters.

# an example of a complex password would be
deyp78&*fasbk!~)&(*

# an example of a strong passphrase would be
boat drill charger keys stop
# this could be more specific and meaningful to you, or random like the one above

The last thing about passwords that you need to be considerate of, is password protection. Follow these rules about access to or sharing information about passwords:

• Don’t send your password over the internet to anyone.

• Don’t write passwords down and store them on a physical location.

• Store any user ID’s or passwords in an encrypted format.

• Do not script any passwords for automatic log in.

• Never use a previously used password.

• Change your password once every year.

Another thing to note about passwords:

If you ever need to send the output of some code to a support staff member and that code contains a password or other sensitive information; Be sure that you censor the password before sending it, as done below.

OS_AUTH_URL=https://api.nz-por-1.catalystcloud.io:5000/v3
OS_PROJECT_DOMAIN_ID=default
OS_REGION_NAME=nz-por-1
OS_PROJECT_NAME=XXXXXXXXXXXXX/XXXXXXXXXXXXXXX
OS_USER_DOMAIN_NAME=Default
OS_IDENTITY_API_VERSION=3
OS_INTERFACE=public
OS_USERNAME=XXXXXXXXXXXXX@catalyst.net.nz
OS_PROJECT_ID=fha98835bhnae8092n4388ujf
OS_PASSWORD=XXXXXXXXXXXXX

Multi factor authentication¶

We recommend that you use multi factor authentication (MFA) on all accounts, please see Multi factor authentication for details on how to implement this. You can review which accounts have MFA enabled on the Project Users panel in our dashboard.

Update systems often¶

Keeping your software up to date with the most current version of your applications and operating systems helps to keep you secure. Malicious software that attacks files and core operating infrastructure on your computer is consistently created; therefore your operating system and other applications need to be constantly updated to protect yourself. It is understandable that if you are using a legacy program or software that you may not be able to update it but for those that you can, it is recommended you keep them updated as regularly as possible. These updates usually include upgrades dealing with security a large portion of the time.

Encrypting emails¶

When sending emails that pertain to sensitive information, they should be encrypted using a PGP key or some other form of encryption. This not only means that it’s harder for your emails to be broken into, it also mitigates phishing attacks because your emails can be authenticated.

You should never send any form of private key or identification information over emails that are not encrypted. In some cases you may need to use a physical memory device (flash drive) to transport highly sensitive files.

Access management¶

Access management, is a set of practices and rules that make sure that your organisation knows exactly who has access to the resources that you have previsioned in the cloud and what exactly these users can do with said resources. The Catalyst Cloud achieves a strong level of security in this regard by the use of Roles. These are given to users by the project administrator and they impose restrictions or provide privileges to users. For more information on roles and their uses, please see the identity access management section of the documentation.

Security groups¶

Security groups are what allow you to safely and securely access the instances that you create on the Catalyst Cloud. When creating a security group, it automatically has the following rules:

These mean that the security group can access the internet from IPv4 and v6 with outward bound traffic. But at this stage there is no ingress traffic, you must define that yourself. When doing so you need to be careful and understand the type of access you wish to permit. Below is pictured the different rules you can create to meet your needs.

The standard that we use at Catalyst is an SSH key pair which you can upload or create via the dashboard. We use SSH keys because they provide an increased level of security beyond restricting ports. The full process of how to create or upload your SSH keys is documented here.

Resource and object naming¶

When deciding on the names you are going to give your resources, it is important to note that the resource names you choose will be logged in our internal logs, audit logs and are included on the invoices we send to you. Object names stored in our Object storage system will be logged in our logging and audit logs.

It is recommended that you don’t use any sensitive, or personally identifiable information in either your resource names or object names.