_/_/_/_/ _/_/_/ _/_/_/_/ _/ _/ _/_/_/_/ _/_/_/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/_/ _/_/_/_/ _/_/ _/_/_/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/_/ _/_/_/ _/ _/ _/ _/_/_/_/ _/ _/ ========================================================================== Newsletter of the IEEE Computer Society's TC on Security and Privacy Electronic Issue 65 March 18, 2005 Hilarie Orman, Editor Sven Dietrich, Assoc. Editor cipher-editor @ ieee-security.org cipher-assoc-editor @ ieee-security.org Bob Bruen, Book Review Editor, cipher-bookrev @ ieee-security.org ========================================================================== The newsletter is also at http://www.ieee-security.org/cipher.html Contents: * Letter from the Editor * Conference and Workshop Announcements o IEEE Security and Privacy Symposium, May 8-11, 2005 Berkeley, CA, Claremont Resort Preliminary Program * Commentary and Opinion o Robert Bruen's review of "Buffer Overflow Attacks. Detect, Exploit, Prevent" by Foster, James, and Vitaly Osipov, and Nish Bhalla, and Niels Heinen o Robert Bruen's review of "The Art Of Computer Virus Research and Defense" by Peter Szor o Robert Bruen's review of "Internet Denial of Service. Attack and Defense Mechanisms" by Mirkovic, Jelena, and Sven Dietrich, and David Dittrich, and Peter Reiher o IETF Revises Kerberos Specifications, by Sam Hartman and Russ Housley o Review of the RSA Security Conference by Jeremy Epstein o Carl Landwehr announces NSF 2004 Cyber Trust Award summaries o Systems Quality Requirements Engineering Methodology by Nancy Mead and Ted Stehney of Carnegie Mellon University Contributed by Sven Dietrich o Book reviews, Conference Reports and Commentary and News items from past Cipher issues are available at the Cipher website * List of Computer Security Academic Positions, by Cynthia Irvine * Staying in Touch o Information for subscribers and contributors o Recent address changes * Interesting Links and New reports available via FTP and WWW * Links for the IEEE Computer Society TC on Security and Privacy o Becoming a member of the TC o TC Officers o TC publications for sale ==================================================================== Letter from the Editor ==================================================================== Dear Readers: I am pleased to present three articles written for Cipher in this issue, as well as the customary contribution of three lively book reviews from Robert Bruen. The RSA security conference elicited a report of impressions by Jeremy Epstein, who should be designated Cipher reporter-at-large for his many such articles over the years. The security area directors for the Internet Engineering Task Force, Russ Housley and Sam Hartman, provided us with an update on recent happenings in the Kerberos standardization effort. Nancy Mead and Ted Stehney of Carnegie Mellon University report on an examination of how engineering quality assurance methods fare when applied to system security issues. The IEEE Symposium on Research in Security and Privacy will hold its annual meeting at the Claremont Resort in Berkeley, California on May 8-11. The list of sessions and papers appears in this Cipher issue, and it promises to be an interesting event. We need a reporter to cover this venerable conference, so please considering volunteering to cover all or part of the conference. A reader recently suggested that our online calendar and calls-for-papers web page should primarily represent conferences with published proceedings, because those venues are more valuable for researchers. We will probably be reading CFP's a little more carefully so that we can denote "proceedingless" conferences in some way on the web pages. We welcome such comments and suggestions that will help us improve the utility of Cipher's online presence. Usually Cipher contains a list of upcoming conference dates and CFP's. They are available online, as always, but your editor did not have time to extract and format the full list for this issue. Cipher's contributors are a wonderful group. We can always use help, and we always welcome relevant material. Send us news items, your commentary on conferences or workshops (especially if there are no proceedings!), or notices of events. If you are driving a cryptographic hash function, wear a seatbelt, there have reports of numerous collisions recently. Hilarie Orman cipher-editor @ ieee-security.org ==================================================================== Conference and Workshop Announcements ==================================================================== 2005 IEEE Symposium on Security and Privacy May 8-11, 2005 The Claremont Resort Oakland, California, USA sponsored by the IEEE Computer Society Technical Committee on Security and Privacy in co-operation with The International Association for Cryptologic Research (IACR) (see http://www.ieee-security.org/TC/SP2005/oakland05.html) Monday, May 9, 2005 Session: Intrusion Detection (Wenke Lee) Language-Based Generation and Evaluation of NIDS Signatures Shai Rubin, Somesh Jha, Barton P. Miller Efficient Intrusion Detection using Automaton Inlining Rajeev Gopalakrishna, Eugene H. Spafford, Jan Vitek Semantics-Aware Malware Detection Mihai Christodorescu, Somesh Jha, Sanjit Seshia, Dawn Song, Randal E. Bryant Session: Sensor Networks (Michael Backes) Distributed Detection of Node Replication Attacks in Sensor Networks Bryan Parno, Adrian Perrig, Virgil Gligor Detection of Denial-Of-Message Attacks on Sensor Network Broadcasts Jonathan M. McCune, Elaine Shi, Adrian Perrig, Michael K. Reiter Session: 5-minute Work-in-progress Talks (Vern Paxson, Michael Waidner) (Proposals for 5-minute talks can be submitted until April 1, 2005, 19:00 CET. For details please check the Call for Papers) Tuesday, May 10, 2005 Session: Access Control and Authentication (Virgil Gligor) Distributed Proving in Access-Control Systems Lujo Bauer, Scott Garriss, Michael K. Reiter On Safety in Discretionary Access Control Mahesh V. Tripunitara, Ninghui Li Seeing-Is-Believing: Using Camera Phones For Human-Verifiable Authentication Jonathan M. McCune, Adrian Perrig, Michael K. Reiter Session: Integrity (Michael K. Reiter) A Generic Attack on Checksumming-Based Software Tamper Resistance Glenn Wurster, Paul van Oorschot, Anil Somayaji Towards Constant Bandwidth Overhead Integrity Checking of Untrusted Data Dwaine Clarke, G. Edward Suh, Blaise Gassend, Ajay Sudan, Marten van Dijk, Srinivas Devadas Bind: A Time-Of-Use Attestation Service For Secure Distributed System Elaine Shi, Adrian Perrig, Leendert Van Doorn Session: Cryptography and Protocols (Josh Benaloh) Relating Symbolic And Cryptographic Secrecy Michael Backes, Birgit Pfitzmann Low-Cost Traffic Analysis Of Tor Steven Murdoch, George Danezis Leap-Frog Packet Linking and Diverse Key Distributions for Improved Integrity In Network Broadcasts Michael T. Goodrich Wednesday, May 11, 2005 Worms and Network Forensics (Giovanni Vigna) Remote Physical Device Fingerprinting Tadayoshi Kohno, Andre Broido, KC Claffy Polygraph: Automatically Generating Signatures For Polymorphic Worms James Newsome, Brad Karp, Dawn Song Worm Origin Identification Using Random Walks Yinglian Xie, Vyas Sekar, David A. Maltz, Michael K. Reiter, Hui Zhang ==================================================================== Upcoming Calls-For-Papers and Events ==================================================================== The complete Cipher Calls-for-Papers is located at http://www.ieee-security.org/CFP/Cipher-Call-for-Papers.html The Cipher event Calendar is at http://www.ieee-security.org/Calendar/cipher-hypercalendar.html 3/18/05: Foundations of Computer Security http://www.cs.chalmers.se/~andrei/FCS05/, Chicago, IL submissions are due 3/18/05: Conference on Security and Privacy for Emerging Areas in Communication Networks, http://www.securecomm.org, Athens, Greece; Submissions are due 3/22/05: Applications and Services in Wireless Networks, http://www.ieee-security.org/Calendar/cfps/cfp-ASWN05.html>Paris, France 3/23/05- 3/24/05: CERIAS Information Security Symposium, http://www.cerias.purdue.edu/news_and_events/events/symposium/2005/, West Lafayette, IN 3/23/05- 3/24/05: Information Assurance Workshop http://iwia.org/2005/CfP_WS2005.html>, Washington, DC 3/25/05: European Symposium on Research in Computer Security, http://esorics05.dti.unimi.it, Milan, Italy submissions are due 3/30/05: Workshop on Security and Privacy in Ad hoc and Sensor Networks, http://www.crysys.hu/ESAS2005/cfp.html Budapest, Hungary; submissions are due 3/30/05: Usenix Workshop on Steps to Reducing Unwanted Traffic on the Internet http://www.research.att.com/~bala/sruti/, Cambridge, MA 3/30/05: Workshop on Critical Information Infrastructures http://www.ida.liu.se/conferences/CIIW05/, Linkoping, Sweden submissions are due 3/31/05: Symposium on Recent Advances in Intrusion Detection http://www.conjungi.com/RAID/, Seattle, Washington; submissions are due ==================================================================== Commentary and Opinion ==================================================================== Book reviews from past issues of Cipher are archived at http://www.ieee-security.org/Cipher/BookReviews.html, and conference reports are archived at http://www.ieee-security.org/Cipher/ConfReports.html ____________________________________________________________________ Report on the The RSA Security Conference February 2005 San Francisco, CA by Jeremy Epstein Senior Director, Product Security & Performance http:/www.webMethods.com ____________________________________________________________________ This was my first time attending, and I expected to be unimpressed, as I usually am at conferences that have lots of trade show / PR aspects. To my surprise, there were a lot of good talks, as well as goodies on the show floor. The organizers claimed over 13,000 attendees, and it felt that way trying to find a seat in some of the tracks, or find somewhere to sit down to talk to someone. Predominant technologies in the trade show were: - Authentication devices - 2 factor, challenge response, biometrics, etc. - Anti-spam software, appliances, services, etc. - Security assessment services, including for regulatory compliance. - Fair amount of IDS & IPS, with less hype than in the past. - Wireless crypto devices. - Security testing via static and dynamic testing. I didn't see anything radically new and exciting on the show floor. I asked several people I know what excited them the most, and heard "nothing much". Highlights: - There's a lot more focus on getting confidence that systems are built securely - Everyone understands that web services have a lot of potential dangers, but many users are ignoring them and moving forward with implementation - The security field is progressing very slowly, and keeps making the same mistakes - There's a lot of talk about the SHA-1 break, but it's not practical at this point - Bill Gates may be rich as Croesus, but he's also a mediocre speaker Some of the highlights.... Cryptographer's Panel --------------------- The cryptographers panel focused on predictions for the future, as well as looking at prior predictions. Video clips showed previous predictions, and the panelists were asked to comment on how their views had changed and what they got right and wrong. - Passwords won't go away - the real reason IT wants to get rid of passwords isn't security, but rather password sharing. For many applications, passwords are good enough. - RFID tags are still coming. An interesting usage is in libraries to find mis-filed books, which when misplaced are effectively lost forever - Provable security isn't much closer than it was 12 years ago, when it was predicted to be 10 years away. - Anonymous electronic money, which was predicted as a key technology for the Internet 10 years ago, is never going anywhere; the real progress is in online credit cards. [There was an article in the Washington Post about small value transactions a few weeks ago. See http://www.washingtonpost.com/wp-dyn/articles/A45393-2005Feb22.html ] - Fraud isn't as big a problem as was expected. - Hardware cryptanalysis may start getting interesting - the new multi-core chips have the potential for allowing one thread to do cryptanalysis of what another chip is doing by watching the timing and processor state. This is critical for Digital Rights Management (DRM). There was a discussion of the new SHA-1 security break found by a group of Chinese cryptographers who had been totally unknown until a year ago. Their progress is really surprising, because they don't come out of any recognized cryptographic community. They can find collisions in 2^69 tries rather than 2^80 as would be expected. It's not severe enough to change things, but cause for caution. SHA-256, SHA-384, and SHA-512 will increase the work factors enough to be safe for now. Web services security --------------------- There were a number of presentations on web services hacking, mostly pointing out that the same issues that apply in any other application apply to web services. Just because something is behind the firewall doesn't mean it's safe. There are SQL injection attacks, cross-site scripting, etc., plus a few unique ones such as recursive XML using DTDs to cause the XML processor to (effectively) perform a DoS attack on itself. WSDL and UDDI are great things that make web services useful, but they also give an attacker lots of information about what an attack should look like. Some companies are responding by keeping their WSDL proprietary (a security through obscurity attack). What was both enlightening and alarming is that the few actual customer presentations on use of web services were just using SSL and username/password authentication, with the assumption that trading partners are entirely benign so they make minimal efforts to protect against attacks once you're authenticated. The one bit of good news is that since every web services installation is relatively unique (offering different web services), an attacker will need to go after each web service individually (as opposed to firewalls or operating systems, that are multiple instances of the same thing). Regulation for improved security -------------------------------- This debate has been covered pretty extensively in the media, so I'll summarize it by noting that the breakdown was mostly Bruce Schneier and Dick Clarke (arguing that government has to force more security) vs. Harris Miller from ITAA & Rick White (who think the free market does fine and regulation is inherently evil). A hot topic of debate was the Choicepoint case (theft of credit information) which happened the day before. Schneier pointed out that companies need to be actually responsible, not just give lip service to security. Specifically, Choicepoint's customers aren't the people whose information was stolen, but rather other companies - so Choicepoint has little non-regulatory incentive to do a better job. He recognizes that regulation *will* stifle innovation, but we need to make the tradeoff for the good of society. His summary was "When we have self-regulation, security becomes a PR issue". Dick Clarke also suggested that disclosure might work as a substitute for regulation, just as Y2K regulations forced companies to disclose, not to fix. Right now, accounting companies are setting the security bar via SOX compliance - is that really what we want? Static analysis --------------- There were several talks around static analysis, generally of source code. There's been a fair amount of progress of commercial products (several of which were exhibited on the show floor), although this field is in its infancy as far as being practical. Most of the academic research is in finding potential problems, which is making good progress. However, the really critical parts are figuring out which of the potential problems are actual vulnerabilities and need to be fixed vs. which can be safely ignored, and then to tell the user what's wrong and how to fix it. It's also harder than just analysis of a program because modern systems are built out of a mish-mash of technologies in n-tier architectures that include C/C++, Java, HTML, Perl, JSPs, etc., and the problems can be from a combination of pieces that are individually "safe". Ten Bugs that Cost Our Customer Billions ---------------------------------------- Ben Jun from Cryptography Research gave perhaps the most amusing talk. He reviewed systemic problems that cost $100M+ each. Briefly: - Bug #10: DVD CSS failure (trivially cracked) caused by bad crypto selection (no reason to do any other types of attack, because the crypto failure is so bad). Lesson learned: bad crypto is inexcusable -- Bug #9: Pachinko stored value fraud (Japanese electronic stored value cards, easily duplicated/forged). Loss was $600M+ from fraudulent cards exchanged for cash. Merchants were indemnified against fraudulent cards, so they had no motivation to watch for fraud. Some indications that North Korea was behind this. Regulators weren't technically savvy, and corporate culture was not to report bad news. Lesson learned: even though fraud can't be eliminated, it needs to be managed. Lesson learned: security field should have equivalent of "morbidity and mortality" meetings in hospitals to review what went wrong, without fear of lawsuits. -Bug #8: Y2K: This was not a security problem, but costs were huge. Testing failed when products were originally built - should have had tests for date rollovers. Lesson learned: try testing data fields more thoroughly. - Bug #7: Napster/P2P: Lesson learned: improved delivery mechanisms simplify content attacks. Countermeasures include new systems that include code to decode content, making the job of the attacker harder. - Bug #6: Spam: Email wasn't designed for a hostile environment. The economic disparity, similar to telemarketers, where it costs the sender much less than the receiver make spam hard to fix. Lesson learned: Infrastructure retrofits are hard & expensive. - Bug #5: Mag stripe skimming: ATM card fronting/cloning is easy. Lesson learned: Need to replace dumb cards with chip-based cards. - Bug #4: Pay TV hacking: The international boundary system (TV regions) generates demand, because can't get programs from certain countries. As a result, attackers are willing to spend $1M to duplicate/crack systems. Lesson learned: don't need to make the system bulletproof, but need to make attacks expensive. - Bug #3: The PC platform: Saltzer & Schroeder identified the principal of least privilege in 1975, but their results are still largely ignored. Most users run as administrator on Windows boxes, which makes them more vulnerable to attack. We need firewalls inside computers, and use of all the rings (not just kernel vs. application). Lesson learned: Don't sidestep partitioning. - Bug #2: 802.11b (WEP): Lousy usage of crypto algorithms, no key management resulted in corporate rollouts being delayed ~18 months. There are real exploits, including database theft. Real threat is for non-PCs (i.e., PDAs, watches). Lesson learned: Make it hard for users to make security mistakes; get expert assistance. - Bug #1: The unknown bug: How do we fail less than we have in the past? Learn from the Risk and Insurance Management Society. ____________________________________________________________________ NSF Award Summaries are Online Carl Landwehr March 2, 204 ____________________________________________________________________ There is now a summary of FY04 Cyber Trust awards, as well as related FY04 CAREER and ITR awards. There is a paragraph summarizing each project, with a hyperlink to the NSF abstract, and the awards are organized into several different sets of categories. Readers can find the summary at http://www.nsf.gov/cise/funding/cyber_awards.jsp For those interested in statistics, the Cyber Trust solicitation received about 490 proposals this year, just about the same number as last year. ____________________________________________________________________ Book Review By Robert Bruen March 14, 2005 ____________________________________________________________________ Buffer Overflow Attacks. Detect, Exploit, Prevent. by Foster, James, and Vitaly Osipov, and Nish Bhalla, and Niels Heinen Syngress Publishing 2005. ISBN 1-932266-67-4 497 pages. $34.95, Index, two Appendices, chapter endnotes & references. Buffer overflows have been a staple of attacks ever since Aleph1's infamous paper "Smashing the Stack for Fun and Profit" was published in Phrack back in 1996. Certainly the BO had been around before the paper, but the explanation with code gave it a boost. Other papers have been published since then. Serious work has been done to prevent it from working, such as the non-executable stack, and several good books have been published showing how to write code that is not so vulnerable to it. Foster and company have significantly expanded the knowledge base with this book. The book looks a lot like the original paper: clear explanations, assembly code, C code and a clear understanding of what is going on under the hood. The book takes advantage of the newer approaches, lots of new exploit code, and distinctions between a stack and a heap. It also highlights the continuing success with attacks on format strings which still provide easy targets. This is a bit distressing since much has been written about them, including relative ease of preventing them, especially with the tools available. The authors estimate that about 20% of successful exploits are buffer overflows. The basic attack still looks the same: write past a buffer boundary depositing code of your choosing, preferably something that will start a command line interpreter with privileges. The new direction studies better ways to accomplish it. Buffer overflows are specific to the operating system and hardware when they utilize machine code, the mechanism of choice. It helps to have a disassembler handy while developing an exploit or trying to do a post mortem. It also helps to understand memory addressing and memory management. The book shows some neat techniques that take advantage of allocating and deallocating memory. An important facet of understanding attacks and prevention is how operating systems differ. As an example, Microsoft Windows does not use system calls in the same way that the various flavors of Unix do. That means that your BO code or your preventative measures will be different. No worries here, the book does a great job showing the unique aspect of each operating system, as well as the code required. In fact, the book has a large number of examples of exploit code with line by line explanations. It is not enough to publish code; to get an understanding, one needs to be able to explain clearly the concepts involved, as the authors do in this book, thus presenting the bigger picture of the problem I really like this book and highly recommend it, but a small caveat is in order. It pushes Application Defense a bit too much and the web site does not actually have the code in the book as promised. Since this is generally considered an extra, this not a big deal - it just means you have to type. ____________________________________________________________________ Book Review By Robert Bruen March 14, 2005 ____________________________________________________________________ The Art Of Computer Virus Research and Defense by Peter Szor Addison-Wesley 2005. ISBN 0-321-30454-3 713 pages, $49.99, Index, End of chapter references. This book appears to be one of the best resources for virus information. Peter Szor has added greatly to the field of viruses and more generally to malware understanding with "The Art of Computer Virus Research and Defense." He treats viruses as the general category, everything else a subset including worms, which he terms network viruses. The distinction between code that needs help getting from one place another and code that can move itself has been with us for a while. As usual, the media does not really know or care about the distinction, blurring the boundaries of the terms. Szor has helped by organizing the concepts and definitions in an thoughtful manner. The main focus is self-replicating malware, however this is accomplished. The book aimed at the professional and well grounded individual, not the casual reader, so assembly is required. The author skips through assembler, VB, Perl, C and other languages with no obvious difficulty. It does mean the reader needs to be able to follow, however, or important information can be lost. For example, if you are not Visual Basic coder, you most likely will be unfamiliar with all the calls available, such as shutting off the visibility of the VB editor. It is a simple statement, setting a variable to false, not difficult code, but if you are unfamiliar with it then it would look like magic. The author happily states he is in the camp of the anti-virus (AV) world which takes the position that there is no value in teaching others how to write virus code. He believes that defenders need to know how to defend, and, moreover, the required expertise is within this book. Therefore, he claims, there is no exploit code in the book and you cannot glean enough information it to write viruses. I am not so sure. He has done a wonderful, detailed, job of describing the evolution of viruses and the techniques of both the attacker and the defender. Lots of code snippets appear throughout the book demonstrating techniques. This is not intended to be a criticism, but it is my opinion that the more you know about the attacker (and attacks) the easier it is to set up defenses. If you are a virus writer, or just a wannabee, reading this book will help in many ways. The number of approaches described will certainly help in the design, as will the many defensive techniques. Of course, you will have to be an expert in areas such as operating systems and assembly language to be really good. There are number of books on viruses going back to Fred Cohen's original work, but this one is highly recommended based on the quality and quantity of useful information, the excellent lists of references and the overall organization. If you want and/or need a real book on viruses, this is it. ____________________________________________________________________ Book Review By Robert Bruen March 14, 2005 ____________________________________________________________________ Internet Denial of Service. Attack and Defense Mechanisms by Mirkovic, Jelena, and Sven Dietrich, and David Dittrich, and Peter Reiher Prentice Hall 2005. ISBN 0-13-147573-8 LoC TK5105.59.I5455. 372 pages, $39.99, index, three Appendices, extensive Bibliography. Any idiot can launch a successful denial of service. It only requires hammering on an Internet service until it is overwhelmed. The only real technical advancement in many years is the distributed version that uses lots of sources to do the hammering. The methods involved in taking over these sources were part of a real technical advance, but it appears that DoS attacks have reached a sort of maturity with little future development. The certain progress has been in its use. The initial DoS's were flooding attacks against servers and networks by those who did it just because they could or because they were unhappy with the victim. Evolution has brought us to the point where extortion is the main goal. Yes, it is all about the money, now. DoS attacks are waged against business, especially gambling establishments. While there are also political uses, by and large, DoS stands as a fairly simple tool to interfere with the financial health of business. This makes it important to understand how it's used and to find ways to mitigate its impact. Mirkovic et al., show a deep understanding of the vagaries of DoS and DDoS. The task at hand is to mitigate the attacks once they start to limit the impact. The holy grail is to find a way to trace back to the various zombies and the to the controller/originator. Without new techniques drawn from extensive experience, it is unlikely that this will happen. The authors have provided as good a description of the state of the art as can be found. I appreciate any book that is well researched with citations and a good bibliography. Those contributions move a book from being just a list of attacks and defenses to a serious work which provides the benefits of real expertise. This book covers a broad range of information from how to determine when an attack is in progress to how to deal with the law. One interesting detour from the criminal aspects is the use of civil law to deal with a DoS. This may become an expanding area of activity. A number of tools and approaches for coping with attacks of this nature get explained. We may see new variations of distributed attacks that will require more innovative methods to combat them. Think for a moment of a constant flow of packets from many sources to many victims at low rates that can ramped up or down instead of just being turned from "flooding on" or "flooding off". These might become a long term, constant presence on the Internet. Other possibilities await. The best we can do is understand what we can, starting with this excellent book. ____________________________________________________________________ IETF Revises Kerberos Specifications Report by Sam Hartman and Russ Housley March 7, 2005 ____________________________________________________________________ Numerous operating systems products and enterprise deployments use the Kerberos network authentication protocol for user and machine authentication. Kerberos uses a trusted third-party, called the key distribution center (KDC), to perform authentication. The IETF has revised the core Kerberos specifications to reflect implementation experience, provide for easier deployment, and utilize new cryptographic algorithms. The Kerberos cryptographic framework (RFC 3961) clearly specifies how cryptographic primitives are used by Kerberos. The document defines the operations and security properties required from a Kerberos cipher suite. It also describes the currently deployed Kerberos cipher suites. The Advanced Encryption Standard (AES) encryption for Kerberos 5 (RFC 3962) specifies the use of the Advanced Encryption Standard for Kerberos. The AES becomes the mandatory-to-implement encryption algorithm, replacing DES. The first revision of the Kerberos Network Authentication Service (V5; the base Kerberos specification) has been approved by the Internet Engineering Steering Group for publications as a standards-track RFC. This revision specifies discovery of Kerberos KDCs using DNS "SRV" records rather than requiring administrator configuration of each client. Policy checking for cross-organizational authentication can be done at the KDC rather than requiring policy distribution to each application server. Many specification errors found in the last 10 years have been corrected. A new Generic Security Services API (GSS API) mechanism for Kerberos is now another standards-track RFC. Unlike the previous mechanisms, this one will not require revision each time a new cipher suite is added to Kerberos. The new mechanism uses the same operations defined in RFC 3961 that other parts of Kerberos use. Work continues on PK-Init, Kerberos protocol specification to simplify key management by using public key cryptography and X.509 certificates during initial authentication. An Internet-Draft specifies the use of preauthentication data fields and error data fields in Kerberos messages to transport public key data. This work is expected to finish in the next few months, resulting in a standards track RFC. Work also continues on a standardized protocol for setting the initial master keys of application servers and for allowing administrators to change user passwords or keys. For more information contact Sam Hartman, hartmans @ mit.edu ____________________________________________________________________ Systems Quality Requirements Engineering Methodology by Nancy Mead, Ted Stehney of Carnegie Mellon University Contributed by Sven Dietrich ____________________________________________________________________ The Survivable Systems Engineering (SSE) team in SEI's Networked Systems Survivability (NSS) Program recently completed case studies using the Systems Quality Requirements Elicitation (SQUARE) methodology. The SQUARE methodology attempts to address industry's continued failures to implement security early on in project development, which in turn stifles return on investment. During the summer and fall of 2004, graduate student teams, under the mentorship of Dr. Nancy Mead, worked with an industry partner to test the current methodology's effectiveness in building security into the early stages of the development lifecycle. The first iteration provided important information-gathering inputs to the second study, including network documentation, use and misuse cases, and attack trees. For the second iteration, specific focus was given to the risk assessment and threat categorization phases of the methodology, as well as to the generation of a multi-tiered security requirements document that could be mapped back to both the business and security goals of the client. Though SQUARE is still a work in progress, the results of the case study found SQUARE to be a useful tool in helping the client develop a security requirements posture that it can use for future planning and accountability purposes. Further, through applying the methodology, the student team was able to generate a critique on SQUARE that came to fruition from their real world findings. This report, soon to be published by CERT/CC, looked favorably on SQUARE as a tool for generating security requirements and offered some suggestions for refining the methodology's nine-step process. The recommendations looked to aid ease of implementation, and to help the somewhat involved nine-step process flow more smoothly when applied in a real-world setting. The NSS Program has taken the results of the two case studies into consideration and continues to fine-tune SQUARE with eventual hopes of industry-wide adoption. SSE plans to apply the revised model, shown below, in a third case study during the summer of 2005. This process is best applied by the project's requirements engineers and security experts in the context of supportive executive management and stakeholders. We believe the process works best when elicitation occurs after risk assessment (step 4) has been done, and when security requirements are specified prior to critical architecture and design decisions. Step 1, Agree on Definitions, is needed as a prerequisite to security requirements engineering. On a given project, team members will tend to have definitions in mind, based on their prior experience, but those definitions won't necessarily agree. For example, to some government organizations, security means access based on security clearance levels, whereas to others security may mean physical security or cyber-security. It is not necessary to invent definitions. Most likely, sources such as IEEE and SWEBOK will provide a range of definitions to select or tailor. A focus group meeting with the interested parties probably will result in a consistent set of definitions to be selected for the security requirements activity. Step 2, Identify Security Goals, needs to be done at the level of the organization and also for the information system to be developed. Different stakeholders are likely to have different goals. For example, a stakeholder in human resources may be concerned about maintaining the confidentiality of personnel records, whereas a stakeholder in a financial area may be concerned with ensuring that financial data is not accessed or modified without authorization. Once the goals of the various stakeholders have been identified, they will need to be prioritized. In the absence of consensus, an executive decision may be needed. Step 3, Develop Artifacts, is necessary to support all the subsequent activities. It is often the case that organizations do not have a documented concept of operations for a project, succinctly stated project goals, documented normal usage and threat scenarios, misuse cases, and other documents needed to support requirements definition. This means that either the entire requirements process is built on a foundation of sand, or a lot of time will be spent backtracking to try to obtain the documentation. Step 4, Perform Risk Assessment, requires an expert in risk assessment methods, support of the stakeholders, and support of the requirements engineer. There are a number of risk assessment methods. A specific method can be recommended by the risk assessment expert, based on the needs of the organization. The artifacts from step 3 provide the input to the risk assessment process. The outcomes of the risk assessment can help identify the high priority security exposures. Organizations that do not do risk assessment typically don't have a logical approach to identifying security requirements, but tend to select mechanisms, such as encryption, without understanding the problem that is being solved. Step 5, Select Elicitation Technique, becomes important when there are several classes of stakeholders. A more formal elicitation technique, such as JAD or structured interviews can be effective when there are stakeholders with different cultural backgrounds. In other cases, elicitation may simply consist of sitting down with a primary stakeholder to try to understand their security requirements needs. Step 6, Elicit Security Requirements, is the actual elicitation process using the selected technique. Most elicitation techniques provide detailed guidance on how to perform elicitation. Step 7, Categorize Requirements, allows the requirements engineer to distinguish between essential requirements, goals (desired requirements), and architectural constraints. Requirements that are constraints typically occur when a specific system architecture has been decided on prior to the requirements process. This categorization helps in the prioritization activity that follows. Step 8, Prioritize Requirements, depends not only on the prior step, but may also suggest performing a cost/benefit analysis, in order to determine which security requirements have a high payoff relative to their cost. Step 9, Requirements Inspection, can be done at varying levels of formality, from Fagan Inspections to Peer Reviews. Once inspection is complete, the organization should have an initial set of prioritized security requirements. They should also understand which areas are incomplete and will need to be revisited at a later time. Finally, they should understand which areas are dependent on specific architectures and implementations, and expect to revisit those as well. ==================================================================== Listing of academic positions available by Cynthia Irvine ==================================================================== http://cisr.nps.navy.mil/jobscipher.html -------------- This job listing is maintained as a service to the academic community. If you have an academic position in computer security and would like to have in it included on this page, send the following information: Institution, City, State, Position title, date position announcement closes, and URL of position description to: irvine@cs.nps.navy.mil ==================================================================== Information on the Technical Committee on Security and Privacy ==================================================================== ____________________________________________________________________ Information for Subscribers and Contributors ____________________________________________________________________ SUBSCRIPTIONS: Two options, each with two options: 1. To receive the full ascii CIPHER issues as e-mail, send e-mail to cipher-admin@ieee-security.org (which is NOT automated) with subject line "subscribe". OR send a note to cipher-request@mailman.xmission.com with the subject line "subscribe" (this IS automated - thereafter you can manage your subscription options, including unsubscribing, yourself) 2. To receive a short e-mail note announcing when a new issue of CIPHER is available for Web browsing send e-mail to cipher-admin@ieee-security.org (which is NOT automated) with subject line "subscribe postcard". OR send a note to cipher-postcard-request@mailman.xmission.com with the subject line "subscribe" (this IS automated - thereafter you can manage your subscription options, including unsubscribing, yourself) To remove yourself from the subscription list, send e-mail to cipher-admin@ieee-security.org with subject line "unsubscribe" or, if you have subscribed directly to the xmission.com mailing list, use your password (sent monthly) to unsubscribe per the instructions at http://mailman.xmission.com/cgi-bin/mailman/listinfo/cipher or http://mailman.xmission.com/cgi-bin/mailman/listinfo/cipher-postcard Those with access to hypertext browsers may prefer to read Cipher that way. It can be found at URL http://www.ieee-security.org/cipher.html CONTRIBUTIONS: to cipher @ ieee-security.org are invited. Cipher is a NEWSletter, not a bulletin board or forum. It has a fixed set of departments, defined by the Table of Contents. Please indicate in the subject line for which department your contribution is intended. Calendar and Calls-for-Papers entries should be sent to cipher-cfp @ ieee-security.org and they will be automatically included in both departments. To facilitate the semi-automated handling, please send either a text version of the CFP or a URL from which a text version can be easily obtained. For Calendar entries, please include a URL and/or e-mail address for the point-of-contact. For Calls for Papers, please submit a one paragraph summary. See this and past issues for examples. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. All reuses of Cipher material should respect stated copyright notices, and should cite the sources explicitly; as a courtesy, publications using Cipher material should obtain permission from the contributors. ____________________________________________________________________ Recent Address Changes ____________________________________________________________________ Address changes from past issues of Cipher are archived at http://www.ieee-security.org/Cipher/AddressChanges.html One of the luminaries of the field, David E. Bell, has announced his retirement and new contact information: 2415 Andorra Place Reston VA 20191 email: davidelliottbell @ mac.com Hilarie Orman reports that she has joined Shinkuro, Inc. as Vice President of Engineering and Chief Technology Officer. She can be reached via her username "hilarie" at shinkuro.com. _____________________________________________________________________ How to become <> a member of the IEEE Computer Society's TC on Security and Privacy _____________________________________________________________________ You may easily join the TC on Security & Privacy by completing the on-line for at IEEE at http://www.computer.org/TCsignup/index.htm ______________________________________________________________________ TC Publications for Sale ______________________________________________________________________ IEEE Security and Privacy Symposium The 2004 Symposium proceedings are available for $25 plus shipping and handling. The 2003 proceedings are $20 plus shipping and handling; the 2000 proceedings are $15 plus shipping and handling. The 1998 proceedings are $15 plus shipping and handling. A CD of the 2000-2001 proceedings is $15 plus shipping and handling. Shipping is $4.00/volume within the US, overseas surface mail is $7/volume, and overseas airmail is $11/volume, based on an order of 3 volumes or less. The shipping charge for a CD is $1 per CD (no charge if included with a hard copy order). Send a check made out to the IEEE Symposium on Security and Privacy to the TC treasurer (see officers, below) with the order description, including shipping method, and send email to Hilarie Orman (see below) with the shipping address, please. IEEE CS Press Back issues of TC publications may be available; contact Jonathan Millen for information about the Computer Security Foundations Workshop. ______________________________________________________________________ TC Officer Roster ______________________________________________________________________ Chair: Past Chair: Heather Hinton Mike Reiter IBM Software Group - Tivoli Carnegie Mellon University 11400 Burnett Road ECE Department Austin, TX 78758 Hamerschlag Hall, Room D208 + 1 512 838 0455 (voice) Pittsburgh, PA 15213 USA hhinton@us.ibm.com (412) 268-1318 (voice) reiter@cmu.edu Vice Chair: Chair, Subcommittee on Academic Affairs: Jonathan Millen Prof. Cynthia Irvine The MITRE Corporation U.S. Naval Postgraduate School Mail Stop S119 Computer Science Department 202 Burlington Road Rte. 62 Code CS/IC Bedford, MA 01730-1420 Monterey CA 93943-5118 781-271-51 (voice) (831) 656-2461 (voice) jmillen@mitre.org irvine@cs.nps.navy.mil Chair, Subcommittee on Standards: Chair, Subcomm. on Security Conferences: David Aucsmith Jonathan Millen Microsoft Corporation The MITRE Corporation One Microsoft Way Mail Stop S119 Redmond, WA 98052 202 Burlington Road Rte. 62 425-706-9225 (voice) Bedford, MA 01730-1420 425-936-7329 (fax) 781-271-51 (voice) awk@microsoft.com jmillen@mitre.org Treasurer: Newsletter Editor: Tom Chen Hilarie Orman Department of Computer Science Purple Streak, Inc. and Engineering 500 S. Maple Dr. School of Engineering Salem, UT 84653 Southern Methodist University (801) 423-1052 (voice) P.O. Box 750122 cipher-editor@ieee-security.org Dallas, TX 75275-0122 (214) 768-8541 (voice) http://www.engr.smu.edu/~tchen ________________________________________________________________________ BACK ISSUES: Cipher is archived at: http://www.ieee-security.org/cipher.html