Re: [ekmi] SKML 1.0 Specification - Edited with questions

[Arshad Noor <arshad.noor@strongauth.com>]

Hi Allen,

All of these aer very good comments.  I agree with you about the 
Auditors and the sampling of messages they must take to verify 
messages against the policy settings in the SKMS.  

Sometime after we have standardized the protocol and Implementation 
Guidelines, the TC is going to be taking up the Audit Guidelines for 
EKMI.  I think we should make this task a required component of an 
Audit guideline/standard for EKMIs.

Mike/Ken/Davi, what do you all think?  You represent the leading edge 
of ISACA's thought-processes on IT audits.  Should we start thinking 
about what kind of tools we should recommend/provide auditors so they 
can not only audit an EKMI but verify that what they see is exactly 
what is under the covers?

One last note Allen: you might want to take your comment about XML
Schema to xmlschema-dev@w3.org, which has many thought-leaders in
that arena on that forum.  Perhaps they might give you an answer to
your concerns.

Arshad Noor
StrongAuth, Inc.

----- Original Message -----
From: "Allen" <netsecurity@sound-by-design.com>
To: "Arshad Noor" <arshad.noor@strongauth.com>
Cc: ekmi@lists.oasis-open.org
Sent: Thursday, June 26, 2008 10:17:23 PM (GMT-0800) America/Los_Angeles
Subject: Re: [ekmi] SKML 1.0 Specification - Edited with questions

Hi Arshad,

Well, what can I say? Blind obedience to clearly inhuman rules leads 
to further mistakes?

What you describe as requirements of the XML Schema demonstrates a 
lack of understanding by the compliers of the schema of three key 
elements of proper technical documentation: clarity, conciseness, 
and white space.

The maintainers of the schema should be sent back to school to learn 
how humans communicate best.

Enough said about that. So what do we do to make our documentation 
less opaque? I suggest that we provide a non-normative section that 
lays out the issues in the manner that you wrote in your e-mail and 
then provides a translation into the obscurity required by the 
schema. At least this way they get the understanding of what they 
are attempting to accomplish and the logic underlying it all.

Some additional comments below.

Arshad Noor wrote:
> Thanks for the feedback, Allen.
> 
> I agree that the earlier construct I provided in an e-mail last
> week was easier to understand, Allen.
> 
> Unfortunately, it turns out that XML Schema does not allow you
> to define an element (with the same name) to contain either
> sub-elements or text content.  The only way to do this was with
> an attribute.  Since "any" is used to frequently in XML Schema,
> you have to qualify it with the "ekmi" namespace.
> 
> The xsi:nil became another XML Schema requirement, because if
> you have an element that is defined to have some value in it
> (such as a number range or enumerated list, etc.), having a
> null element causes schema-validation failures, *unless* you
> have the "xsi:nil" attribute set to "true".

Is it possible to have have this to a numerical like range where 
zero (or ten for that matter) equals the same as "any" and other 
numbers indicate more restrictive uses? This might avoid having to 
add the xsi confusion.

> That said, Auditors will not likely be searching protocol
> messages between SKMS clients and servers when auditing an
> EKMI.  

If they do not look at the actual messages and compare it to what 
the policies say, how will they know that the messages haven't been 
compromised at some point?

Frankly any auditor that failed to sample the messages should have 
their audit certificates revoked. This is the equivalent of looking 
at the check book stubs and declaring all is right with the world 
and never looking at the check to see who they are actually made out 
to, who cashed them and what stamps were used to endorse them. You'd 
never get a bank auditor to do it this way unless they were crooked.



> They will query the Administration Console for all Key-
> UsePolicies that have NULL values for Permissions.  The console
> will then perform an SQL database search for NULL values and
> show them the policies that meet the search criteria.

Policies are not procedures. Knowing and acting on this is the 
difference between a policy that is ignored in the breach and one 
that is actually followed day to day.

> If an Auditor is diligent enough and wants to see the actual
> protocol message between a server and a client for one of the
> KeyUsePolicies, then they will more than likely use an XML
> Schema tool such as NetBeans, Eclipse, etc. to view the XML
> elements in graphics mode and then view the content they're
> interested in, in text.

And, pray tell, how do they know the tool does what it says it does? 
It is an iron clad rule of auditing that you start as close to the 
actual transaction as possible - maybe doing just a valid 
statistical sample - and then run that through higher level tools to 
validate that the tools are not, by accident or design, distoring 
the results.

> Additionally, we have another goal for this TC - which we will
> get around to in 2009: creating a conformance test-suite so
> that protocol implementations can be tested.  That conformance
> certificate from OASIS will also tell the Auditors something
> about a a company's EKMI implementation.

However, as I say above, to be sure that a conformance test suite is 
delivering valid output, one needs to examine both the actual 
messages and the rules that implement the protocol. If this is not 
done then one is simply looking at the ledger of accounts, not how 
the expenditures are made. There lies the opportunity for fraud, or 
in the case of EKMI, massive breaches that could be missed.

> Hope that addresses your concern, Allen.

As much as it is possible to do so with the constraints you 
describe, you have done so.

I do think we need to push back on this so that future documentation 
is designed for human readability and understanding, not some 
formalistic structure that ignores the humans that use the 
documentation and implement the protocol.

Best,

Allen