Return-Path: <sentto-279987-4854-1024636721-fc=all.net@returns.groups.yahoo.com> Delivered-To: fc@all.net Received: from 204.181.12.215 [204.181.12.215] by localhost with POP3 (fetchmail-5.7.4) for fc@localhost (single-drop); Thu, 20 Jun 2002 22:20:09 -0700 (PDT) Received: (qmail 22349 invoked by uid 510); 21 Jun 2002 05:18:42 -0000 Received: from n2.grp.scd.yahoo.com (66.218.66.75) by all.net with SMTP; 21 Jun 2002 05:18:42 -0000 X-eGroups-Return: sentto-279987-4854-1024636721-fc=all.net@returns.groups.yahoo.com Received: from [66.218.67.201] by n2.grp.scd.yahoo.com with NNFMP; 21 Jun 2002 05:18:42 -0000 X-Sender: fc@red.all.net X-Apparently-To: iwar@onelist.com Received: (EGP: mail-8_0_3_2); 21 Jun 2002 05:18:41 -0000 Received: (qmail 44299 invoked from network); 21 Jun 2002 05:18:40 -0000 Received: from unknown (66.218.66.218) by m9.grp.scd.yahoo.com with QMQP; 21 Jun 2002 05:18:40 -0000 Received: from unknown (HELO red.all.net) (12.232.72.152) by mta3.grp.scd.yahoo.com with SMTP; 21 Jun 2002 05:18:41 -0000 Received: (from fc@localhost) by red.all.net (8.11.2/8.11.2) id g5L5JQP02303 for iwar@onelist.com; Thu, 20 Jun 2002 22:19:26 -0700 Message-Id: <200206210519.g5L5JQP02303@red.all.net> To: iwar@onelist.com (Information Warfare Mailing List) Organization: I'm not allowed to say X-Mailer: don't even ask X-Mailer: ELM [version 2.5 PL3] From: Fred Cohen <fc@all.net> X-Yahoo-Profile: fcallnet Mailing-List: list iwar@yahoogroups.com; contact iwar-owner@yahoogroups.com Delivered-To: mailing list iwar@yahoogroups.com Precedence: bulk List-Unsubscribe: <mailto:iwar-unsubscribe@yahoogroups.com> Date: Thu, 20 Jun 2002 22:19:26 -0700 (PDT) Subject: [iwar] [fc:COMPUTER.SECURITY.SOME.THOUGHTS.ON.STANDARDS.and.TESTING,.FORMAL.METHODS] Reply-To: iwar@yahoogroups.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=3.2 required=5.0 tests=RISK_FREE,FREE_MONEY,DIFFERENT_REPLY_TO version=2.20 X-Spam-Level: *** Sent by Wanja Eric Naef. [The article below is from a list member who like to stay anonymous. Please send any comments about the article to me and I will forward them to the author. WEN] By Anonymous, 19. June 2002 COMPUTER SECURITY SOME THOUGHTS ON STANDARDS and TESTING, FORMAL METHODS and WAY FORWARD Background 1. When I think of the history of computing and lessons to be learned I would start with Bletchley Park in World War II. The task was to break Enigma and other German enciphering systems. This could only be done by designing and using appropriate computer systems (including Colossus). Security of the operation was paramount. Physical, personnel and technical security aspects all had to be addressed and great pains were taken to ensure that there were no loop holes in this cordon sanitaire. History records the Bletchley Park operations as an enormous success with security ‘breaches’ at an absolute minimum. So why do we have such enormous difficulties with computer security 60 years later? 2. There are many reasons. Some are given below – a) We do not provide adequate physical security; b) We do not take the rigorous steps needed for adequate personnel security; c) We do not adopt adequate technical security measures; d) We do not employ computer systems for one purpose and one purpose alone. From the technical security point of view most of our problems arise because we want to use systems - particularly the Internet - which were not designed with security in mind. This is in total contrast to the Bletchley Park regime. Recent History 3. Security problems have been obvious since at least 1970s. The USA began to address these problems at that time with Computer Security Standards (NSA `s Orange Book). Within a few years the computer world was moving away from main frame computing to distributed computing. In the UK it was realised that the Orange Book standards could not just be ‘read across’. The ITSEC scheme run jointly by the DTI and CESG was born. The cornerstone of ITSEC was that components, devices, software and firmware should be evaluated against specific security standards from E1 (lowest level) to E6 (highest level). Through the 1990s the ideas behind ITSEC have been increasingly adopted by other countries and “Common Criteria” has evolved. This is a significant step with Common Criteria becoming International Standard 15408 in 1999. 4. Despite these good efforts problems remain. These difficulties arise for many reasons but amongst them are – a) Technology ‘churn` - the ever increasing paceof new developments and products; b) Time to test – months sometimes years; c) Test limitations – testing will perforce beconducted over a very limited configuration. 5. Further, integration issues are not addressed by ITSEC/Common Criteria (they are not designed to). This gives rise to the problem where the unwitting may buy and install an E3 Firewall and believe that all is well. Of course, it is not - any more than one padlock can secure your home. Even more importantly, organisations of all sorts and sizes, e.g. corporations, HMG departments and the Police adopt complex and largely open systems. Risks 6. The risks associated with such systems are addressed by system security officers and IT staffs but their efforts are often less than cohesive. Examples are legion and some bring unwanted publicity to their organisations. This is particularly so where even the general public feel they ought to have known better e.g. Microsoft and Barclays. In these two recent cases “inadequate software testing” was blamed. Standards 7. Standards are useful yardsticks whether specific or procedural. The standards called up by ITSEC and Common Criteria are specific but the rule of “caveat emptor” still applies. A properly installed E3 Firewall can help give a fair level of protection but remember that this is an E3/EAL 4 device not an E6/EAL7 device and testing will not be exhaustive:- “testing will be supported by an independent search for obvious vulnerabilities”. In other words vulnerabilities will remain. It is only at EAL5 and 6 levels that semi-formal methods are employed in testing. At EAL 7 extensive formal analysis is employed but generally this can only be done where designs are (much) less complex. 8. The procedural standards of ISO17999 provide a template and guidelines for implementing Infosec holistically. Much of ISO17999 is common sense and undemanding of management. Nonetheless it provides a framework and basis for good security. However, even adequate security will demand a great deal more than doing an ISO17999 check list and ‘ticking the boxes’. Formal Methods and Proof of Concepts 9. Formal Methods are often seen as too costly. However, Formal Methods are used at EAL5 – EAL7 levels. At these levels of confidence security can be seen as an enabler (and thus cost effective) rather than an expensive overhead. Formal Methods and Proof of Concepts certainly have a role to play. Information Flow Analysis can be used to check that actual dependencies in code match that which was intended. For example, Praxis Critical Systems have reported that Proof of Concepts can be more efficient than any form of testing and that System Validation testing can be more efficient in finding faults than can individual unit testing (see IEEE Vol 26 Nr 8 of Aug 2000). Way Ahead? 10. Obviously we must, collectively, do better. Despite the considerable difficulties I believe we can. There is no easy blueprint for success but these are suggested tenets. a) Adopt appropriate technology. Look at what is on offer: balance the advantages of a product or service with its known downsides. For example, I use Microsoft Outlook Express because its easy to use; others will look at its security vulnerabilities and choose a more secure product. b) Adopt a systems engineering approach. The use of Formal Methods and Proof Concepts can be very cost effective in particular where a high level of security is needed. c) Integrate new technology and new products cohesively and carefully. d) Use products and services you can trust. ITSEC and CC approved products can be a good starting point but don`t discount appropriate offerings from smaller companies who cannot afford cost of such testing. e) Have your (revised) system tested for functionality and vulnerabilities. Use an approved test house and/or approved intruder detection system. f) Review these results. Don`t go live if you have doubts – fix and re-check. g) Re-test and review regularly. h) Empower your IT staff (whether directly employed or not) to take corrective action if your systems come under attack or encounter new threats and vulnerabilities. i) Adopt an holistic approach. Be sure to adequately address physical and personnel security aspects. Regularly review all security related aspects. BCS Role [British Computer Society] 11. The BCS has an important role to play not least because it can speak to the individual user as well as having influence with key players. Education and outreach using existing BCS channels including meetings, workshops, seminars, literature and www.bcs.org Encourage enterprises to see security as a (potential) enabler (i.e. as cost effective – not an added cost). Encourage Microsoft and other key players to give due weighting to security aspects. Encourage DTI and CESG to bring forward improvements in ITSEC/CC – making testing more relevant and speeding up EAL1 to EAL 4 testing as a first step: (Fast Track and Certificate Maintenance initiatives are insufficient). Work with other bodies to seek ways to evaluate security products from smaller manufacturers who cannot afford ITSEC/CC testing. Work effectively with other organisations to achieve the above aims. ------------------------ Yahoo! Groups Sponsor ---------------------~--> Free $5 Love Reading Risk Free! http://us.click.yahoo.com/3PCXaC/PfREAA/Ey.GAA/kgFolB/TM ---------------------------------------------------------------------~-> ------------------ http://all.net/ Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
This archive was generated by hypermail 2.1.2 : 2003-08-24 02:46:32 PDT