Security-related news (E65.Mar-2005)

Special to Cipher
NSF Cyber Trust awards
by Carl Landwehr, National Science Foundation
March 2, 2005

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.

Special to Cipher
Systems Quality Requirements Engineering Methodology
by Nancy Mead, Ted Stehney of Carnegie Mellon University
March 14, 2005

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 such 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.

Special to Cipher
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.