NBDRA Table 1 represents a preliminary mapping of the operational taxonomy to the NBDRA components. The topics and activities listed for each operational taxonomy element (Section 4.2) have been allocated to a NBDRA component under the Activities column in Table 1. The description column provides additional information about the security and privacy aspects of each NBDRA component. Table Draft Security Operational Taxonomy Mapping to the NBDRA Components Activities Description System Orchestrator Policy Enforcement Security Metadata Model Data Loss Prevention, Detection Data Lifecycle Management Threat and Vulnerability Management Mitigation Configuration Management Monitoring, Alerting Malware Surveillance and Remediation Resiliency, Redundancy and Recovery Accountability Compliance Forensics Business Risk Model Several security functions have been mapped to the System Orchestrator block, as they require architectural level decisions and awareness. Aspects of these functionalities are strongly related to the Security Fabric and thus touch the entire architecture at various points in different forms of operational details. Such security functions include nation-specific compliance requirements, vastly expanded demand for forensics, and domain-specific, privacy-aware business risk models. Data Provider Device, User, Asset, Services, Applications Registration Application Layer Identity End User Layer Identity Management End Point Input Validation Digital Rights Management Monitoring, Alerting Data Providers are subject to guaranteeing authenticity of data and in turn require that sensitive, copyrighted, or valuable data be adequately protected. This leads to operational aspects of entity registration and identity ecosystems. Data Consumer Application Layer Identity End User Layer Identity Management Web Services Gateway Digital Rights Management Monitoring, Alerting Data Consumers exhibit a duality with Data Providers in terms of obligations and requirements – only they face the access/visualization aspects of the Application Provider. Application Provider Application Layer Identity Web Services Gateway Data Transformation Digital Rights Management Monitoring, Alerting Application Provider interfaces between the Data Provider and Data Consumer. It takes part in all the secure interface protocols with these blocks as well as maintains secure interaction with the Framework Provider. Framework Provider Virtualization Layer Identity Identity Provider Framework Provider is responsible for the security of data/computations for a significant portion of the
This use case provides an overview of a Big Data application related to the shipping industry for which standards may emerge in the near future. Table 10: Mapping Cargo Shipping to the Reference Architecture NBDRA Component and Interfaces Security and Privacy Topic Use Case Mapping Data Provider → Application Provider End-point input validation Ensuring integrity of data collected from sensors Real-time security monitoring Sensors can detect abnormal temperature/environmental conditions for packages with special requirements. They can also detect leaks/radiation Data discovery and classification --- Secure data aggregation Securely aggregating data from sensors Application Provider → Data Consumer Privacy-preserving data analytics Sensor-collected data can be private and can reveal information about the package and The revealing of such information needs to preserve privacy Compliance with regulations --- Government access to data and freedom of expression concerns The U.S. Department of Homeland Security may monitor suspicious packages moving into/out of the country Data Provider ↔ Framework Provider Data-centric security such as identity/policy-based encryption --- Policy management for access control Private, sensitive sensor data and package data should only be available to authorized individuals. Third-party commercial offerings may implement low-level access to the data Computing on the encrypted data: homomorphic encryption See above section on “Transformation” Audits --- Framework Provider Securing data storage and transaction logs Logging sensor data is essential for tracking packages. Sensor data at rest should be kept in secure data stores Key management For encrypted data Security best practices for data stores The diversity of sensor types and data types may necessitate the use of non-relational data stores Security against DoS attacks --- Data provenance Metadata should be cryptographically attached to the collected data so that the integrity of origin and progress can be assured. Complete preservation of provenance will sometimes mandate a separate Big Data application Fabric Analytics for security intelligence Anomalies in sensor data can indicate tampering/fraudulent insertion of data traffic