Changes between Initial Version and Version 1 of UoL LAMP Server Risk Assessment

Timestamp:

08/26/16 13:22:12 (9 years ago)

Author:

Richard Bramley

Comment:

--

UoL LAMP Server Risk Assessment

@@ +1 @@
+= UoL Lamp Server Risk Assessment
+
+Tags: [[UoL LAMP Server]] [[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 Internet and so open to attack
+
+=== 1.3 Mitigation
+
+- 1.3.1 Access via ssh is only allowed from within the University of Leicester
+- 1.3.2 Servers are behind a proxy server, which attackers would have to compromise before accessing the server itself.
+- 1.3.3 Only ports 80 and 443 communication is allowed through the proxy server
+- 1.3.4 VMs are backed up daily to allow a restore if a corruption occurs
+- 1.3.5 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 internet and so open to attack
+
+=== 2.3 Mitigation
+
+- 2.3.1 Database users are only allowed to connect from the local host.
+- 2.3.2 Database port are only available from the local host.
+- 2.3.3 VMs are backed up daily to allow a restore if a corruption occurs
+- 2.3.4 Databases are backed up daily with a history of 3 months to allow for recovery
+- 2.3.5 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 Use LDAP to connect to servers to disallow sharing of passwords
+- 3.3.2 Remove user accounts as soon as employees leave.
+- 3.3.3 Backups of VMs are kept securely off site.
+- 3.3.4 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.1.3 Applications are visible on the internet so attacks will occur
+
+=== 4.3 Mitigation
+
+- 4.3.1 Use Apache config to restrict access to University of Leicester Network were appropriate
+- 4.3.2 Enforce a strong password policy
+- 4.3.3 Use LDAP authentication where possible
+
+=== 4.4 Improvements
+
+- 4.4.1 Investigate what measures are installed on the proxy to mitigate against attack [[#578]]
+
+== 5 Communication Interception
+
+=== 5.1 Impact
+
+- 5.1.1 Application data could become exposed
+
+=== 5.2 Likelihood
+
+- 5.2.1 Applications are visible on the internet so attacks will occur
+
+=== 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 and internet available sights are always at risk.
+
+=== 6.3 Mitigation
+
+- 6.3.1 Software is kept up to date
+- 6.3.2 Exploits often involve opening SSH ports, that are restricted through the proxy
+- 6.3.3 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
+
+[[BackLinks]]