Cross-Domain Guard

[cmheazel]

With the migration to JSON, Cross Domain Guards can no-longer rely on applying rules against XML documents to make go-nogo decisions. Another approach is required.

Proposal: Leverage digital signatures to bind security markings to payloads. The signature validates the binding and identifies the entity which applied the binding. The CDG now only has to:

validate the signature,
validate that the originating entity can be trusted to apply markings to this level of data,
check current policy to see if data with these markings are authorized to pass (build on XACML)

There are cases where an additional level of protection may be needed. Due to on-going operations, data over a specific area during a specific time period may be protected. The CDG should be able to detect data which would violate that restriction. This would require extracting the bounding box and temporal extent of the data for evaluation against the current security policy.

It is often the case that only a small part of a data set is sensitive. Re-do the Alcatraz scenario, extending the CDG to redact sensitive areas of imagery.

[royrathbun]

Use Cloud Optimized GeoTIFF and 'range' request?

[sraymie]

what about multi-level security at the data element level?

[dflaefer]

Dear All I think that this is quite important. Debra

Debra F. Laefer Professor of Urban Informatics & Director of Citizen Science Center for Urban Science & Department of Civil and Urban Eng. New York University

On Mon, Nov 12, 2018 at 9:09 AM, sraymie notifications@github.com wrote:

what about multi-level security at the data element level?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_opengeospatial_ideas_issues_84-23issuecomment-2D437894366&d=DwMCaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=3xXYWn0GurAlN8zmPh8kFsgPLF1iQKF3prczDF2r8mI&m=fHd6H6BE0ebZMJkxchQ2nlyDJ2KFqHmgsKEIQ4CObUA&s=SfUkEnIOhtEHtDESxMKfDJLEm8tUvkGnt06DEj2DuH4&e=, or mute the thread https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_Aj2hLi11383rDU2-2DagdkuxYrRDDAraMfks5uuYEcgaJpZM4WjSuq&d=DwMCaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=3xXYWn0GurAlN8zmPh8kFsgPLF1iQKF3prczDF2r8mI&m=fHd6H6BE0ebZMJkxchQ2nlyDJ2KFqHmgsKEIQ4CObUA&s=BwKR2nG9ASQaisS0XSrzG_Aw54D3xY5LRwgNFRcWM14&e= .

[cmheazel]

Very hard to do in a Guard. What we can do is pass request and response pairs through the Guard. Fine grained access control is applied by the data service, and all the Guard has to do is validate that the request and response are allowed to cross to the other domain. Key to this is Federated Identity. The data service has to know enough about the requesting principle to enforce its' security policies. We laid out a Federated Authentication architecture in Testbed 14 and plan to build on it for Testbed 15. Ultimately we would like to federate both authenticated identity as well as the principle's attributes. That should allow us to do cross-domain ABAC.