Jeff Hodges and Barry Leiba (eds), IETF Internet Draft
An updated version of the IETF Informational Internet Draft has beenpublished docmenting "Security Requirements for HTTP." Recent InternetEngineering Steering Group (IESG) practice dictates that IETF protocolsmust specify mandatory-to-implement (MTI) security mechanisms, so thatall conformant implementations share a common baseline. This documentexamines all widely deployed HTTP security technologies, and analyzesthe trade-offs of each. The document examines the effects of applyingsecurity constraints to Web applications, documents the properties thatresult from each method, and will make Best Current Practicerecommendations for HTTP security in a later document version.
Some existing HTTP Security Mechanisms include: Forms And Cookies, HTTPAccess Authentication [Basic Authentication, Digest Authentication,Authentication Using Certificates in TLS, Other Access AuthenticationSchemes, Centrally-Issued Tickets, and Web Services security mechanisms.In addition to using TLS for client and/or server authentication, itis also very commonly used to protect the confidentiality and integrityof the HTTP session. For instance, both HTTP Basic authentication andCookies are often protected against snooping by TLS. It should be notedthat, in that case, TLS does not protect against a breach of thecredential store at the server or against a keylogger or phishinginterface at the client. TLS does not change the fact that BasicAuthentication passwords are reusable and does not address that weakness.
Is is possible that HTTP will be revised in the future. "HTTP/1.1" (RFC2616) and "Use and Interpretation of HTTP Version Numbers" (RFC 2145)define conformance requirements in relation to version numbers. In HTTP1.1, all authentication mechanisms are optional, and no single transportsubstrate is specified. Any HTTP revision that adds a mandatory securitymechanism or transport substrate will have to increment the HTTP versionnumber appropriately. All widely used schemes are non-standard and/orproprietary..."
Sunday, March 14, 2010
Elastic Provisioning in the Cloud: Terracotta and Eucalyptus Integration
"Terracotta recently announced a partnership with open source privatecloud platform vendor Eucalyptus that allows the companies to provisionprivate clouds on the Amazon AWS-compatible Eucalyptus cloud platformand take advantage of the elasticity and flexibility of the cloud.
Eucalyptus is compatible with the Amazon AWS public cloud infrastructureand its design gives users the option of moving applications fromon-premise Eucalyptus clouds to public clouds, and vice versa. It alsosupports 'hybrid' clouds allowing a composite of private (generally usedto store private data) and public (provided by cloud service providersto offer customers the ability to deploy and consume services) cloudresources together to get the benefits of both deployment models. Byaddressing the data layer and to provision elastic cloud resourceswithin internal infrastructure, Eucalyptus and Terracotta integrationgives the organizations a way to build private clouds using commodityhardware and the virtualization technology."
Excerpts from comments of Ari Zilka (Terracotta) and Rich Wolsk(Eucalyptus): "We have both seen the need for the combined feature setwe offer in a number of customer engagements, so working together madea lot of sense. Eucalyptus provides the provisioning and managementframework for building and operating private clouds, and Terracottaensures application data can elastically scale to meet the demands ofthis dynamically configured compute tier. The products are verycomplementary...
Developers using Eucalyptus as a cloud platform can immediately use theTerracotta scaling and caching frameworks to quickly build scalableweb sites and Java applications, and deploy those applications to eitherEucalyptus or to Amazon AWS. Developers already using Terracotta inAmazon's cloud can bring those applications and sites into aEucalyptus-managed an on-premise cloud within their own data center..."
Eucalyptus is compatible with the Amazon AWS public cloud infrastructureand its design gives users the option of moving applications fromon-premise Eucalyptus clouds to public clouds, and vice versa. It alsosupports 'hybrid' clouds allowing a composite of private (generally usedto store private data) and public (provided by cloud service providersto offer customers the ability to deploy and consume services) cloudresources together to get the benefits of both deployment models. Byaddressing the data layer and to provision elastic cloud resourceswithin internal infrastructure, Eucalyptus and Terracotta integrationgives the organizations a way to build private clouds using commodityhardware and the virtualization technology."
Excerpts from comments of Ari Zilka (Terracotta) and Rich Wolsk(Eucalyptus): "We have both seen the need for the combined feature setwe offer in a number of customer engagements, so working together madea lot of sense. Eucalyptus provides the provisioning and managementframework for building and operating private clouds, and Terracottaensures application data can elastically scale to meet the demands ofthis dynamically configured compute tier. The products are verycomplementary...
Developers using Eucalyptus as a cloud platform can immediately use theTerracotta scaling and caching frameworks to quickly build scalableweb sites and Java applications, and deploy those applications to eitherEucalyptus or to Amazon AWS. Developers already using Terracotta inAmazon's cloud can bring those applications and sites into aEucalyptus-managed an on-premise cloud within their own data center..."
Anatomy of an Open Source Cloud: Infrastructure as a Service
Cloud computing is no longer a technology on the cusp of breaking outbut a valuable and important technology that is fundamentally changingthe way we use and develop applications. Volumes could be written aboutthe leadership role that open source is playing in the cloud andvirtualization domain, but this article provided a short introductionto some of the popular and visible solutions available today. Whetheryou're looking to build a cloud based on your own requirements fromindividual pieces or simply want a cohesive solution that works out ofthe box, open source has you covered.
This article begins with an exploration of the core abstractions ofcloud architectures (from Infrastructure as a Service IaaS), thenmoves beyond the building blocks to the more highly integratedsolutions. Although not a requirement, virtualization provides uniquebenefits for building dynamically scalable architectures. In additionto scalability, virtualization introduces the ability to migrate virtualmachines (VMs) between physical servers for the purposes of loadbalancing. The virtualization component is provided by a layer ofsoftware called a hypervisor (sometimes called a virtual machinemonitor - VMM). This layer provides the ability to execute multipleoperating systems (and their applications) simultaneously on a singlephysical machine. On the hypervisor is an object called a virtual machinethat encapsulates the operating system, applications, and configuration.Optionally, device emulation can be provided in the hypervisor or as aVM. Finally, given the new dynamic nature of virtualization and the newcapabilities it provides, new management schemes are needed. Thismanagement is best done in layers, considering local management at theserver, as well as higher-level infrastructure management, providingthe overall orchestration of the virtual environment.
As VMs are an aggregation of operating system, root file system, andconfiguration, the space is ripe for tool development. But to realizethe full potential of VMs and tools, there must be a portable way toassemble them. The current approach, called the Open VirtualizationFormat (OVF) is a VM construction that is flexible, efficient, andportable. OVF wraps a virtual disk image in an XML wrapper that definesthe configuration of the VM, including networking configuration,processor and memory requirements, and a variety of extensible metadatato further define the image and its platform needs. The key capabilityprovided by OVF is the portability to distribute VMs in ahypervisor-agnostic manner..."
This article begins with an exploration of the core abstractions ofcloud architectures (from Infrastructure as a Service IaaS), thenmoves beyond the building blocks to the more highly integratedsolutions. Although not a requirement, virtualization provides uniquebenefits for building dynamically scalable architectures. In additionto scalability, virtualization introduces the ability to migrate virtualmachines (VMs) between physical servers for the purposes of loadbalancing. The virtualization component is provided by a layer ofsoftware called a hypervisor (sometimes called a virtual machinemonitor - VMM). This layer provides the ability to execute multipleoperating systems (and their applications) simultaneously on a singlephysical machine. On the hypervisor is an object called a virtual machinethat encapsulates the operating system, applications, and configuration.Optionally, device emulation can be provided in the hypervisor or as aVM. Finally, given the new dynamic nature of virtualization and the newcapabilities it provides, new management schemes are needed. Thismanagement is best done in layers, considering local management at theserver, as well as higher-level infrastructure management, providingthe overall orchestration of the virtual environment.
As VMs are an aggregation of operating system, root file system, andconfiguration, the space is ripe for tool development. But to realizethe full potential of VMs and tools, there must be a portable way toassemble them. The current approach, called the Open VirtualizationFormat (OVF) is a VM construction that is flexible, efficient, andportable. OVF wraps a virtual disk image in an XML wrapper that definesthe configuration of the VM, including networking configuration,processor and memory requirements, and a variety of extensible metadatato further define the image and its platform needs. The key capabilityprovided by OVF is the portability to distribute VMs in ahypervisor-agnostic manner..."
W3C Launches Decisions and Decision-Making Incubator Group
"W3C is pleased to announce the creation of the Decisions and Decision-Making Incubator Group. The mission of this XG is to determine therequirements, use cases, and a representation of decisions anddecision-making in a collaborative and networked environment suitablefor leading to a potential standard for decision exchange, sharedsituational awareness, and measurement of the speed, effectiveness,and human factors of decision-making. Incubator Activity work is noton the W3C standards track but in many cases serves as a starting pointfor a future Working Group. The following W3C Members have sponsoredthe charter for this group: DISA, MITRE, and CNR. Jeff Waters and DonMcGarry are the initial Decisions and Decision-Making Incubator Groupco-Chairs.
Background: "Everyone makes important decisions in the dailyaccomplishment of their duties. The aggregate of these decisionsconstitutes the current state of their organization, and charts thecourse for our future direction and progress. In a sense, ourdecisions represent individuals and the organizations they represent.The effective representation, management, evaluation, and sharing ofthese decisions determines the success of the enterprise. Especiallyin a distributed, self-organizing, networked environment where digitalmedia are the main interaction between members, distribution andtracking of decisions is particularly important for understandingwhat others are doing. Our decisions serve as information-work products;both as inputs and outputs. We use others decisions as references andour decisions become references to the decision process of others.The significant time and effort we spend converting our decisionsinto work products such as briefs, papers, proposals, and communicationof our decisions in meetings, teleconferences, conversations, andemails, could be recaptured if we had a standard concise format forrepresenting and sharing our decisions.
For these reasons, the members of the Decisions and Decision-MakingIncubator are exploring and determining the requirements, use cases,and a potential standard format for representing our decisionsefficiently and effectively in a collaborative networked environmentfor the purpose of information exchange for situational awareness.The Emergency Data Exchange Language Common Alerting Protocol (EDXL-CAP)family of standards is an example of the type and style of informationexchange formats which are simple, useful, and understandable. WhatEDXL-CAP did for alerts, a common decision exchange protocol shoulddo for decisions. However, to reach its full potential, the proposeddecision format must be extended by the Semantic Web tools andstandards to provide semantic interoperability and to provide a basisfor reasoning that can ease development of advanced applications.Simplicity and understandability of decisions is particularly importantin distributed, dynamic settings such as emergency management.
The group will maintain a wiki site containing relevant information.The deliverables will be a final report, a potential standard ontology,examples, and potentially prototype tools using the ontology. Thevision of the final report outline includes: introduction, backgroundand need, scope, use cases, requirements, issues and challenges,ontological patterns & solutions, sample decision ontology, representationformats, examples, candidate tools for instrumentation, examples,recommendations, and conclusion. In case the group decides that aparticular technology is ripe for further standardization at the W3C,the group will consider preparing a W3C member submission and/or proposea W3C group charter to be considered by the W3C.
Background: "Everyone makes important decisions in the dailyaccomplishment of their duties. The aggregate of these decisionsconstitutes the current state of their organization, and charts thecourse for our future direction and progress. In a sense, ourdecisions represent individuals and the organizations they represent.The effective representation, management, evaluation, and sharing ofthese decisions determines the success of the enterprise. Especiallyin a distributed, self-organizing, networked environment where digitalmedia are the main interaction between members, distribution andtracking of decisions is particularly important for understandingwhat others are doing. Our decisions serve as information-work products;both as inputs and outputs. We use others decisions as references andour decisions become references to the decision process of others.The significant time and effort we spend converting our decisionsinto work products such as briefs, papers, proposals, and communicationof our decisions in meetings, teleconferences, conversations, andemails, could be recaptured if we had a standard concise format forrepresenting and sharing our decisions.
For these reasons, the members of the Decisions and Decision-MakingIncubator are exploring and determining the requirements, use cases,and a potential standard format for representing our decisionsefficiently and effectively in a collaborative networked environmentfor the purpose of information exchange for situational awareness.The Emergency Data Exchange Language Common Alerting Protocol (EDXL-CAP)family of standards is an example of the type and style of informationexchange formats which are simple, useful, and understandable. WhatEDXL-CAP did for alerts, a common decision exchange protocol shoulddo for decisions. However, to reach its full potential, the proposeddecision format must be extended by the Semantic Web tools andstandards to provide semantic interoperability and to provide a basisfor reasoning that can ease development of advanced applications.Simplicity and understandability of decisions is particularly importantin distributed, dynamic settings such as emergency management.
The group will maintain a wiki site containing relevant information.The deliverables will be a final report, a potential standard ontology,examples, and potentially prototype tools using the ontology. Thevision of the final report outline includes: introduction, backgroundand need, scope, use cases, requirements, issues and challenges,ontological patterns & solutions, sample decision ontology, representationformats, examples, candidate tools for instrumentation, examples,recommendations, and conclusion. In case the group decides that aparticular technology is ripe for further standardization at the W3C,the group will consider preparing a W3C member submission and/or proposea W3C group charter to be considered by the W3C.
Friday, March 12, 2010
OGC Announces Earth Observation Profile for Web-based Catalogue Services
Open Geospatial Consortium Announcement
The Open Geospatial Consortium has announced adoption and availability
of the "OGC Catalogue Services Standard Extension Package for ebRIM
Application Profile: Earth Observation Products", and also the related
"Geography Markup Language (GML) Application Schema for EO Products."
Together, these standards, when implemented, will enable more efficient
data publishing and discovery for a wide range of stakeholders who
provide and use data generated by satellite-borne and aerial radar,
optical and atmospheric sensors.
The OASIS standard ebRIM (Electronic business Registry Information Model)
is the preferred cataloguing metamodel foundation for application
profiles of the OpenGIS Catalogue Service Web (CS-W) Standard. The CS-W
ebRIM EO standard describes a set of interfaces, bindings and encodings
to be implemented in catalog servers so that data providers can publish
descriptive information (metadata) about Earth Observation data. Developers
can also implement this standard as part of Web clients that will enable
data users and their applications to very efficiently search and exploit
these collections of Earth Observation data.
"OGC Catalogue Services Standard 2.0 Extension Package for ebRIM
Application Profile: Earth Observation Products" (OGC 06-131r6) is an
OGC Implementation Standard of subtype Application Profile. This
application profile standard "describes the interfaces, bindings and
encodings required to discover, search and present metadata from
catalogues of Earth Observation products. The profile presents a
minimum specification for catalogue interoperability within the EO
domain, with extensions for specific classes of data. It enables
CSW-ebRIM catalogues to handle a variety of metadata pertaining to
earth observation, like EO Products... EO data product collections
are usually structured to describe data products derived from a single
sensor onboard a satellite or series of satellites. Products from
different classes of sensors usually require specific product metadata.
The following classes of products have been identified so far: radar,
optical, atmospheric."
"OpenGIS Geography Markup Language (GML) Application Schema for Earth
Observation Products" (0GC 06-080r4) is an OGC Implementation Standard
of subtype GML Application Schema. It "describes the encodings required
to describe Earth Observation (EO) products from general to mission
specific characteristics. The approach consists in modelling EO data
product through a GML application schema.ISO definitions are
specified for attributes where available, although not the full ISO
schema is used for the structural definitions, which would lead to a
less efficient overall structure. The general mechanism is to create
a schema with a dedicated namespace for each level of specificity
from a general description which is common to each EO Product to a
restricted description for specific mission EO Product. Each level
of specificity is an extension of the previous one..."
The Open Geospatial Consortium has announced adoption and availability
of the "OGC Catalogue Services Standard Extension Package for ebRIM
Application Profile: Earth Observation Products", and also the related
"Geography Markup Language (GML) Application Schema for EO Products."
Together, these standards, when implemented, will enable more efficient
data publishing and discovery for a wide range of stakeholders who
provide and use data generated by satellite-borne and aerial radar,
optical and atmospheric sensors.
The OASIS standard ebRIM (Electronic business Registry Information Model)
is the preferred cataloguing metamodel foundation for application
profiles of the OpenGIS Catalogue Service Web (CS-W) Standard. The CS-W
ebRIM EO standard describes a set of interfaces, bindings and encodings
to be implemented in catalog servers so that data providers can publish
descriptive information (metadata) about Earth Observation data. Developers
can also implement this standard as part of Web clients that will enable
data users and their applications to very efficiently search and exploit
these collections of Earth Observation data.
"OGC Catalogue Services Standard 2.0 Extension Package for ebRIM
Application Profile: Earth Observation Products" (OGC 06-131r6) is an
OGC Implementation Standard of subtype Application Profile. This
application profile standard "describes the interfaces, bindings and
encodings required to discover, search and present metadata from
catalogues of Earth Observation products. The profile presents a
minimum specification for catalogue interoperability within the EO
domain, with extensions for specific classes of data. It enables
CSW-ebRIM catalogues to handle a variety of metadata pertaining to
earth observation, like EO Products... EO data product collections
are usually structured to describe data products derived from a single
sensor onboard a satellite or series of satellites. Products from
different classes of sensors usually require specific product metadata.
The following classes of products have been identified so far: radar,
optical, atmospheric."
"OpenGIS Geography Markup Language (GML) Application Schema for Earth
Observation Products" (0GC 06-080r4) is an OGC Implementation Standard
of subtype GML Application Schema. It "describes the encodings required
to describe Earth Observation (EO) products from general to mission
specific characteristics. The approach consists in modelling EO data
product through a GML application schema.ISO definitions are
specified for attributes where available, although not the full ISO
schema is used for the structural definitions, which would lead to a
less efficient overall structure. The general mechanism is to create
a schema with a dedicated namespace for each level of specificity
from a general description which is common to each EO Product to a
restricted description for specific mission EO Product. Each level
of specificity is an extension of the previous one..."
IETF Publishes xCal: The XML Format for iCalendar
Cyrus Daboo, Mike Douglass, and Steven Lees (eds), IETF Internet Draft
An IETF Internet Draft previously published under the title "iCalendar
XML Representation" has been revised and issued under the new title
"xCal: The XML Format for iCalendar." An added Section 5 (Handling
Link Elements in XML and iCal) now recommends a preferred format for
links in xCal documents, specifies an iCalendar extension for including
links in iCalendar documents, and describes how to convert between the
two formats.
"The iCalendar data format defined in IETF RFC 5545 is a widely deployed
interchange format for calendaring and scheduling data. While many
applications and services consume and generate calendar data, iCalendar
is a specialized format that requires its own parser/generator. In
contrast, XML-based formats are widely used for interoperability between
applications, and the many tools that generate, parse, and manipulate
XML make it easier to work with than iCalendar.
The purpose of this specification is to define 'xCal', an XML format
that allows iCalendar data to be converted to XML, and then back to
iCalendar, without losing any semantic meaning in the data. Anyone
creating XML calendar data according to this specification will know
that their data can be converted to a valid iCalendar representation
as well. Two key design considerations are: (1) Round-tripping
(converting an iCalendar instance to XML and back) will give the same
result as the starting point. (2) Preserving the semantics of the
iCalendar data. While a simple consumer can easily browse the calendar
data in XML, a full understanding of iCalendar is still required in
order to modify and/or fully comprehend the calendar data.
Handling Link Elements in XML and iCal: Both Atom (RFC 4287) and HTML
use a link element to reference external information which is related
in some way to the referencing document. iCalendar (RFC 5545) does not
have such a mechanism. There are several common use cases where it would
be useful for a calendar item to link to external structured data. For
instance, it would be useful for an event item to denote the location
of the event by referencing a vCard. Similarly, there may be a primary
contact person for the event, and that person's vCard should be linked
from the event as well. It is recommended therefore that calendar data
in the xCal format use the Atom link element, as specified in RFC 5545
section 4.2.7, for linking to external related resources. The Relation
Name 'location' designates a location for the referencing item. Typically
the location will be in the form of a vCard, but it could be some other
kind of document containing location information... A LINK extension
property for iCalendar is used to reference external documents related
to this calendar item. The property can appear on any iCalendar component,
and the value of this property is a URI which references an external
resource related to the component. Since the LINK parameter is specified
in terms of the link element defined by RFC 5545, converting between
the two is straightforward. When converting from iCalendar to xCal,
simply take any parameters present and assign their values to the
corresponding attribute on the link element. Any unknown extensions
either in the iCalendar or xCal format MAY be ignored when converting
to the other format..." More Detail
An IETF Internet Draft previously published under the title "iCalendar
XML Representation" has been revised and issued under the new title
"xCal: The XML Format for iCalendar." An added Section 5 (Handling
Link Elements in XML and iCal) now recommends a preferred format for
links in xCal documents, specifies an iCalendar extension for including
links in iCalendar documents, and describes how to convert between the
two formats.
"The iCalendar data format defined in IETF RFC 5545 is a widely deployed
interchange format for calendaring and scheduling data. While many
applications and services consume and generate calendar data, iCalendar
is a specialized format that requires its own parser/generator. In
contrast, XML-based formats are widely used for interoperability between
applications, and the many tools that generate, parse, and manipulate
XML make it easier to work with than iCalendar.
The purpose of this specification is to define 'xCal', an XML format
that allows iCalendar data to be converted to XML, and then back to
iCalendar, without losing any semantic meaning in the data. Anyone
creating XML calendar data according to this specification will know
that their data can be converted to a valid iCalendar representation
as well. Two key design considerations are: (1) Round-tripping
(converting an iCalendar instance to XML and back) will give the same
result as the starting point. (2) Preserving the semantics of the
iCalendar data. While a simple consumer can easily browse the calendar
data in XML, a full understanding of iCalendar is still required in
order to modify and/or fully comprehend the calendar data.
Handling Link Elements in XML and iCal: Both Atom (RFC 4287) and HTML
use a link element to reference external information which is related
in some way to the referencing document. iCalendar (RFC 5545) does not
have such a mechanism. There are several common use cases where it would
be useful for a calendar item to link to external structured data. For
instance, it would be useful for an event item to denote the location
of the event by referencing a vCard. Similarly, there may be a primary
contact person for the event, and that person's vCard should be linked
from the event as well. It is recommended therefore that calendar data
in the xCal format use the Atom link element, as specified in RFC 5545
section 4.2.7, for linking to external related resources. The Relation
Name 'location' designates a location for the referencing item. Typically
the location will be in the form of a vCard, but it could be some other
kind of document containing location information... A LINK extension
property for iCalendar is used to reference external documents related
to this calendar item. The property can appear on any iCalendar component,
and the value of this property is a URI which references an external
resource related to the component. Since the LINK parameter is specified
in terms of the link element defined by RFC 5545, converting between
the two is straightforward. When converting from iCalendar to xCal,
simply take any parameters present and assign their values to the
corresponding attribute on the link element. Any unknown extensions
either in the iCalendar or xCal format MAY be ignored when converting
to the other format..." More Detail
NIST Publishes Open Vulnerability and Assessment Language (OVAL)
John Banghart, Stephen Quinn, David Waltermire (eds), NIST Report
An announcement from Pat O'Reilly of NIST's Computer Security Division
reports on the publication of a Draft NIST Interagency Report (IR)
7669: "Open Vulnerability and Assessment Language (OVAL) Validation
Program Test Requirements." The report defines the requirements and
associated test procedures necessary for products to achieve one or
more Open Vulnerability and Assessment Language (OVAL) Validations.
Validation is awarded based on testing a defined set of OVAL
capabilities by independent laboratories that have been accredited
for OVAL testing by the NIST National Voluntary Laboratory
Accreditation Program (NVLAP).
Open Vulnerability and Assessment Language (OVAL) is an information
security community standard to promote open and publicly available
security content, and to standardize the transfer of this information
across security tools and services. The OVAL Language is an XML
specification for exchanging technical details on how to check systems
for security-related software flaws, configuration issues, and patches.
The OVAL Language standardizes the three main steps of the assessment
process: representing configuration information of systems for testing;
analyzing the system for the presence of the specified machine state
(vulnerability, configuration, patch state, etc.); and reporting the
results of the assessment. In this way, OVAL enables open and publicly
available security content and standardizes the transfer of this content
across the entire spectrum of information security tools and services.
OVAL is maintained by the MITRE Corporation...
The NIST OVAL Validation Program is designed to test the ability of
products to use the features and functionality defined in the OVAL
Language. An information technology (IT) product vendor can obtain
one or more OVAL Validations for a product. These validations are
based on the test requirements defined in this document, which cover
four distinct but related validations based on product functionality..." more detail
An announcement from Pat O'Reilly of NIST's Computer Security Division
reports on the publication of a Draft NIST Interagency Report (IR)
7669: "Open Vulnerability and Assessment Language (OVAL) Validation
Program Test Requirements." The report defines the requirements and
associated test procedures necessary for products to achieve one or
more Open Vulnerability and Assessment Language (OVAL) Validations.
Validation is awarded based on testing a defined set of OVAL
capabilities by independent laboratories that have been accredited
for OVAL testing by the NIST National Voluntary Laboratory
Accreditation Program (NVLAP).
Open Vulnerability and Assessment Language (OVAL) is an information
security community standard to promote open and publicly available
security content, and to standardize the transfer of this information
across security tools and services. The OVAL Language is an XML
specification for exchanging technical details on how to check systems
for security-related software flaws, configuration issues, and patches.
The OVAL Language standardizes the three main steps of the assessment
process: representing configuration information of systems for testing;
analyzing the system for the presence of the specified machine state
(vulnerability, configuration, patch state, etc.); and reporting the
results of the assessment. In this way, OVAL enables open and publicly
available security content and standardizes the transfer of this content
across the entire spectrum of information security tools and services.
OVAL is maintained by the MITRE Corporation...
The NIST OVAL Validation Program is designed to test the ability of
products to use the features and functionality defined in the OVAL
Language. An information technology (IT) product vendor can obtain
one or more OVAL Validations for a product. These validations are
based on the test requirements defined in this document, which cover
four distinct but related validations based on product functionality..." more detail
Subscribe to:
Posts (Atom)