NIEM and Content Policy briefing David Webber - Public Sector NIEM Team, April 2013 NIEM Test Model Data Deploy Requirements Build Exchange Generate Dictionary

<Insert Picture Here>

NIEM and Content Policy briefing

David Webber - Public Sector NIEM Team, April 2013

NIEMTest Model Data

Deploy Requirements

Build Exchange

GenerateDictionary

XML Exchange Development

NIEM

and

Content Policy

Copyright ©2011, Oracle. All rights reserved. Oracle Draft Materials – Limited Circulation

The following is not intended to outline Oracle general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions.

The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

Disclaimer Notice

Slide 22013,


Executive Overview

Managing information privacy and access policies has

become a critical need and technical challenge. The

desired solution should be ubiquitous, syntax neutral

but a simple and lightweight approach that meets the

legal policy requirements though the application of

clear, consistent and obvious assertions.

Today we have low-level tools that developers know

how to implement with, and we have legal documents

created by lawyers, but then there is a chasm between

these two worlds.

32013,


Approach

The solution we are introducing will:

• Enable business information analysts to apply and

manage the policy profiles

• Provide a clear separation between content and policy

artifacts

• Allow reuse of policies across content instances

• Provide a clear declarative assertions based method,

founded on policy approaches developed by the

business rules technologies community

• Leveraging open software standards and tools

42013,


DNI exchange level mission requirements

• Marking validation to ensure controlled values and business rules are followed.

• Cross-domain discovery, access, and dissemination capabilities based on access policy logic that leverages electronic security markings along with other key metadata about users, services, clearances, and access environments.

• Source: http://www.dni.gov/index.php/about/organization/chief-information-officer/information-security-marking-metadata

5

This is the domain of NIEM and exchange services

2013,

http://www.dni.gov/index.php/about/organization/chief-information-officer/information-security-marking-metadata

http://www.dni.gov/index.php/about/organization/chief-information-officer/information-security-marking-metadata


DNI document rendering requirements

• User interfaces and processing logic that helps users and services to reliably assign and manipulate information security markings at the portion and document level.

• Automated rendering of electronic portion markings, security banners, classification authority blocks, and other security control markings in accordance with the IC's classification and control marking system and associated executive orders, statutes, and DNI policies.

6

This can be handled as entirely separate layer per local users handling of content

2013,


Important Considerations

• Embedding security markings in content can compromise that content and make it a target

• Keeping policy separate from content makes the application flexible and consistent

• Document instances do not reveal aspects of their content while allowing dynamic application of policy rules

• Rules based approaches can be much more predictable and flag content that security markings alone cannot

• NIEM facilitates this approach by providing consistent content semantics

72013,


Application Scenario Overview

8

Policy Rules

Portal

User Dashboard

11

Apply Policy Rules to Requested Case Content

44

Users see only

information

permitted by

their role and

policy profile

(digest and

detail levels)

Request

Output Templates

Output TemplatesInformation

Requests

22

Case Management

Registry

Services

33

Output Templates

Output Templates

Case Documents

XML

Response

Output Templates

Output TemplatesRequested Information

55

User Profiles

2013,


The 8 “D”s and NIEM

• Design• Develop• Deploy• Document• Dictionaries• Discovery• Differentiate• Diagnose

Repeatable, Reusable Process(Exchange Specification Lifecycle)

NIEM IEPD Process

*IEPD - Information Exchange Package Documentation

92013,


Example - Suspicious Activity Report V2.0

dictionariesdictionaries

XMLXML

XMLXML

XMLXML

• SAR v1.5 components

• NIEM core dictionary

• LEXS 3.1.4 dictionary

• SAR v1.5 components

• NIEM core dictionary

• LEXS 3.1.4 dictionary LEXS

components

referenced

New structure components

based on NIEM + SAR + new

SAR conceptual components

Definitions stored as syntax

neutral canonical XML

NIEM core components

Dictionary Collection

Namespaces of

dictionary components

DRAFT

CAM Editor project for NIEM http://www.cameditor.org2013,


