Cybersecurity

Cloud Customer Architecture for Securing Workloads on Cloud Services was written as practical reference to help IT architects and IT security professionals architect, install, and operate the information security components of solutions built using cloud services.
 
Many cloud services are now available covering infrastructure, platform and application capabilities. Building business solutions using these cloud services requires a clear understanding of the available security services, components and options, allied to a clear architecture which provides for the complete lifecycle of the solutions, covering development, deployment and operations.
 
This paper introduces best practices for architecting the security of cloud service solutions.

As data is increasingly accessed and shared across geographic boundaries, a growing web of conflicting laws and regulations dictate where data can be transferred, stored, and shared, and how it is protected. The Object Management Group® (OMG®) and the Cloud Standards Customer Council™ (CSCC™) completed a significant effort to analyze and document the challenges posed by data residency.
 
This discussion paper defines data residency as:
 
“...the set of issues and practices related to the location of data and metadata, the movement of (meta)data across geographies and jurisdictions, and the protection of that (meta)data against unintended access and other location-related risks.”
 
This paper covers issues and risks, laws and regulations, applicable and related standards.

This Technical Specification is for the production of conformity evidence for FDP-FDP ground-based system interoperability which has to be declared by the Air Navigation Service Provider (ANSP) before putting FDP-systems into service. This Technical Specification defines the Technical, Operational and Maintenance requirements for Flight Data Processing (ATC-ATC) system interoperability.
Flight Data Processing (FDP) interoperability between ATC units is a key element to facilitate and harmonise Flight Data systems data exchanges and critical to the functioning of a harmonised European Air Traffic Management system. FDP Interoperability can be achieved by the use of different techniques appropriate to the operational need, e.g. message exchange, replication mechanisms and data sharing.
The architectural framework in which the different actors have to inter-operate is of major importance to define the context in which the European Standards have to be developed.

ISO 15118-8:2018 specifies the requirements of the physical and data link layer of a wireless High Level Communication (HLC) between Electric Vehicles (EV) and the Electric Vehicle Supply Equipment (EVSE). The wireless communication technology is used as an alternative to the wired communication technology as defined in ISO 15118‑3.
It covers the overall information exchange between all actors involved in the electrical energy exchange. ISO 15118 (all parts) are applicable for conductive charging as well as Wireless Power Transfer (WPT). For conductive charging, only EVSEs compliant with "IEC 61851‑1 modes 3 and 4" and supporting HLC are covered by this document. For WPT, charging sites according to IEC 61980 (all parts) and vehicles according to ISO/PAS 19363 are covered by this document.

ISO 15118-5:2018 specifies conformance tests in the form of an Abstract Test Suite (ATS) for a System Under Test (SUT) implementing an Electric Vehicle or Supply Equipment Communication Controller (EVCC or SECC) with support for PLC-based High Level Communication (HLC) and Basic Signaling according to ISO 15118‑3. These conformance tests specify the testing of capabilities and behaviors of an SUT, as well as checking what is observed against the conformance requirements specified in ISO 15118‑3 and against what the implementer states the SUT implementation's capabilities are.
The capability tests within the ATS check that the observable capabilities of the SUT are in accordance with the static conformance requirements defined in ISO 15118‑3. The behavior tests of the ATS examine an implementation as thoroughly as is practical over the full range of dynamic conformance requirements defined in ISO 15118‑3 and within the capabilities of the SUT (see NOTE 1). A test architecture is described in correspondence to the ATS. The conformance test cases in this part of the standard are described leveraging this test architecture and are specified in TTCN-3 Core Language for the ISO/OSI Physical and Data Link Layers (Layers 1 and 2). The conformance test cases for the ISO/OSI Network Layer (Layer 3) and above are described in ISO 15118‑4.

ISO 15118-4:2018 specifies conformance tests in the form of an Abstract Test Suite (ATS) for a System Under Test (SUT) implementing an EVCC or SECC according to ISO 15118-2.
These conformance tests specify the testing of capabilities and behaviors of an SUT as well as checking what is observed against the conformance requirements specified in ISO 15118-2 and against what the supplier states the SUT implementation's capabilities are. The capability tests within the ATS check that the observable capabilities of the SUT are in accordance with the static conformance requirements defined in ISO 15118-2. The behavior tests of the ATS examine an implementation as thoroughly as is practical over the full range of dynamic conformance requirements defined in ISO 15118-2 and within the capabilities of the SUT (see NOTE). A test architecture is described in correspondence to the ATS. The conformance test cases in this document are described leveraging this test architecture and are specified in TTCN-3 Core Language for ISO/OSI Network Layer (Layer 3) and above. The conformance test cases for the Data Link Layer (Layer 2) and Physical Layer (Layer 1) are described in ISO 15118-5. Test cases with overlapping scopes are explicitly detailed.

ISO 15118-3:2015 specifies the requirements of the physical and data link layer for a high-level communication, directly between battery electric vehicles (BEV) or plug-in hybrid electric vehicles (PHEV), termed as EV (electric vehicle) [ISO-1], based on a wired communication technology and the fixed electrical charging installation [Electric Vehicle Supply Equipment (EVSE)] used in addition to the basic signalling, as defined in [IEC-1].
It covers the overall information exchange between all actors involved in the electrical energy exchange. ISO 15118 (all parts) is applicable for manually connected conductive charging. Only "[IEC-1] modes 3 and 4" EVSEs, with a high-level communication module, are covered by this part of ISO 15118.

