Re: [Json] Security Considerations

[Peter Brooks <[e-mail]>]

I see two quite separate issues here.

1. The security of JSON itself as a data exchange mechanism
2. The ability for organisations to exercise good governance by having
their defined security policy reflected transparently in the access
controls of objects

The first issue applies only where JSON is exchanged in cleartext. If
JSON messages are exchanged through secure, encrypted channels, such
as SSL, then the chance of any successful interception and
modification of the message without detection is very small and more
the responsibility of the security software than the structure of JSON
itself. If JSON messages are exchanged in cleartext, that, itself, is
an indication that they are public and unimportant, so the risk, even
if they are intercepted and modified, is low.

The second issue matters even if the JSON messages are encrypted. If
the software fails to enforce corporate security policy, objects can
be revealed to unauthorised parties without detection being easy, or
even possible, as the logic is in the application, not the data, the
JSON object itself.

It is possible to secure JSON at the moment by adding fields that do
one of two things:

- Apply a corporate confidentiality level to an object
('Public','Private','Company Confidential','Internal Only','Board
Members Only', for example). The names of the fields are not defined,
though, so a scheme set up by one company would not be compatible with
one set up by another, which would cause problems if the two merged.
This inconsistency also makes it more difficult to validate the
security mechanism.

- Define the roles that are allowed to have, or are denied, access to
an object. Again, this is possible today, but there is no agreement as
to what syntax the access controls should follow or how the roles
should be defined.

If a system for security control was added to JSON in this way, it
would have to be backwards compatible by having any object without a
confidentiality level or access control being treated as PUBLIC.

The virtue of embedding this in the objects, not the application, is:

- applications can be tested and validated against access controls, in
detail, and proved to be complying with the JSON security.

- security staff, auditors and others can validate the security of
objects against policy by examining only the JSON schema and JSON data
with no requirement (once they have been tested and validated as
above) to examine the applications themselves.

Both of these would lead to JSON being recommended as an acceptable
data exchange method for organisations requiring good security
governance.

Obviously, securing the JSON objects would not prevent JSON files
being exchanged with the secure data exposed, but, again, the security
of files or databases is the responsibility of other security matters,
not the definition of JSON.