What Makes a Good Security Architecture?

Transcription

1 What Makes a Good Security Architecture? What makes a good security architecture? How many times have you heard some organisations state, our policy is that anti-virus software is installed on all servers. But why? What is the AV software actually doing? It is a good policy if the server is a mail server, or a file and print server, where the AV software has actually got a job to do. But why do you need AV software on a database server? Ah well, to protect the server in case malicious software is loaded onto it. Well AV software is not going to provide any protection against normal SQL traffic to the database server. And if the so called protection is to protect against system administrators loading malicious software onto the server, first system administrators should be checking any files before they load it onto the server. And second, any malicious system administrator will just turn off the AV software and then load the Trojan or whatever. The end result is costs are increased, server performance is decreased, and no decrease in risk. An expensive policy, providing a false sense of security! There are a number of principles that should be deployed in any security architecture, which include in no particular order, and are expanded below: 1. Use layered defences 2. Keep it simple stupid 3. Build-in maintainability 4. Segregation 5. Minimise the number of users 6. Default no trust 7. Expect the unexpected 8. Use assured products 9. Don t gold plate the solution 10. Enable the business 11. Deploy deterrents 12. Use barriers 13. Detect intrusions 14. React against intrusions 1. Use Layered Defences Relying on a single defence is a risky strategy. If this defence should fail for whatever reason, then the system is vulnerable to attack. The design of castles used for millennium relied on multiple layers of defences. Deploying multiple security controls means that if one control fails, the other security controls will protect the system. Thus a system that is protected by security controls A, B, C, D, E and F has six levels of protection, either one of them can potentially protect the system. This type of protection is often described as the onion security model. Page 1 of 5

2 2. Keep it Simple Stupid How can complexity improve security? Any system that relies on security controls of A and B and C and D and E and F has six ways to go wrong, against a system that only replies on one security control, which has only one way to go wrong. It is lot easier to look after a single system than multiple systems. There is a world of difference between a system relying on security controls A and B and C, and a system relying on security controls of D or E or F. The latter is called layered defences (see above), whereas the former is called coupling of security controls. Hence deploy the KISS principle, and keep any solution simple as far as possible. 3. Build-in Maintainability Maintainability should be built in at the design stage for any system. This means that the system is designed to be able to rapidly deploy patches, and version upgrades are planned as part of the overall lifecycle. Where this has been forgotten, this can create huge risks for the business. In one particular case, the business were running a system on hardware which should be consigned to a museum, written in a computer language where there are only a few people left with relevant skills, and they are rapidly approaching retirement. So what happens when there are no more spares left in the world? The business are playing Russian roulette every day, and unless they come up with a replacement system, it won t be a matter of if, but a question of when the catastrophe will happen. Malware is now been released within days of a patch been released. Failure to rapidly deploy the security patches puts at risk your system from being attacked. The PCI DSS requires that all security patches are deployed within one month of release. This really should be viewed as the minimum standard, with the aim to push out security patches a lot faster. The only way that this can be achieved is to design a system that meets this objective. By using automated test scripts, the patch can be tested before being deployed into the live environment. Version upgrades, hardware refreshes should not come as a surprise. Hardware components fail with age. Software is only supported by vendors for a limited period. Which means that after that period, security patches are no longer released and the system is vulnerable to attack. Designing the system so that it has a fixed life of say five years before being upgraded, will ensure that the risks to the system are being managed and not increasing with old age. 4. Segregation Diversifying and not putting all your eggs in one basket is an excellent way to reduce risk as Nobel Laureate Harry Markowitz proved in 1952, when he developed portfolio theory. Just as diversification reduces risk in portfolio theory, so dividing up a network can reduce risk. If one segment of the network comes under attack, then only that segment is affected, and the other segments continue to operate normally. A lot of business can continue to operate normally, despite their being a disaster in one sector. Do you really want Internet users to gain access to your internal network? How to divide up the network will depend greatly on the size of the business, and how the business is organised. Even small organisations should separate their external business systems from their internal systems. However, sub-dividing the network into too many small chunks will just add cost and complexity without increasing security. Page 2 of 5

3 The best advice for any organisation having to comply with PCI DSS is to segregate those systems that are covered by PCI DSS and those that are not. All the information systems of an organisation have different security requirements. Segregation ensures that different levels of security can be deployed, instead of trying to raise all systems up to the highest common denominator in terms of security. 5. Minimise the Number of Users Reducing the number of people who can access the system reduces risk. This includes both authorised users and unauthorised users who just have access to the network. Assume that one person in a hundred is malicious, and one in ten of those malicious users has the capability to exploit the system. Then this means that if 1,000 people can access the system, at least one person will potentially successfully attack the system. Obviously actual statistics will vary between organisations, but the principle is the same, the more people who have access to the system, the greater the risk. A system that can only be accessed by 10 people is thousand times less likely to be attacked, than a system that can be accessed by 10,000 people. 6. Default No Trust Every fraudsters dream is that you will trust them; every burglar hopes that you think everyone is trustworthy and have left windows open and not fitted a burglar alarm. The film Catch Me If You Can proved how Frank Abagnale had managed to abuse trust for many years before finally being caught. If you trust a person or another system not to attack your system, then you are relying on their security. In other words, risk has been transferred from that system or organisation to you. Do you really want to take on the risk of another organisation that is outside of your control? In a standard three layered architecture of web server, application server, database server, security is greatly enhanced by each layer implementing its own security, and not trusting the security of the other layers. For example, validating all input. This means that if a vulnerability in one layer, all the other layers are not automatically vulnerable. Often a completely paranoid approach is not practical, and different degrees of trust have to be applied. This degree of trust should be based on how much control you can place on that other system. For example as explained in ISO/IEC :2006, a simple three layered trust approach could be deployed of low trust for external systems, medium trust for partners where there is a formal contract in place, and high trust for internal systems and users. 7. Expect the Unexpected As Murphy s Law states, anything that can go wrong will go wrong Information security is about mitigating the effects of hazards occurring. During the Second World War in Moscow, a distinguished professor of statistics in suddenly turned up in a bomb shelter, having never frequented the bomb shelter before. When asked why he was there, he stated that in Moscow there are 7 million people and one elephant. Last night they got the elephant. One can hardly assume that Moscow zoo was the target of Nazi air attacks, even so the improbable did occur. Before Australia was discovered, who would have thought that all swans were not white? See Taleb s book on The Black Swan for other improbable events that occurred. Page 3 of 5