The OASIS CSAF Technical Committee is chartered to make a major revision to the Common Vulnerability Reporting Framework (CVRF) under a new name for the framework that reflects the primary purpose: a Common Security Advisory Framework (CSAF). TC deliverables are designed standardize existing practice in structured machine-readable vulnerability-related advisories and further refine those standards over time.

The OASIS XSPA TC works to standardize the way healthcare providers, hospitals, pharmacies, and insurance companies exchange privacy policies, consent directives, and authorizations within and between healthcare organizations. The OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) Technical Committee will specify healthcare profiles of existing OASIS standards to support reliable, auditable methods of confirming personal identity, official authorization status, and role attributes. This work aligns with security specifications being developed within the U.S. Healthcare Information Technology Standards Panel (HITSP).

The Web of Things seeks to counter the fragmentation of the IoT through standard complementing building blocks (e.g., metadata and APIs) that enable easy integration across IoT platforms and application domains.
 
Thing Description:
 
Semantic vocabularies for describing the data and interaction models exposed to applications, the choice of communications patterns provided by protocols, and serialization formats suitable for processing on resource-constrained devices and transmission over constrained networks.
 
Scripting API:
 
Platform-independent application-facing API for Thing-to-Thing interaction and Thing lifecycle management.
 
Binding Templates:
 
Example mappings from the abstract messages to specific common platforms and protocols in collaboration with the corresponding organizations.
 
Security and Privacy:
 
Cross-cutting policies and mechanisms integrated into the other building blocks to describe and implement security and privacy policies to enable secure and safe interaction across different IoT platforms.
 
Of these, the first deliverable, the normative Thing Description standard, is central, with the other items playing supporting roles. The Scripting API is also normative but simply serves to provide a standardized and convenient way to access the functionality of the Thing Description from a programming language in order to build concrete applications. Binding Templates are informational and provide mappings to concrete protocols. This deliverable also provides templates for describing further protocol mappings through the Thing Description. The Security and Privacy deliverable is normative, but while considered separately, its implementation is integrated into the other deliverables.

The mission of the Web Payments Working Group is to make payments easier and more secure on the Web. The group seeks to:

• streamline checkout by making it easier for users to return stored credentials and other information, and by creating a consistent experience across Web sites, browsers, and operating systems. These improvements should help reduce the percentage of transactions abandoned prior to completion ("shopping cart abandonment") by improving consumer confidence in the payment experience;
• improve payment security by fostering digital payment method innovation on the Web;
• simplify and lower the cost of creating effective Web checkout experiences;

Under its charter, the Working Group defines Recommendations that allow for a payment to be initiated within a Web site or application.

The Working Group will continue to advance these existing specifications to Recommendation:

• Payment Request API, which standardizes an API to allow merchants (i.e., Web sites selling physical or digital goods) to utilize one or more payment methods with minimal integration. User agents (e.g., browsers) facilitate the payment flow between merchant and user, mediating the user experience and providing consistency between different merchants and providers.
• Payment Method Identifiers, which defines the validation and (where applicable) registration of identifiers used for matching purposes by other W3C payments specifications.
• Payment Handler API, which defines capabilities that enable Web applications to handle payment requests. The specification defines how payment apps register their capabilities with the user agent, how the user agent communicates with them, and what information is exchanged.
• Payment Method Manifest, which allows the curators of a defined payment method or owners of a proprietary payment method to authorize (via a manifest file) which payment apps may be used to fulfill the payment method. The scope of this work extends to all types of payment apps, including native mobile apps and Web apps.

The Working Group will continue to develop the following payment method specification, intended to become a Working Group Note:

• Basic Card Payment, which specifies request and response data for making simple card payments with Payment Request API.

The Working Group will also look at enabling re-use of the Payment Request API data model in out-of-browser payments. One approach may be to define the model in a binding- and encoding-neutral way. For early work on this topic, see HTTP Messages 1.0.

The mission of the Web Performance Working Group is to provide methods to measure aspects of application performance of user agent features and APIs.
 
Web developers are building sophisticated applications where application performance is a critical feature. Web developers want the ability to observe the performance characteristics of their applications, and they want the ability to write more efficient applications, using well-defined interoperable methods. Their methods must be both secure and privacy-enabling by design, using well-defined interoperable methods that conform to the current Web browser security model.
 
The Web Performance Working Group's scope of work includes user agent features and APIs to observe and improve aspects of application performance, such as measuring network and rendering performance, responsiveness and interactivity, memory and CPU use, application failures, and similar APIs and infrastructure to enable measurement and delivery of better user experience. Such deliverables will apply to desktop and mobile browsers and other non-browser environments where appropriate, and will be consistent with Web technologies designed in other working groups including HTML, CSS, Web Application Security, Web Platform, Device and Sensors, and SVG.
 
In addition to developing Recommendation Track documents, the Web Performance Working Group may provide review of specifications from other Working Groups.