Differentiate

• This step includes building in deployment specific

details and rules and usage policy determinations• Add additional XPath rules for local integration needs

• Constrain code lists to local use

• Limit and restrict content based on policy and role of exchange

partners

• Contextually exclude structure components based on rules

• Create other integration artifacts for middleware such as policy

control, partner certificates and security configuration

• Can configure these aspects through the CAM

template editor and using middleware tools

CAM Editor project for NIEM – http://www.cameditor.org

112013,


SAR Visual Template + Rule Assertions

Rules Assertions

associate and control

access privacy to

specific content areas

in the SAR details

structure

Visual metaphor

allows policy

analysts to verify

directly

12

SAR – Suspicious Activity Report

2013,


Deploy, Diagnose and Document

• Once structure information exchange is complete need

to test and verify it by generating realistic XML examples

• Validate those against the exchange template

• Share working examples with exchange partners

• Share documentation (IEPD)

• Generate NIEM IEPD artifacts including• Business component usage report with rules and definitions

• Code list details and content checks

• UML models

• Spreadsheets of Policy Rules

132013,


TECHNOLOGY REQUIREMENTS

Policy Templates and Profiles

2013,


Use Case – SAR Case Management

• Three levels of information access • Citizen level reporting - SAR statistics• Local law enforcement officials - case review• State and Federal - case management and coordination

• This means three profiles:• Profile 1 - Registry query - statistics results• Profile 2 - Local staff• Profile 3 - Regional staff

152013,


Using Policy Templates

• Traditional NIEM approach focuses on the information exchange data handling

• Uses XSD schema to define content structure and metadata• Need is for a bridge between the NIEM schema, the XML

information instances and the XACML rule assertion language• Approach is based on visual content structure templates with

declarative rule assertions

162013,


D E P L O Y E D

Approach in a Nutshell

XACML

Engine

Rule Assertions

P O L I C I E S

Output Templates

Output TemplatesExchange Structures

Policy Assertion Template

Policy Assertion Template

22

S C H E M A

NIEM

IEPD

11

XACML Generation

Tool

XACML Generation

Tool

33XACML

XML Script

44

Rules Asserted to

Nodes in the Exchange

Structure via simple

XPath associations

172013,


Policy Granularity

Coarse-Grained

Role-based authorization of subjects.

Access granted to coarse-grained data objects.

E.g., “Permit law enforcement to access the NCIC Wanted Persons

Database.”

Fine-Grained

Attribute-based authorization of subjects.

Access limited to specific data objects based on attributes.

E.g., “Permit law enforcement to access criminal history records if the records were created by the

requester’s agency.”

182013,


• Actions.

Rule and Context Metadata

19

Properties of the access rules and environment.

• Conditions– Subject.– Resource.– Policy.

• Obligations.

2013,


• Express policies in a structured language (e.g., XML)

• Identify requesters• Compare data collection and

release purposes• Enforce retention rules• Notify data owners and

subscribers• Verify compliance

Privacy and Security Architectures

202013,


Mapping to Data Standards

21

• GFIPMUser Metadata

• NIEM• GFIPM

Content Metadata

• XACMLActions

Electronic

Policy Statements

2013,


• A mechanism to specify policy rules in unambiguous terms

• XML Access Control Markup Language (XACML)• Machine-readable• Supports federated

and dynamic policies

Policy Authoring Language

222013,


SUMMARY AND REVIEW

Policy Templates and Profiles

2013,


Key Messages

• Dramatically simpler policies adoption

• Can be rapidly developed with existing tools

• Can be visually inspected and verified by policy

analysts

• Enables use of dynamic contextual policies

• Leverages UML and semantic modelling

• Supports international standards work

242013,


CAMeditor.ORG Project Statistics

‹#›

SNAPSHOT OF PROJECT

ACTIVITIES

120,000 CAMeditor.org page

visits to date

165+ countries have downloaded tools; 27% of visitors are

from U.S.;750+ downloads

weekly

1000+ video training minutes viewed

monthly

8 languages now available

2013,