4 Don t assume that just because your system has not being attacked before, it doesn t mean that it won t in the future. That is relying on the Law of Small Numbers, which is also known as the Gamblers Fallacy. Chances are that you don t have enough data to estimate the probability. If a risk can be avoided, then avoid it and don t take the chance that it might not occur, however small the odds. 8. Use Assured Products Don t assume that a product or system will provide the protection it claims. Get independent assurance that the security claims are valid. The easiest way to achieve this is wherever possible to use assured products such as products certified under the Common Criteria scheme, or have FIPS certification for cryptographic products. Where it is not possible to use assured products, then use products that have been independently tested against some specification which specially tests the security controls. Forget about those tests which test how easy is it to install the product, or how fancy the management controls are. They may make life easier for administrators, but they do not improve the security of the product. There are many products out there which claim to be secure but are unassured. For example, WinZip claims to be secure because it uses AES-256. However, there are published papers showing how to exploit weaknesses in the WinZip, negating any supposed protection. 9. Don t Gold Plate the Solution Don t gold plate the solution, every security control has to be justified that it is cost effective in reducing the risk down to an acceptable level. It is often difficult, if not impossible, to properly quantify the effect a particular security control, or group of controls, has in reducing risk. However, despite the difficulties, security controls should only be deployed if they adding value in reducing risk. Thus it is important to understand how the security controls work. The objective is not to try and reduce risk to zero, but down to an acceptable level, dependent on the risk appetite of the organisation and the risk tolerance. This inevitably means that more security controls could be deployed, but their extra cost cannot be justified by the business. 10. Enable the Business Enable the business. Information security is not about preventing the business from doing their job, but ensuring that the business can perform their function securely. Hence information security should be seen as an enabler, and not as an inhibitor. The question to always ask is how can this be done securely? It maybe that the costs or restrictions are too high, but then that becomes a risk management decision. However, there is nearly always a solution to the problem, even if it does require some creative thinking. Shops are not designed to minimise shop lifting, but designed to maximise sales. In so doing, shops have to allow a certain amount of shop lifting. This does not mean that the problem is ignored, but rather there is a balance between minimising stock shrinkage and maximising sales. Certain security controls are put in place to minimise stock shrinkage, which have minimal impact on maximising sales. Page 4 of 5

5 11. Deploy Deterrents Deterrents are an important set of security controls in the toolbox. They do not prevent an attacker, but deter an attacker from carrying out an attack. Deterrents are like warning notices. Examples of deterrents include employee contracts, partner agreements, operating procedures, warning notices (e.g. when you login), obfuscation. The job of deterrents is to state to a potential attacker that the amount of effort required to attack the system is going to not worth the potential reward, or the risk of being caught. Ideally a deterrent should have a consequence if the warning is ignored. For example, an employment contract will state that if you attack the system, you risk losing your job with no compensation, and also risk civil and/or criminal action. If the potential reward is 500m probably not much of a deterrent, but more than adequate if the reward is only 500. Deterrents should be used with other security controls, as they only deter and do not prevent or detect an attack. They are particularly useful when trust is involved, for example with employees, partners, service providers, etc. 12. Use Barriers Barriers prevent attackers from gaining access to a system. There are five types of barriers: encryption in transit; encryption at rest; ID&A (identification and authentication); firewalls; and secure disposal. Barriers have a known strength, which is defined in the amount of effort, or resources, required to compromise the barrier. Wherever possible, barriers should be used as the primary defence against attackers in preference to any other form of security control. 13. Detect Intrusions As Elson's Law states Anything that can go wrong already has, you're just not aware of it yet! How do you know your system has not already been attacked and compromised, if you don t have the ability to detect it? Detection systems are analogous to burglar alarms. The most useful detection controls are: automatic monitoring of log files; and HIDS (Host Intrusion Detection Systems). 14. React Against Intrusions What is the point of having a burglar alarm if no one reacts to the alarm? Detection systems by themselves are of no value if no one is looking at the result. Therefore, all detection systems should be reacting against a potential attack, such as generating an alert which system operators can respond to. There are automatic reaction systems, such as anti-virus software, or NIPS (Network Intrusion Systems). Author Eur Ing Harry E. CLARKE, MSc, CEng, MBCS, CITP, CISSP, M.Inst.ISP Page 5 of 5