| 2.3.10. Risk Control: | | From a professional point of view, business continuity can only be delivered from many secure remote data centers and never from a single in-house server. | | We cannot prevent hardware failures, but we can ensure that in most cases a hardware failure will have no impact on the business and the worst case senario is that a user would need to switch to use an associated domain name. | | For example; where an Internet service is provided using a domain such as www.c2man.co.uk we have to accept that the public Internet may have a transient failure that causes that domain name to become unusable. | | Each user is trained to automatically switch to a backup domain such as www.c2man.com that is operating from a totally diffrent data center in a different part of the country. | | In the very unlikely event that both the primary and backup domain name cannot be used, each user is trained to automatically switch to an alternative domain such as www.c2man.net that is operating from a totally diffrent data center in a different part of the country. | | With some critical applications, this set of domain names may extend to more than six different data centers to ensure that the business will always continue. |
| Denial of Service (DoS) Risk Control: | | We implement two lines of defence: (1) we operate business-to-business applications that discard network traffic from unknown sources and (2) we operate from more than one data center so if one data center is attacked, we can quickly continue operations from a different data center. | | Our application services are elastic - they expand in capacity as needed to cope with transient surges in traffic. It is very hard for a traditional in-house web service to be elastic and cope with traffic spikes - DODS attacks are specifically targeted to in-house servers that can be overloaded. | | Our application services operate from at least 3 data centers, so while a hacker may attack one data center, the others continue without any impact. It is not practical for a traditional in-house web service to switch to another data center and so many thousands of hacked computers continually requesting data from that in-house server, it will not be able to continue. See Wikipedia DoS |
| Administrator Risk Control: | | Even an administrator with rights to access each data center could not make a fraudulent update that could not be tracked. | | Multiple tables record each database change, together with "what did I do" and history logs in each data center. If an administrator found a way to bypass some audit trails in one data center, they could not intercept the message queues and multiple updates of each change to other data centers. | | Nobody has physical access to any server, no backup tapes are in circulation that could be hacked and then used to restore fraudulent data. Risk analysis suggests that the control mechanisms in-place have no known ways of being broken. |
| Public Internet Risk Control: | | Every message flowing over the public Internet will be intercepted and will be recorded by ISP and law enforcement authorities. | | Careful design of data requests ensure that each message has low commercial value and very expensive to build up a portfolio of related information. In general, each field is updated or entered one at a time - one data field value has very little commercial value to a hacker. | | Some important data is recorded one character at a time, so any intecept would only view one character of information in complete isolation of context. In many places, additional data is communicated to obfuscate any hacker. | | Risk analysis suggests that the public Internet is fit for purpose and a switch to HTTPS can encrypt data that has a higher commercial value. |
|
|