The National Cyber Security Centre of the UK Government recently published a white paper on the six design anti-patterns that should be avoided when designing computer systems.
The first anti-pattern is ‘browsing-up’ for administration. This refers to administrating a system from a computer/terminal that is less trusted than the system itself. Essentially, the administrator computer is the weakest link and can be an easier target in attacks. A better approach to this is ‘browsing-down’, keeping administration computers clean by using safeguards such as not browsing the web or opening email attachments.
A second pattern that should be avoided is short-cutting layered defences in a network, via management access. This can be identified when, for example, a user request has to traverse through a Web Application Firewall (WAF), an application server and some logic in order to access the database, whereas management access grants the administrator direct access to the database, bypassing all the intermediate layers. The recommended solution to this is to use a similar layered defences in management interface as is used for user access.
Another pattern to be avoided is having multiple firewalls back-to-back for the same set of controls. The reasoning behind using multiple firewalls for the same controls (often from different vendors) is that an exploit in one of them would stop the attacker in the second one. The counter argument by NCSC is that an exploit in a firewall would rarely be a result of data payload, but most probably would be because of a vulnerability in the administration interface, which should not be connected to public Internet anyway. Also, effective patching should mean that only 0-day exploits would be able to be used by the attacker. Finally, proper defence-in-depth design of the network should minimise the effects of such a breach anyway. The recommendation by NCSC is to implement a firewall once, and do it well. Adminstrators should actively maintain the firewall and its configuration.
Lifting and shifting an ‘on-premises’ solution to the cloud is another pattern to be avoided. This usually means that the on-premises infrastructure components are replicated into the cloud, without proper architecture design or consideration of whether they are still the best components to use. For example, spinning up an AWS EC2 instance, only to install an open source SQL database and use it as a database server, will have to be weighed against using the native AWS RDS solution. In general, using higher order services can both free up resources from patching and updating these systems, which will typically result in a more secure system.
Having third party access that is not controlled and/or monitored is another pattern to avoid. This typically results from outsourcing support to a third party organisation. This third party may have direct access to a system, an access that bypasses many security layers. Avoiding this anti-pattern relies on following the principles mentioned above, allowing access based on the least privilege principle, and ensuring that there is an audit trail for every action in the system. Organisations should also choose third parties carefully, and perform appropriate due diligence.
The last pattern to avoid is the "un-patchable system". Systems that have to be operational 24/7 and can only be patched with downtime measured in hours (or even days) are very difficult to patch. Usually these are systems that have no redundancy in their subsystems, but systems should always be designed for easy maintainance, and patching should ideally be instant, continuous and incur zero downtime.
The whitepaper itself goes to great lengths for each anti-patterns, and also suggests further reading.