1. Cybersecurity Users Council: Inter Standards Dimension
In addition to consuming individual cybersecurity standards, the Cybersecurity User’s perspective includes a broader set of both challenges and opportunities. This broader perspective could substantially enhance our feedback to the TCs and help to reduce security portfolio balkanization (fragmentation?).
This material identifies a few motivating examples for consideration.

2. Dimension: The Intersection Between Individual CyberSecurity standards.
Multiple TC Standards intersect in detection, response, orchestration, provisioning, … . Security standards (& technologies) should work together across the security technologies & lifecycle. (Note: Standards like Open DXL may enable these kinds of use cases)
Correlation: Alerts, logs, …correlated across security technologies - CEC
Analytics: Security analytics across standards - regression, ML, modeling
Orchestration: Security technologies operating together systemically – (e.g. detect at the WAF, ramp logging, block at the upstream FW, …)
Provisioning: Considering security semantics across deployment topology/security architecture.
Possible CUC Product: Validated crosscutting use cases, challenges, opportunities to the relevant TCs.

3. Dimension: The Intersection Between CyberSecurity Standards and Platform/App Context
Usage of TC standards may be able to advantage of provisioning context (intended application/service behaviors), orchestration context (expected platform behaviors) and realized topology (structural architecture , as built) … . Security technologies should leverage context established in the platform and application lifcycles.
API: API Management frameworks (MuleSoft, ApiGee, Boomi, …) capture intended inter App interaction. Should inform WAFish, gateway and access broker policy. More important with growth in microservice, IoT, and distributed architectures. Behavior captured in RAML, Swagger, API Blueprints, …
Platform: Platform orchestration (scale out, load balancing, workload migration, failover, ECMP, PBR, … all leave a normal “behavioral footprint in logs, alerts, and forensics).
Design/deployment: Containers, Kubernetes Orchestration, TOSCA (or TOGAF, SABSA, …) Graphs, … all provide security relevant structural intent that has compelling value across detection, response and remediation phases.
Possible CUC Product: Validated context enabled use cases, challenges, and opportunities.

4. Dimension: The Intersection Between CyberSecurity Standards and Risk/Audit/Attestation/Argumentation Standards
Security centric context can also very useful, bring the layers of governance, audit, attestation, … even security argumentation (future).
Risk: Risk mapping standards have proven very useful in security management for critical infrastructure (ref. RiskMap, FedRamp, …), giving all security technologies the same perspective on classification and impact.
Audit: Intentional security architecture establishes the audit control architecture and dependencies (SABSA, TOSCA, Application Blueprints, NFV service chain …). Could support automated support for validating audit structure at runtime.
Attestation: SLA expression standards (SANS SMART, CSA/ENISA secSLA, MUSA, SLALOM, …)
Argumentation (future): Security argumentation can express the broader security characteristics and supportable claims of a system of services, application, functions or components. Requires logics that can support reasoning in the presence of both in- completeness and uncertainty (well beyond first order policy languages e.g. Congress) … at least defeasible policy logics.
Possible CUC Product: Validated alignment use cases across governance, policy, , challenges, and opportunities.

5. Dimension: Emerging challenges
Emerging technologies, architectures, application/service frameworks, … are challenging long standing standardization assumptions.
Identifiers (IP, MAC, System SID, …) – The decoupling and dynamics of serverless functions (AWS Lambda, OpenWhisk, Cloud Functions, …) challenge the use conventional identifiers.
Integrity: The complex supply chain and long operational life of IoT devices, challenge any notion of full stack integrity or control.
Diversity: The growing diversification of compute fabrics (GPUs, FPGAs, OCP, SDx, PBR, CBR …) challenge conventional security configuration and control.
Opaqueness: Many emerging security innovations limit transparency and independent verification, making security instrumentation difficult (e.g. secure multi party compute, semi- homomorphic encryption, secure enclaves, nested virtualization, public cloud operational security/forensics, ...)
Possible CUC Product: Validated challenge identification. Possibly suggestions about plausible directional approaches to the TCs.

6. Proposal
Establish a work stream consider these examples for more representative representation of the CUC view.
Consideration of which, if any, of the resulting dimensions we should consider pursuing.
If we feel that more resourcing is needed to address these kinds of issues, consider whether we could sponsor a CUC position paper as a community conversation starter for broader consideration.