wiki:UhlLinuxServer Risk Assessment

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'

Last modified 6 years ago Last modified on 08/26/16 14:15:38
Note: See TracWiki for help on using the wiki.