ISO 17799 Software Directory: Software for ISO 17799 Compliance, ISO 17799 Audit & ISO17799 Implementation

ISO 17799 And The UK Data Protection Act 1998 Roger Jarvis m.instis mbci Recently I thought that it would be a jolly novel idea to link the dictates of the Data Protection Act (1998) (DPA) with the guidance of ISO17799 the Guideline for Information Security Management, to achieve more effective compliance with the DPA in IT processes. This 'idea' proved to be neither original or useful. It was pointed out to me that there are many 'really bright' people are now linking the DPA and ISO17799. For updates I was invited to use one of the www surf engines and ask for items with both 'DPA' and '7799' in the title. Gosh. However, although those people were all right, and all they said was right (well mostly), being right was, I thought, not really good enough. It was like linking truth and beauty, wonderful but useless. In this article I attempt to go further, and see what might happen if the DPA and ISO17799 were actually worked together. My target, based on my repeated failure to achieve DPA compliance there in the past, is the field of IT application development. The theory being that if things were designed compliant, they would be built compliant and would stay compliant. Another approach to linking data protection and security management would have been to apply the excellent IS 15408 (the "Common Criteria" (CC)) as the CC does specifically address both these areas in several contexts, one of which is application development. However, with the greatest respect to that formidable methodology, and its equally formidable terminology, in my view only developers who were bound to it (public sector) would fail to run away at the first review. Application developers, intent on turning business dreams into coded reality, will otherwise only tolerate the easy to read and the simple to do. Despite, perhaps because of, its many strengths, the CC is neither of those.   The following is the DPA viewed via ISO17799 at the Guideline's second level of detail. It was found that that the first level, for instance, 'Section 9 Access Control', was too high to be useful, whereas the third level, for instance, 'Section 9.2.1 User registration', became too detailed. It was a case of finding the right balance between looking at the wood and the trees. All that was needed at this stage was a feel for how well ISO17799 might work as a DPA translator. For each ISO17799 sub-section, each DPA principle was examined to see how effective it might be in guiding a software developer to create a product that was naturally DPA compliant, as well as being secure. This was achieved via a one time pass at speed each way through the translation using nothing more scientific that the author's gut feel. If anyone has done better, or is willing to do so, please let me know. As will be seen, a simple scoring system was used based on the perceived relevance of DPA principles, where "H" means high and "0" means none. There was also the option of recording a negative reaction, suggesting that the DPA was demonstrably counterproductive. Scores and meanings Score value meant H +3 fully related to the DPA principle M +2 mostly related to the DPA principle L +1 partly related to the DPA principle 0 0 did not match the DPA principle - -1 seemed to conflict with the DPA principle The scores were then totalled by DPA Principle (S1) and by ISO17799 sub-category (S2) to show general reactions and trends. S1 : Product quality by DPA Principle Value Range Development Project reaction Vital 20 to 24 Product compliance was a the key concern Important 16 to 19 Product compliance would be naturally included in the design useful 12 to15 Product would be altered if it showed non-compliance some use 08 to 11 Product would be secure (some accidental DPA compliance) harmless 00 to 07 Product may not compliant, but may well be exempt negative -8 to -1 investigate why ISO17799 and DPA clash for this product S2 : Product quality by ISO17799 sub-category Value Range Development Project reaction Vital 90 to 108 Principle was essential to the development process Important 65 to 89 Principle compliance naturally included in the design useful 40 to 64 Principle borne in mind during development some use 15 to 39 Principle not a major concern harmless 00 to 15 Principle not relevant negative -36 to -1 investigate why DPA and ISO17799 clash for this product The results are shown in the following table. ISO17799 - DPA Principle Table 7799 Guideline subject P1 P2 P3 P4 P5 P6 P7 P8 S1                       3.1 Security policy H H L M H H H H 21 4.1 Information Security Infrastructure H L L L L H H L 14 4.2 Security of third party access 0 0 L 0 0 0 H 0 04 4.3 Outsourcing 0 0 M 0 0 M H 0 07 5.1 Accountability for assets 0 0 0 0 0 0 H 0 03 5.2 Information classifications 0 0 H 0 0 0 H 0 06 6.1 Security in job definition and resourcing H 0 0 0 0 M H 0 08 6.2 User training M M M M M H H 0 21 6.3 Responding to incidents & malfunctions 0 0 0 0 0 M L 0 03 7.1 Secure areas 0 M 0 0 0 0 H 0 05 7.2 Equipment security 0 M 0 0 0 M H H 10 7.3 General controls 0 0 M 0 0 M H 0 07 8.1 Operational procedures & responsibilities 0 M M 0 0 L H 0 08 8.2 System planning and acceptance 0 0 0 0 0 0 H 0 03 8.3 Protection against malicious software L M 0 0 0 M H M 10 8.4 Housekeeping 0 0 0 0 0 0 H L 04 8.5 Network management 0 M 0 0 0 L H M 08 8.6 Media handling and security 0 0 0 0 0 0 H M 05 8.7 Exchanges of information and software 0 M 0 0 0 0 H 0 05 9.1 Business requirement for access control 0 M 0 0 0 H H M 10 9.2 User access management 0 M 0 0 0 M H 0 07 9.3 User responsibilities 0 H 0 0 0 H H 0 09 9.4 Network access control 0 M 0 0 0 M H H 10 9.5 Operating system access control 0 0 0 0 0 0 H 0 03 9.6 Application access control 0 M 0 0 0 M H M 09 9.7 Monitoring system access and use 0 M 0 0 0 M H M 09 9.8 Mobile computing and networking 0 M 0 0 0 M H M 09 10.1 Security requirements of systems M M M M M M H 0 15 10.2 Security in application systems H H H H H H H M 23 10.3 Cryptographic controls 0 L 0 0 0 H H H 10 10.4 Security of system files 0 L 0 0 0 M H L 07 10.5 Security in development & support process H H H H H H H L 22 11.1 Aspects of business continuity management 0 0 0 0 0 L H 0 04 12.1 Compliance with legal requirements H H H H H H H H 24 12.2 Review of Policy and technical compliance M M M M M M H M 17 12.3 System audit considerations M M M M M M M M 16 S2   27 50 29 19 21 61 105 39     Some observations There were no negative responses. ISO17799 had most in harmony with DPA Principles 7 and 6 ISO17799 had least in harmony with Principles 4 and 5 The DPA had most in harmony with the ISO17799's development process, security policy and user training. The DPA had least in harmony with ISO17799's system planning, asset accountability and response to incidents/malfunctions. Some comments on the observations There seemed to be no actual contradiction between ISO17799 and the DPA. Therefore, in as far as there is difficulty applying the DPA to development projects, its cause must be more culture than content driven. To put it another way, the search should be for errors of omission, not commission (no pun intended). It was expected that there would be harmony between ISO17799 and Principle 7 as they cover the same ground. However the closeness with Principle 6 was less expected. It may be that where the rights of the individual are not likely to be an issue the developer saw Principle 6 as a 'good thing'. Where rights are more likely to be contentious, and perhaps have a significant influence on application design, then the developer's attitude may have proved more hostile. This would mean, for instance, that applications developed in the public sector, for say something to do with law enforcement, tax liability or medical history, might be more likely to show tension between the DPA and ISO17799. This does not mean that the DPA is OK as long as it keeps out of the way, in the developer's eyes, but it does mean that where the DPA imposes restrictions, there must be guidance for the developer on how to comply and still proceed. The apparent lack of concern over data quality (Principle 4) and data life (Principle 5) showed a developer's view that data content, as distinct from data structure, was the concern of the system user. However, both developer and user can influence the rules under which the data is managed. If the development specification becomes DPA sensitive, the entry edits and review schedule can be made to support Principle 4 and expiry data processing can equally support Principle 5. Matching 4 and 5 with the details of ISO17799 (sections 10.2 and 10.5) leads to appropriate guidance. An extension of those sections could make compliance with Principles 4 and 5 naturally part of the application development process. Looking at one aspect of ISO17799 reacting across the whole of the DPA (rather than the other way around as with 2 & 3 above), compliance seemed easier to come by the closer one was to the theory of IT and the more one avoided the front line. The reaction was understandable. For most people it's easier to understand (and thus be willing to support) the Highway Code then various Road Traffic Acts, yet both cover the same subject. While it is good that DPA compliance is strong in the development process, security policy and user training, those aspects do not live in a vacuum. They need to be broadened to ensure that the DPA is more than a fair weather friend. Of the three seemingly most anti-DPA ISO17799 aspects, system planning, asset accountability and response to incidents/malfunctions, asset accountability can be discounted as it's far from the normal areas of DPA concern. System planning is a highly technical process and provided the kit is data free to start with the DPA is irrelevant. Incident response means all hands the pump. There is no time for legal niceties. Wrong, wrong, wrong. A challenge of DPA-ISO17799 compliance is to show its relevance and indeed its positive value, in any IT situation. The first two above are easy. In the first case, assets can hold personal data, or can be used to access such data or process it in many ways. If the development team cannot show accountability they are not in control of their assets, or in a wider sense their company's assets, which include the developing application. In the second case, while it is true that system planning is a technical consideration, it is also true the system which is being planned is one which must processes any personal data in a secure and lawful manner. The compliance must be part of the plan, not a add-on to it. The third case, where the crisis of incident management may exclude all thought of ISO17799 and the DPA, is harder to address. Even at the extreme of service failure, there must be rules of security and of law that the system recovery team must not break. This is a question of discipline which means it is a question of training. However, even the eloquent summary of the DPA in its Eight Principles does not really help the team battling to recover some failed service. Simple rules are best. Regardless of the urgency of recovery, certain things need to be inviolate : system access control, data currency, data accuracy. Some paths to follow Given that the goal is a more effective compliance with the DPA during application development, the following paths, based on the above, look variously hopeful. If something is missing from the DPA, for the application developer, that could be provided by harmony with ISO17799, then that thing must be guidance. The DPA tells us not to do things. Laws do that. ISO17799 advises us not to do things, but also suggests what to do instead. Since laws cannot suggest, ISO17799 needs to grow to encompass guidance that is reactive to the law. There are very few laws, considering its social power, that relate directly to IT and all of them (apart from the DPA) are out of date. So now is a good time to start. Application developers can call upon a variety of development and project control aids to help them they prepare their product. In addition, that are also a variety of project checks that can be used to verify product quality during and after development. It would be worth while investigating whether these aids promote DPA compliance in the product and in what sense this is delivered in an ISO17799 context. If improvements seem appropriate, then a product orientation of ISO17799 seems a good approach. Creating guidelines for DPA compliant data management should be straight forward. The DPA says what it wants and ISO17799 knows where to find it. The path looks clear. There are, ironically, some good pointers in the Common Criteria. Broadening out ISO17799, so that the comfortable theory better supports harsh reality would be a way to bring DPA compliance centre stage in the application development world. A fine prize some way off. Here the path seems foggy. The author, for one, senses the problem, but not yet well enough to describe it, much less propose a solution. Where whole aspects of ISO17799 seem to be at odds with the DPA, analysis suggests that the problem is really a lack of understanding rather then real disharmony. Training is the key, and a way to focus that is to tune the heart of ISO17799, the Security Policy, such that is fundamentally DPA compliant. This does not mean adding a line that says, 'by the way don't forget to observe the DPA'. It means designing a Policy based directly on the DPA Principles. Interestingly such policies are also naturally ISO17799 compliant. Comments are welcome to jarvisco@globalnet.co.uk A light practical can be found at www.instis.org (see Articles August 2001 on DPA & 7799). HOME ~ WEBLINKS ~ CONTACTS ==> SOFTWARE DOWNLOAD AREA <==