Contents
[In preparation. References to application security vulnerabilities and incidents.]
- CERT Coordination Center
- Common Intrusion Detection Signatures Standard (CIDSS)
- Common Vulnerabilities and Exposures (CVE)
- DMTF Alert Standard Format Specification (ASF)
- IEEE ICSG Malware Working Group
- IETF Incident Object Description and Exchange Format (IODEF)
- IETF Intrusion Detection Exchange Format (IDMEF)
- OASIS Application Vulnerability Description Language TC (AVDL)
- OASIS Web Application Security TC (WAS)
- OpenSec Advisory and Notification Markup Language (ANML)
- Open Vulnerability Assessment Language (OVAL)
- Open Web Application Security Project (OWASP)
- VulnXML Project: A Web Application Security Vulnerability Description Language
- Vulnerability and Exposure Markup Language (VuXML)
- General: Articles, Papers, News
CERT Coordination Center
CERT's work involves "handling computer security incidents and vulnerabilities, publishing security alerts, researching long-term changes in networked systems, and developing information and training to help [administrators] improve security at their websites."
References:
Common Intrusion Detection Signatures Standard (CIDSS)
"The purpose of the Common Intrusion Detection Signatures Standard (CIDSS) is to define a common data format for storing signatures from different intrusion detection systems. This Internet-Draft describes a common data format to represent information contained in signatures of intrusion detection systems, and explains the rationale for using this common format. The proposed format is a dialect of the Extensible Markup Language (XML). An XML Document Type Definition is developed, and examples are provided." [abstract from the Internet Draft]
The specification and IDS Signature Translator tool have been developed at the Polish-Japanese Institute of Information Technology under the direction of Adam Wierzbicki. As of 2004-11 "the translator was able to translate signatures of Snort and Dragon IDS into the common format; it has also been partially tested with Shoki, ISS RealSecure, and Cisco NetRanger."
- Common Intrusion Detection Signatures Standard. Version -02. October 2005. See the I-D tracker.
- "Common Intrusion Detection Signatures Standard." IETF Internet Draft. October 2004.
- CIDSS XML Schema
- IDS Signature Translator. Developed under the GNU General Public License.
- CIDSS Specification [source PDF]
- Contact: translator@b59.net
- Polish-Japanese Institute of Information Technology
Common Vulnerabilities and Exposures (CVE)
"CVE is a list of information security vulnerabilities and exposures that aims to provide common names for publicly known problems. The goal of CVE is to make it easier to share data across separate vulnerability databases and security tools with this 'common enumeration.'
The CVE Reference Key document provides a description of CVE references and sources, including [2003-03-24]: AIXAPAR: AIX APAR (Authorized Problem Analysis Report), ALLAIRE: Allaire Security Bulletin, ASCEND: Ascend vendor acknowledgement, ATSTAKE: @stake security advisory, AUSCERT: AUSCERT advisory, BID: Security Focus Bugtraq ID database entry, BINDVIEW: BindView security advisory, BUGTRAQ: Posting to Bugtraq mailing list, CALDERA: Caldera security advisory, CERT: CERT/CC Advisories, CERT-VN: CERT/CC vulnerability note, CHECKPOINT: Check Point Alert, CIAC: DOE CIAC (Computer Incident Advisory Center) bulletins, CISCO: Cisco security advisory, COMPAQ: COMPAQ Service Security Patch, CONECTIVA: Conectiva Linux advisory, CONFIRM: URL to location where vendor confirms that the problem exists, DEBIAN: Debian Linux Security Information, EEYE: eEye security advisory, EL8: EL8 advisory, ENGARDE: En Garde Linux advisory, ERS: IBM ERS/BRS advisories, FREEBSD: FreeBSD security advisory, FarmerVenema: "Improving the Security of Your Site by Breaking Into it" paper by Dan Farmer and Wietse Venema, FreeBSD: FreeBSD security advisory, HERT: HERT security advisory, HP: HP security advisories, IBM: IBM ERS/BRS advisories, IMMUNIX: Immunix Linux advisory, INFOWAR: INFOWAR security advisory, ISS: ISS Security Advisory, KSRT: KSR[T] Security Advisory, L0PHT: L0pht Security Advisory, MANDRAKE: Linux-Mandrake advisory, MISC: Miscellaneous URL's, MS: Microsoft Security Bulletin, MSKB: Microsoft Knowledge Base article, NAI: NAI Labs security advisory, NETBSD: NetBSD Security Advisory, NETECT: Netect security advisory, NTBUGTRAQ: Posting to NTBugtraq mailing list, NetBSD: NetBSD Security Advisory, OPENBSD: OpenBSD Security Advisory, REDHAT: Security advisories, RSI: Repent Security, Inc. security advisory, SCO: SCO security bulletins, SEKURE: Sekure security advisory, SF-INCIDENTS: posting to Security Focus Incidents mailing list, SGI: SGI Security Advisory, SNI: Secure Networks, Inc. security advisory, SUN: Sun security bulletin, SUNBUG: Sun bug ID, SUSE: SuSE Linux: Security Announcements, TURBO: TurboLinux advisory, URL: General placeholder for recording URL's in candidates, VULN-DEV: Posting to VULN-DEV mailing list, VULNWATCH: VulnWatch mailing list, WIN2KSEC: Win2KSecAdvice mailing list, XF: X-Force Vulnerability Database.
DMTF Alert Standard Format Specification (ASF)
"The DMTF defines Desktop Management Interface (DMI) and Common Information Model (CIM) interfaces that best serve the clients' OS-present environment. The Alert Standard Format specification defines remote control and alerting interfaces that best serve clients' OS-absent environments... The term 'system manageability' represents a wide range of technologies that enable remote system access and control in both OS-present and OS-absent environments. These technologies are primarily focused on minimizing on-site I/T maintenance, maximizing system availability and performance to the local user, maximizing remote visibility of (and access to) local systems by I/T managers and minimizing the system power consumption required to keep this remote connection intact..."
See also: DMTF Security Protection and Management Working Group. "The Working Group will define a CIM Common Model that addresses security protection and detection technologies, which may include devices and services, and classifies security information, attacks and responses. Technologies may include but are not limited to firewall, intrusion detection, vulnerability assessment, and antivirus functionalities. Network protocols include but are not limited to IP and FiberChannel. The goal is to ease the manageability of heterogeneous security systems within an enterprise or service provider environment, as well as to provide a standard mechanism for managing systems from a security perspective... Security of a host, network device, or network can be addressed in a number of ways. Some examples include scanning for known vulnerabilities, applying patches to operating systems or other software, determining a violation of security policy, monitoring and analyzing network traffic, and protecting the host or device against intrusions or viruses. Products and services that help to ensure a secure computing environment create additional management challenges to network and security administrators and architects. In many cases, effective security measures require interactions between the products and services, such as timely updates of security information and content, collection and aggregation of event data, analysis and correlation of related and causal data sets..."
- ASF Specification website
- Alert Standard Format (ASF) Specification Version 2.0 (Preliminary). Reference: DSP0136.
- Exposing ASF Through DMI. (Preliminary Standard). Reference: DSP0131.
- DMTF Security Protection and Management Working Group (SPAM)
- Distributed Management Task Force (DMTF) website
- "DMTF Common Information Model (CIM)."
IEEE ICSG Malware Working Group
The aim of the IEEE ICSG Malware Working Group is "to solve some of the malware related issues the industry faces today. The initial focus has been to establish more intelligent ways of sharing malware samples and the information associated with them in a way that makes the computer security industry more effective... The IEEE Industry Connections Security Group (ICSG) is a group of computer security entities that have come together to work on common goals and industry issues. The key focus is to solve security issues."
On May 24, 2010, the IEEE Standards Association announced the availability of an XML Schema designed to support sharing of information about malware:
"[This XML schema is] designed to facilitate the quick, cost-effective sharing of samples of malware (malicious software such as viruses, worms and spyware) by computer-security organizations. AVG Technologies, McAfee Inc., Microsoft Corp., Panda Security, Sophos, Symantec Corp. and Trend Micro have adopted the flexible ICSG solution as part of their efforts to more quickly deliver the protection that their users most urgently need...
Anti-virus companies, Internet service providers (ISPs), law-enforcement agencies, testing bodies and other organizations may [download] the XML schema for use in sharing malware samples with other bodies with whom they have arranged to exchange information.
According to Jeff Green, ICSG chair and senior vice president of McAfee Labs: "ICSG has provided a much-needed collaborative environment for the computer-security industry to come together quickly and tackle our most pressing issues as they arise. The introduction of an easily adaptable XML schema for sharing malware samples is an important first deliverable, and we have already identified an array of other areas — packer usage, application and cloud-computing security and privilege management — where ICSG can deliver unique value." Vincent Weafer, vice president of Symantec Security Response: 'ICSG's XML schema not only makes the process significantly more efficient, it also enables an organization to prioritize the threats. It all adds up to faster rollout of more relevant protection for our customers'...
ICSG formed in 2009 as a global effort to pool experience and resources in combating the systematic and rapid rise in threats to computer security. Since then, membership has more than doubled, to fifteen (15) organizations. In addition to creating the schema for sharing malware samples, ICSG has begun developing guidelines and definitions for identifying bad or good usage of 'packer' software, which is frequently used for compressing malware for hard-to-detect distribution via executable files. Other areas to be addressed by ICSG include application and cloud-computing security and privilege-management protocols..."
To participate in the IEEE Malware Working Group, the entity with which you are associated (company, organization, etc.) must become a member of Industry Connections Security Group (ICSG)... ICSG is an entity based group and you may join as a company or organization, as examples. It is not individual based. However, some individual subject experts may be invited to participate in the Working Groups... The purpose of working groups under ICSG is to produce consensus approaches or proposals for standards. The group can certainly be used to kick start new standards development projects. For example, you may decide to create a consensus document that you later take to a standard. The key to ICSG and the IEEE Industry Connections program is that it is flexible.
From the FAQ document: "The initial members of ICSG were Microsoft, McAfee, Symantec, Sophos, AVG, and Trend. A number of other individuals have been involved in reviewing the initial document produced by the Malware Working Group, from a variety of companies involved in computer security, including: Websense, Arbor, Support Intelligence, Cisco, Google, Computer Science Lab, SRI International, Immunet, AV-Test, AV-Comparatives, Kaspersky, Avira, Comcast, Team Cymru, SonicWall, Webroot, ShadowServer, VirusBuster, Panda Security, Norman, F-Secure, ESET, G DATA, BFK...
ICSG is a group of computer security entities that have come together to work on common goals and industry issues. The key focus is to solve security issues. In the past few years, attackers have shifted away from mass distribution of a small number of threats to micro distribution of millions of distinct threats. ICSG was established, under the umbrella of the IEEE Standards Association (IEEE-SA) Industry Connections program out of the desire by many in the security industry to pool their experience and resources in response to the systematic and rapid rise in new malware being introduced to the market.
It was recognized that the bad actors have been able to leverage the underground economy to gain economies of scale as well as access to specialist tools and services, whereas the security industry was generally responding to threats as individual entities. While there has been some ad-hoc co-operation in the industry in areas such as malware and phish URL sharing, this co-operation has not been standardized or documented in a format that lends itself to systematic improvement in operational efficiency or visibility and review by people outside the vertical industries..."
References:
- ICSG Malware Working Group
- Malware WG XML Schema
- File listing for Malware WG XML schema (2010-05), from the ZIP package
- IEEE Industry Connections Security Group (ICSG)
- ICSG FAQ document
- "ICSG: Driving Security Standards, Practices, and Industry Co-operation." By Vincent Weafer (Symantec) and Igor Muttik Muttik (McAfee). For the Industry Connections Security Group. 23 pages.
IETF Incident Object Description and Exchange Format (IODEF)
Primary document: Incident Object Description and Exchange Format (IODEF)
"... the free exchange of incident information and statistics among involved parties and the responsible Computer Security Incident Response Teams (CSIRTs) is crucial for both reactionary analysis of current intruder activity and proactive identification of trends that can lead to incident prevention. The purpose of the Incident Handling working group is to define data formats for communication between (a) a CSIRT and its constituency (e.g., users, customers, trusted reporters) which reports system misuse; (b) a CSIRT and parties involved in an incident investigation (e.g., law enforcement, attacking site); and (c) collaborating CSIRTs sharing information. This format will support the now largely human-intensive dimension of the incident handling process. It will represent the product of various incremental data gathering and analysis operations performed by a CSIRT from the time when the system misuse was initially reported (perhaps by an automated system) till ultimate resolution..."
- IETF Extended Incident Handling (INCH) Working Group Charter
- INCH Status Pages
- "The Incident Object Description Exchange Format." By Roman Danyliw (CERT Program Pittsburgh, USA), Jan Meijer (SURFnet bv Utrecht, Netherlands), and Yuri Demchenko (University of Amsterdam Amsterdam, Netherlands). IETF Extended Incident Handling Working Group, Standards Track I-D. April 26, 2007. I-D Tracker citation See also the XML Schema. The "Incident Object Description Exchange Format" specification is an IETF Standards Track I-D produced by members of the IETF Extended Incident Handling Working Group. Organizations require help from other parties to mitigate malicious activity targeting their network and to gain insight into potential threats. This coordination might entail working with an ISP to filter attack traffic, contacting a remote site to take down a bot-network, or sharing watch-lists of known malicious IP addresses in a consortium. The Incident Object Description Exchange Format (IODEF) is a format for representing computer security information commonly exchanged between Computer Security Incident Response Teams (CSIRTs). It provides an XML representation for conveying incident information across administrative domains between parties that have an operational responsibility of remediation or a watch-and-warning over a defined constituency..."
- Incident Handling: Real-Time Inter-Network Defense. IETF Extended Incident Handling Working Group. Internet Draft. 'draft-ietf-inch-rid-01.txt'. October 21, 2004. 63 pages. "Network security incidents such as Denial of Service (DoS), system compromises, worms, and viruses typically result in the loss of service, data, and resources both human and system. Security incidents can be detrimental to the health of the network as a whole. Network Providers (NP) need to be equipped and ready to assist in tracing security incidents with tools and procedures in place before the occurrence of an attack. This paper proposes a proactive inter-network communication method to integrate existing tracing mechanisms across NP boundaries to identify the source(s) of an attack. The various methods implemented to detect and trace attacks must be coordinated on the NPs network as well as provide a communication mechanism across network borders... The communication mechanism described in this paper, Real-time Inter- network Defense (RID), takes into consideration the information needed by various single network trace implementations and the requirement for network providers to decide if a Trace Request should be permitted to continue. The data in RID messages will be represented in an Extensible Markup Language (XML) document and is an extension of the Incident Data Exchange Format (IODEF) model. By following this model, integration with other aspects of the network for incident handling is simplified..."
- "IODEF/RID over SOAP." By Kathleen M. Moriarty and Brian H. Trammell. IETF Internet Draft. June 15, 2006.
- "The Incident Object Description Exchange Format Data Model and XML Implementation." IETF Internet Draft. Reference: 'draft-ietf-inch-iodef-06.txt'. IETF Extended Incident Handling WG. May 18, 2006, expires November 19, 2006.
- The Incident Data Exchange Format Data Model and XML Implementation. Version -02. September 29, 2003.
- Incident Object Description and Exchange Format Data Model and Extensible Markup Language (XML) Document Type Definition
- Incident Object Description and Exchange Format (IODEF)
- Incident Object Description and Exchange Format Requirements. October, 2002.
IETF Intrusion Detection Exchange Format (IDMEF)
"Security incidents are becoming more common and more serious, and intrusion detection systems are becoming of increasing commercial importance. Numerous intrusion detection systems are important in the market and different sites will select different vendors. Since incidents are often distributed over multiple sites, it is likely that different aspects of a single incident will be visible to different systems. Thus it would be advantageous for diverse intrusion detection systems to be able to share data on attacks in progress. The purpose of the Intrusion Detection Working Group is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to management systems which may need to interact with them. The Intrusion Detection Working Group will coordinate its efforts with other IETF Working Groups..."
- IETF Intrusion Detection Exchange Format Working Group
- "The Intrusion Detection Message Exchange Format." IETF Intrusion Detection Exchange Format Working Group. Internet Draft. Reference: 'draft-ietf-idwg-idmef-xml-12'. July 8, 2004.
- The Intrusion Detection Exchange Protocol (IDXP)
- Intrusion Detection Message Exchange Format
OASIS Application Vulnerability Description Language TC (AVDL)
References:
- OASIS Application Vulnerability Description Language TC website.
- AVDL TC list archives
- OASIS Announcement: AVDL Specification Submitted for Approval as an OASIS Standard
- Application Vulnerability Description Language. Committee Draft. 15-March-2004. [source PDF]
- AVDL XML Schema [source]
- Technical Overview of the Application Vulnerability Description Language (AVDL) V1.0. 22-March-2004. [source .DOC, cache]
- "OASIS Committee Draft for the Application Vulnerability Description Language (AVDL)." News story 2004-02-09.
- AVDL XML Schema snapshot. From the source, referenced in the 19-May-2003 posting from Kevin Heineman.
OASIS Web Application Security TC (WAS)
References:
- OASIS TC Call for Participation, Web Application Security
- "OASIS Works to Establish Classification Standards for Web Security Vulnerabilities." Announcement 2003-05-28.
- WAS TC website
- "OASIS to Develop Common Security Language." By Paul Roberts (IDG News Service). In InfoWorld (May 29, 2003).
OpenSec Advisory and Notification Markup Language (ANML)
The Open Security Organization is developing an Advisory and Notification Markup Language (ANML). First in a planned suite of related standards, the Advisory and Notification Markup Language (ANML) "is an XML-based specification for describing advisories and other types of notifications. ANML intends to solve the inconsistent use of terminology by software vendors in their advisories and make it easy for applications to read these advisories. This will make way for the necessary tools to automatically update systems. Although ANML will have its biggest impact for security advisories, it can be used for any type of notification. Some examples include bug-fixes, feature enhancement, upgrade availability, and many more." The developers solicit involvement from interested parties. Other standards planned for development include: (1) System Information Markup Language (SIML) -- an XML-based specification for describing a system's properties and providing a detailed inventory of software, hardware, and configuration information; (2) Software Description Markup Language (SDML) -- an XML-based specification for describing the properties of software and its environment. ANML, SIML, and SDML are designed to form the core of the OpenSec Framework. The OpenSec Framework is a set of guidelines on how to use these technologies to aid system management. The OpenSec goal is to be able to send an SDML file to a web service that will respond with an ANML file. A system manager will compare elements of the ANML file to elements of the SIML file to assess the system and install the necessary updates."
Open Vulnerability Assessment Language (OVAL)
"Open Vulnerability Assessment Language (OVAL) is the common language for security experts to discuss and agree upon technical details about how to check for the presence of a vulnerability on a computer system. The vulnerabilities are identified by OVAL queries, which perform the checks... XML is supported with a core Official OVAL XML Schema that describes the basics of the format, and individual XML-format schemas for each of the OS platforms currently supported by XML."
"After working with the SQL format for over a year, it became clear that tool developers needed a better way to extract data for use in non-SQL applications and OVAL writers need a way to reuse existing components. In May 2003, MITRE instituted a working group to develop an XML specification for OVAL. After a number of revisions and converstations with the OVAL community, we have prepared a final draft of the XML specification of OVAL data. This final draft version was released on December 31st, 2003... There is a core OVAL XML Schema that describes the basics of the format. Individual platforms then have their own XML Schema that describes certain types of tests that can be encoded within an OVAL definition. Platform-specific XML Schemas are in development for Microsoft Windows, Sun Solaris, and Red Hat Linux. These schemas have been posted for comment and review. Also available is an instance document that contains a number of example OVAL definitions in the proposed XML format. ..." [from the OVAL XML spec page]
References:
- OVAL web site
- OVAL FAQ document
- OVAL XML Specification
- OVAL XML Schema
- OVAL XML Format
- "Introduction to OVAL: A New Language to Determine the Presence of Software Vulnerabilities." By Matthew Wojcik, Tiffany Bergeron, Todd Wittbold, and Robert Roberge. November 2003. This white paper introduces the OVAL concept and explains how OVAL improves vulnerability assessment.
- "Open Vulnerability Assessment Language (OVAL)." OVAL Brochure. By Matthew N. Wojcik, Tiffany A. Bergeron, J. Todd Wittbold, and Robert J. Roberge. October 2003. A complete introduction to the OVAL effort, includins graphical representation of OVAL's role in the information security community and of the stages of an OVAL query.
Open Web Application Security Project (OWASP)
The Open Web Application Security Project (OWASP) is an Open Source community project staffed entirely by volunteers from across the world. The project is developing software tools and knowledge based documentation that helps people secure web applications and web services. Much of the work is driven by discussions on the Web Application Security list at SecurityFocus.com. All software and documentation is released under the GNU public licenses." OWASP has published a report detailing the ten most critical web application security problems.
References:
- Open Web Application Security Project (OWASP)
- OWASP software and documentation repository (SourceForge)
- The Ten Most Critical Web Application Security Vulnerabilities. From the Open Web Application Security Project (OWASP). January 2003.
- "A Guide to Building Secure Web Applications. The Open Web Application Security Project." Version 1.1.1. By Mark Curphey, David Endler, William Hau, Steve Taylor, Tim Smith, Alex Russell, Gene McKenna, Richard Parke, Kevin McLaughlin, Nigel Tranter, Amit Klien, Dennis Groves, Izhar By-Gad, Sverre Huseby, Martin Eizner, Martin Eizner, and Roy McNamara. Note: Version 2.0 is planned for release in May/June 2003. [alt URL]
VulnXML Project: A Web Application Security Vulnerability Description Language
"When security researchers publish security advisories or vulnerabilities, they either do so in an ambiguous textual form or using a proprietary data format for use in their tools. This net effect is that security data has become tightly coupled to specific tools and cannot easily be shared across different tools... The VulnXML will create an open standard format for web application security vulnerabilities only. Whilst we believe it could be extended to other classes of security problems, they are beyond the scope of this project... VulnXML aims to make free web application security knowledge available to everyone and anyone at the same time... The VulnXML format will be an open source and openly published standard XML document data type definition from which users can describe a particular security vulnerability in a web application in an unambiguous manner. The DTD will allow the security check developer or security researcher to describe enough meta-data about the vulnerability that an automated program could build an http request or series of requests to determine if the vulnerability exists on the system being tested... [As for] CVE and the Bugtraq databases: The common Vulnerabilities and Exposures (CVE) database and the Bugtraq database do an excellent job of capturing, recording and classifying security vulnerabilities. They are not, however, designed to capture sufficient information about a web application security vulnerability that would enable it to be automatically built into a check that a tool could use. We will be making every effort to reference CVE meta-data of any vulnerability we convert to the VulnXML format and have made provision in the initial data type definition..." [from the VulnXML Project Vision document]
References:
- VulnXML Project website
- Open Web Application Security Project (OWASP)
- "VulnXML Proof of Concept Vision Document." Version 1.1. July 2002. [cache]
- Proposal for a VulnXML web interface (VXWI) [cache]
- VulnXML XML DTD Version 1.2. 2002-11-05. [source]
- VulnXML XML DTD Version 1.1. See also Version 1.0 [cache]
- Sample XML document (buffer overflow) [source]
Vulnerability and Exposure Markup Language (VuXML)
"VuXML is an XML application for documenting security issues in a software package collection such as the FreeBSD Ports Collection or OpenBSD Ports and Packages Collection... VuXML is a document format for describing security issues that affect a software collection. VuXML is NOT a database. The FreeBSD Ports Collection is a collection of software packages — currently over 12,000. The packages are built from the "ports tree." Each "port" is a collection of files that automate building, installation, and packaging the software. Similar collections exist for other operating systems, where terminology varies... Projects documenting issues with VuXML: FreeBSD, OpenBSD..."
References:
- VuXML web site
- VuXML DTD [source]
- "VuXML: Vulnerabilities and Exposures Markup Language" By Jacques Vidrine. Presented at "BSDCan 2005." May 14, 2005. 46 slides. [archive/cache]
- "FreeBSD VuXML." Documenting security issues in FreeBSD and the FreeBSD Ports Collection. Security issues that affect the FreeBSD operating system or applications in the FreeBSD Ports Collection are documented using the Vulnerabilities and Exposures Markup Language (VuXML). Example: drupal — multiple vulnerabilities
- OpenBSD VuXML. Documenting security issues in the OpenBSD Ports & Packages Collection.
- Email contact: Jacques A. Vidrine nectar@FreeBSD.org
General: Articles, Papers, News
[March 08, 2004] "Feds Propose Security Standards." By William Jackson. In Government Computer News Volume 23, Number 5 (March 08, 2004). "Everyone had a different take on standards-based security at the recent RSA Conference 2004. Advocates touted three proposed security standards and a handful of technical specifications. The U.S. Energy Department this spring will launch a Security Incident Response Portal as a prototype of a new standard nomenclature for Web application vulnerabilities. Energy and the Organization for the Advancement of Structured Information Standards (OASIS) are promoting the Application Vulnerability Description Language, or AVDL, an Extensible Markup Language schema for sharing data among multivendor security products. Its developers called it an alternative to the labor-intensive job of eyeballing and rewriting scores of text alerts. The XML-enabled Security Incident Response Portal, at CIAC in Livermore, Calif., will listen for AVDL alerts, process them and automatically pass them on to users... Another federal group, the ID Credentialing Committee, is working on criteria for a common credential useful across the federal government. 'We are going to end the proliferation of stovepipes,' said Judith Spencer, who heads the committee. She said it builds on the experience of the Federal Bridge Certification Authority, which cross-certifies some agencies' digital certificates. The bridge would play a role in the common federal ID, but each agency would issue its own credentials and set access policies..."
[February 23, 2004] "AVDL Integrates Application Security." By Jan Bialkowski and Kevin Heineman. In Network World (February 23, 2004). "Because traditional security tools such as firewalls, VPNs and intrusion-detection systems inadequately protect against application-layer attacks, security managers are turning to next-generation application security products such as vulnerability scanners, application security gateways and patch management systems. However, these best-of-breed stand-alone systems still require individual and separate user interactions, leaving the overall security management process too manual, time-consuming and error-prone. Application Vulnerability Description Language (AVDL) is a new security interoperability standard in development by the Organization for the Advancement of Structured Information Standards. Proposed by leading application security vendors and users, AVDL creates a rich and effective set of consistent XML schema definitions to describe application security properties and vulnerabilities. Using AVDL, security tools and products from different vendors will be able to communicate to coordinate their security operations and automate security management. AVDL integration creates a secure Web application environment that automates mundane security operations, such as patching and reconfiguration, to meet evolving application requirements and security policies. This frees security administrators to focus on higher-level policy analysis. Because all new vulnerability alerts can be described consistently in AVDL, automation of security management also vastly reduces the incident response time, closing critical vulnerability windows and enhancing security posture. AVDL-based security alert bulletins will give users highly efficient access to the collective expertise of all participants in this field, where even the largest organizations are challenged to keep up with rapid industry evolution. The basic concept embodied in the AVDL schema is an application-level transaction, called a probe, which describes HTTP exchanges between browsers and Web application servers. Defined mark-ups allow specification of the HTTP messages in full detail at various levels of abstraction (raw byte stream, or parsed to HTTP header constructs). Such probes might specify valid and expected request-response exchanges between browsers and servers, or might specify application vulnerability exploits..."
[July 30, 2003] "NetContinuum And SPI Dynamics Integrate Attack Prevention And Application Vulnerability Assessment Technologies. First Integration Between Independent Solutions Demonstrates Real-World Benefits of Emerging AVDL Standard for Application Security Interoperability." - "NetContinuum, a leading provider of web and application security solutions, and SPI Dynamics, the expert in web application security assessment, today announced they have completed initial integration between NetContinuum's NC-1000 web security gateway appliance and SPI Dynamics' WebInspect Enterprise Edition application vulnerability assessment software. Integration between the two technologies automates the ongoing security assessment and protection cycle required to fully defend against the growing risk of application-layer security threats, which now comprise up to 70 percent of all new attacks. This interoperability allows organizations to respond more quickly to new threats and dramatically decrease their exposure to attacks and potential downtime. The new integration is based on an expanded XML schema that allows application assessment information discovered by WebInspect to be reported and organized in a way that can be easily read and interpreted by the NC-1000 web security gateway. SPI Dynamics and NetContinuum have submitted the knowledge gained from this integration to the OASIS Application Vulnerability Description Language (AVDL) technical committee for consideration as part of the AVDL 1.0 specification, scheduled for release later this year..."
The Ten Most Critical Web Application Security Vulnerabilities. From the Open Web Application Security Project (OWASP). 27 pages. "The Open Web Application Security Project published a report detailing the ten most critical web application security problems. OWASP is dedicated to helping organizations understand and improve the security of their web applications and web services. These [application-level] flaws are surprisingly common and can be exploited by unsophisticated attackers with easily available tools. When an organization deploys a web application, they invite the world to send HTTP requests. Attacks buried in these requests sail past firewalls, filters, platform hardening, SSL, and IDS without notice because they are inside legal HTTP requests. Therefore, web application code is part of the security perimeter and cannot be ignored.." See also the announcement. [cache, version 2003-01-13]
[April 04, 2003] "Real-Time Safety Combo. SecurityProfiling's Intrusion-Detection System Alerts Managers to Attacks and Remotely Issues Patches" By George V. Hulme. In InformationWeek (March 31, 2003). "With nearly 80 software vulnerabilities reported each week last year, IT security managers spend a big part of their day determining which ones need immediate attention and patching. SecurityProfiling Inc., a developer of security threat-management software, will introduce a product next month to ease that workload. The Intelligent IDS, or intrusion-detection system, is designed to tell managers if their systems are vulnerable to a given attack and remotely issue any needed patches. The system is based on the widely used Snort open-source intrusion-detection system and SecurityProfiling's "logic engine," which is part of its SysUpdate patch-management software. The logic engine analyzes which patches are necessary for the systems a company uses by looking at operating systems, applications, and patches previously installed, as well as company policy..."
[March 24, 2003] "CERT, Feds Consider New Reporting Process." By Dennis Fisher. In eWEEK (March 24, 2003). "Government officials and private organizations alike are reviewing their vulnerability disclosure processes after several incidents over the past 10 days exposed major shortcomings in the way new bugs are handled. The most dramatic case for change came early last week when an anonymous member of a security mailing list posted three unpublished vulnerability advisories. None of the advisories had been released by the authors -- or by a third party such as the CERT Coordination Center -- who typically handle such announcements. The posts were taken from advance copies of the advisories that CERT had shared with a select group of software vendors, something that has angered CERT officials... CERT is now considering whether changes can be made to its process for handling vulnerabilities. The federal government, meanwhile, is discussing ways to centralize vulnerability reporting... The government is considering a plan to establish a single point of contact for vulnerability reporting; researchers would submit discoveries to the contact. The government would then work with the researcher and the affected vendors to coordinate release of the information. The hope is to avoid leaks and to speed vendor response to security problems. However, the Information Assurance and Infrastructure Protection division of the Department of Homeland Security is still without a leader, clogging any major initiatives, insiders said. While the Bush administration has found it difficult to fill the top information security job, sources say Bob Liscouski, director of information integrity and assurance at The Coca-Cola Co., in Atlanta, is slated to take the job of assistant undersecretary for IAIP... The trouble began when a member of the Full-Disclosure mailing list posted three vulnerability reports. Only one of the problems had been disclosed previously, and patches were not yet available. All the advisories detailed the vulnerabilities and affected products. All the vulnerability reports were serious. The first, posted March 15 [2003], warned of a cryptographic weakness in the popular Kerberos protocol. The second message discussed a timing attack on cryptographic keys. The third, posted March 16, concerned a problem in a code library contained in Unix-based software from Sun Microsystems Inc. and other vendors. The Kerberos bulletin was officially released March 17; the details of the timing attack were published on another Web site the previous Friday..."