= 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]]