Items from security-related news (E66.May-2005)
PITAC Releases Cyber Security Report
March 18, 2005
Contributed by Gene Spafford.
[As a member of the PITAC and a co-author of the report, I strongly encourage people will take time to read this and think about how to help carry out the recommendations. --spaf]
For Immediate Release
Contact: Alan S. Inouye
March 18, 2005
PRESIDENT'S INFORMATION TECHNOLOGY ADVISORY COMMITTEE RELEASES NEW REPORT
CYBER SECURITY: A CRISIS OF PRIORITIZATION
Vital to the Nation's security and everyday life, the information technology (IT) infrastructure of the United States is highly vulnerable to disruptive domestic and international attacks, the President's Information Technology Advisory Committee (PITAC) argues in a new report. While existing technologies can address some IT security vulnerabilities, fundamentally new approaches are needed to address the more serious structural weaknesses of the IT infrastructure.
In Cyber Security: A Crisis of Prioritization, PITAC presents four key findings and recommendations on how the Federal government can foster new architectures and technologies to secure the Nation's IT infrastructure. PITAC urges the Government to significantly increase support for fundamental research in civilian cyber security in 10 priority areas; intensify Federal efforts to promote the recruitment and retention of cyber security researchers and students at research universities; increase support for the rapid transfer of Federally developed cyber security technologies to the private sector; and strengthen the coordination of Federal cyber security R&D activities.
To request a copy of this report, please complete the form at http://www.nitrd.gov/pubs/, send an e-mail to firstname.lastname@example.org, or call the National Coordination Office for Information Technology Research and Development at (703) 292-4873. Cyber Security: A Crisis of Prioritization can also be downloaded as a PDF file by accessing the link at http://www.nitrd.gov/pubs/.
The original SSH protocol, widely known as SSHv1, was never formally documented so the IETF SecSH Working Group came together to produce a backwards-compatible upgrade to SSHv1. The new protocol, known as SSHv2, consists of three major components: the transport layer protocol, the user authentication protocol, and the connection protocol. Extensibility was one of the major goals in developing this new protocol suite. As a result, it is easy to add new ciphers, MACs and key exchange algorithms. Additional standard ones will be documented in future RFCs; however, anyone can add their own without going through the IETF process. This was accomplished by fully defining the namespace for the ciphers, MACs and key exchange algorithms. The mandatory-to-implement ones are defined in the recently approved documents, and instructions for the addition of new ones are defined in the Assigned Numbers document [SSH-NUMBERS].
The SSH protocol is described in a set of core documents. The first document, the Architecture document [SSH-ARCH], lays out the overall architecture for the SSH protocol and its application interfaces. A significant portion of this document deals with security considerations. Since SSHv1 has been available for many years, a great quantity of empirical knowledge/evidence was accumulated and placed in this document so that both implementors and people deploying SSH would know of the potential problems and pitfalls. To users, the major problem is in the distribution of the server key. This is significant since the acceptance of SSH is widely attributed to its ease-of-use.
The Transport Layer Protocol [SSH-TRANS] provides server authentication, confidentiality, and integrity. It may optionally also provide compression. The transport layer typically runs over a TCP connection, but it could use any reliable data stream. It is essential that this protocol be initiated first. The other layers depend on its security services. To achieve the extensibility goal, the textual namespaces are used for all exchanged or negotiated parameters. For example, an SSH server proposes encryption algorithms in a comma delimited list. With the currently defined ciphers, this list may be:
A non-standard encryption algorithm name is easily added to the list, but it must be differentiated from the standard ones by the inclusion of the "@" character. Let's say that Chuck Babbage of Example Corporation creates a new cipher that he calls chukscipher. Mr. Babbage can add this encryption algorithm to the proposal list as email@example.com, allowing the server to propose a list like:
The client can search for matches, selecting the most preferred alternative that meets local policies. If the client does not recognize chukscipher, it is simply ignored. Yet, any SSH client that recognizes and implements chuckscipher can elect to use it.
The Transport Layer Protocol document also specifies a negotiation method for SSHv1 and SSHv2 implementations to interoperate. However, in many cases, this interoperability is not desired for local policy reasons.
The User Authentication Protocol [SSH-USERAUTH] authenticates the client-side user to the server. It runs over the transport layer protocol. There are some mandatory-to-implement authentication methods, and new authentication methods may be defined in future RFCs. Private use authentication methods may be defined by any practitioner. As an example, let's say that a new authentication method is devised called macarena by another group at Example Corporation. The server could propose the list of user authentication methods like:
If the macarena method is selected and the user successfully performs Macarena authentication, then access will be granted.
The Connection Protocol [SSH-CONNECT] runs over the user authentication protocol, and it multiplexes the protected tunnel into logical channels. The two primary uses of this protocol are interactions with applications on the server and port forwarding for virtual private networking. Remote shell operations (remote interactive shell and remote command execution) use the "session" channel type. Secure X11 operations are performed through the "x11" channel type. The "forwarded-tcpip" and "direct-tcpip" channel types provide virtual private network access.
The publication of these core documents as RFCs is eagerly awaited by the Internet community. The IETF SecSH Working Group is building on this foundation. Among other, an authentication method that uses X.509v3 certificates, a file transfer service, and a means to convey BREAK through a SSH session are being developed. SSH is also being viewed as a secure transport by other IETF Working Groups. For example, the Network Configuration Working Group (netconf) has selected SSH to fulfill their security requirements.
For more information, contact Chris Lonvick (firstname.lastname@example.org) or Russ Housley (email@example.com).
Security Researchers Reveal Microsoft Funding
From the Seattle Post-Intelligencer
March 23, 2005
Two researchers, from the Florida Institute of Technology and Boston-based Security Innovation Inc., 'surprised the audience at a computer-security convention last month with their finding that a version of Microsoft Windows was more secure than a competing Linux operating system' according to the Seattle Post-Intelligencer. 'This week, the researchers released their finished report, and it included another surprise: Microsoft was funding the project all along.'
CERT Issues Report on Insider Sabotage
Contributed by Sven Dietrich
May 16, 2005
This report (pdf), the second in a series presenting research conducted by the U.S. Secret Service and CERT, analyzes insider incidents across critical infrastructure sectors in which the insider's primary goal was to sabotage some aspect of the organization or to direct specific harm towards an individual. An executive summary is available at: http://www.cert.org/insider_threat/insidercross.html
DARPA Shifts Research Horizons
Chronicle of Higher Education
13 May 2005
Contributed by Richard Schroeppel
The House Science Committee this week discussed the Defense Advanced Research Projects Agency (DARPA) research priorities this week. DARPA is shifting its focus from basic research to projects with more immediate results.
Anthony J. Tether, director of DARPA, deflected criticism of the agency's cybersecurity funding by saying that such projects were, in fact, being funded. He also noted his opinion that computer science research was funded from other allocations, notably microelectronics.