The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Last modified: May 24, 2010
Application Security Standards

Contents

[In preparation. References to application security vulnerabilities and incidents.]

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

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:

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

OASIS Application Vulnerability Description Language TC (AVDL)

[April 29, 2004]   OASIS TC Approves Application Vulnerability Description Language (AVDL) Draft.    The OASIS Application Vulnerability Description Language TC has approved a Committee Draft of its version 1.0 specification and has submitted it for consideration as an OASIS Standard. The AVDL specification defines "a standard XML format that allows entities (such as applications, organizations, or institutes) to communicate information regarding web application vulnerabilities. The OASIS AVDL Technical Committee was formed to create an XML definition for exchanging information about the security vulnerabilities of applications exposed to networks. For example, the owners of an application use an assessment tool to determine if their application is vulnerable to various types of malicious attacks. The assessment tool records and catalogues detected vulnerabilities in an XML file in AVDL format. An application security gateway then uses the AVDL information to recommend the optimal attack prevention policy for the protected application. In addition, a remediation product uses the same AVDL file to suggest the best course of action for correcting the security issues. Finally a reporting tool uses the AVDL file to correlate event logs with areas of known vulnerability." According to a declaration presented by the AVDL TC Chairs, some features of the AVDL specification design were inspired by Mitre's Open Vulnerability Assessment Language (OVAL), which uses the Common Vulnerabilities and Exposures (CVE) database. Related technical work is being done within the OASIS Web Application Security TC based upon Application Security Attack Components (ASAC) and VulnXML, developed by the Open Web Application Security Project (OWASP). Application Vulnerability Description Language version 1.0 Committee Draft will be balloted to the OASIS membership during the period May 16-31, 2004.

[April 02, 2003]   OASIS Forms TC for Application Vulnerability Description Language (AVDL).    Representatives from OASIS member companies Citadel Security Software, Inc., NetContinuum, Inc., and SPI Dynamics are forming a technical committee to "develop an Application Vulnerability Description Language (AVDL). The TC's goal is to create an XML definition for exchange of information relating to security vulnerabilities of applications exposed to networks. The AVDL TC will focus on defining a schema that enables easy communication concerning security vulnerabilities between any of the various security entities that address Hypertext Transfer Protocol (HTTP 1.0 and HTTP 1.1) application-level protocol security. AVDL will describe attacks and vulnerabilities that use HTTP as a generic protocol for communication between clients and proxies/gateways to other Internet systems and hosts. Security entities that might utilize AVDL include but are not limited to: vulnerability assessment tools, application security gateways, reporting tools, correlation systems, remediation tools, etc." The TC Co-Chairs are Jan Bialkowski (NetContinuum, Inc) and Kevin Heineman (SPI Dynamics, Inc). The first meeting of the TC will be held 15-May-2003 by phone conference call.

References:

OASIS Web Application Security TC (WAS)

[May 13, 2003]   OASIS Members Form Web Application Security Technical Committee.    A newly formed OASIS Web Application Security Technical Committee will attempt to unite industry consensus and provide standards for classifying and responding to web security vulnerabilities. The specifications are designed to benefit both vendors and users. The TC will leverage and extend the work of the Open Web Application Security (OWASP) VulnXML project that has been established for over a year. The existing VulnXML work is being contributed to OASIS as part of the new TC proposal. According to the proposed charter, the WAS-XML technical committee will produce: (1) a classification scheme for web security vulnerabilities; (2) a model to provide guidance for initial threat, impact and therefore risk ratings; (3) an XML schema to describe web security conditions that can be used by both assessment and protection tools. The TC Chair is Mark Curphey. The first meeting of the technical committee will be held as a conference call on July 03, 2003.

References:

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:

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:

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]

[May 13, 2003]   OASIS Members Form Web Application Security Technical Committee.    A newly formed OASIS Web Application Security Technical Committee will attempt to unite industry consensus and provide standards for classifying and responding to web security vulnerabilities. The specifications are designed to benefit both vendors and users. The TC will leverage and extend the work of the Open Web Application Security (OWASP) VulnXML project that has been established for over a year. The existing VulnXML work is being contributed to OASIS as part of the new TC proposal. According to the proposed charter, the WAS-XML technical committee will produce: (1) a classification scheme for web security vulnerabilities; (2) a model to provide guidance for initial threat, impact and therefore risk ratings; (3) an XML schema to describe web security conditions that can be used by both assessment and protection tools. The TC Chair is Mark Curphey. The first meeting of the technical committee will be held as a conference call on July 03, 2003.

References:

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:

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..."
Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI: http://xml.coverpages.org/appSecurity.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org