UhlLinuxServer Risk Assessment

Tags: UhlLinuxServer Information_Governance_Category

1 Illicit Access to Server

1.1 Impact

• 1.1.1 Attacker could have access to data stored on the server
• 1,1.2 Attacker could corrupt data stored on the server
• 1.1.3 Attacker could change or corrupt the software running on the machine

1.2 Likelihood

• 1.2.1 The servers are available on the UHL Intranet and so an attack is unlikely

1.3 Mitigation

• 1.3.1 Access via ssh is only allowed from within UHL
• 1.3.2 VMs are backed up daily to allow a restore if a corruption occurs
• 1.3.3 Software is available online or from source repositories (SVN or Git)

1.4 Improvements

• 1.4.1 Access could be restricted to users with an SSH key. #756
• 1.4.2 Disaster Recovery Testing #360

2 Illicit Access to Data

2.1 Impact

• 2.1.1 Attacker could have access to data stored on the server
• 2.1.2 Attacker could corrupt data stored on the server
• 2.1.3 Attacker could use access to the database to access the machine

2.2 Likelihood

• 2.2.1 The servers are available on the UHL Intranet and so an attack is unlikely

2.3 Mitigation

• 2.3.1 VMs are backed up daily to allow a restore if a corruption occurs
• 2.3.2 Databases are backed up daily with a history of 3 months to allow for recovery
• 2.3.3 Database server can only write data to the temp and database directories

2.4 Improvements

• 2.4.1 Access could be restricted to users with an SSH key. #757
• 2.4.2 Disaster Recovery Testing #360

3 Illicit Use or Corruption of Data or Software by Employees

3.1 Impact

• 3.1.1 Data could be released to the public
• 3.1.2 Data could be lost or corrupted (see 7 below)
• 3.1.3 Software could lost or corrupted (see 8 below)

3.2 Likelihood

• 3.2.1 It is unlikely, but these things happen

3.3 Mitigation

• 3.3.1 Remove user accounts as soon as employees leave.
• 3.3.2 Backups of VMs are kept securely off site.
• 3.3.3 Software is kept in source repositories, which track changes and can be restored back to any point.

3.4 Improvements

4 Illicit Access to Software

4.1 Impact

• 4.1.1 Attacker could have access to data stored in the application
• 4.1.2 Attacker could corrupt data stored in the application

4.2 Likelihood

• 4.2.1 The servers are available on the UHL Intranet and so an attack is unlikely

4.3 Mitigation

• 4.3.1 Enforce a strong password policy
• 4.3.2 Use LDAP authentication where possible

4.4 Improvements

5 Communication Interception

5.1 Impact

• 5.1.1 Application data could become exposed

5.2 Likelihood

• 5.2.1 The servers are available on the UHL Intranet and so an attack is unlikely

5.3 Mitigation

• 5.3.1 All communications use SSL

5.4 Improvements

6 Software Security Vulnerability

6.1 Impact

• 6.1.1 Software systems could become insecure
• 6.1.2 Data could be lost or corrupted (see 7 below)
• 6.1.3 Software could lost or corrupted (see 8 below)
• 6.1.4 Data could be exposed

6.2 Likelihood

• 6.2.1 Vulnerabilities in software are constantly coming to light, but sites are only visible within the UHL network.

6.3 Mitigation

• 6.3.1 Software is kept up to date
• 6.3.2 Applications are run as a restricted user account that does not have permission to make configuration changes

6.4 Improvements

7 Data Loss or Corruption

7.1 Impact

• 7.1.1 Jeopardize feasibility of studies where data is lost

7.2 Likelihood

• 7.2.1 A major loss would require a catastrophic failure
• 7.2.2 A smaller loss or corruption of data is much more common

7.3 Mitigation

• 7.3.1 Data is backed up daily and kept for 3 months
• 7.3.2 The VMs are also backed up daily and stored securely off site

7.4 Improvements

8 Software Loss or Corruption

8.1 Impact

• 8.1.1 Interrupt progress of studies until systems can be restored

8.2 Likelihood

• 8.2.1 A major loss is unlikely, but minor problems can easily occur when software is being upgraded

8.3 Mitigation

• 8.3.1 VMs are backed up daily and stored securely off site
• 8.3.2 Software is stored in source code repositories that are backed up and any version can be retrieved
• 8.3.3 Processes to install software are documented within TRAC and automation is employed to simplify the process

8.4 Improvements

• 8.4.1 Move automation should be introduced

Error: Macro BackLinks(None) failed

'Environment' object has no attribute 'get_db_cnx'