Folks,
Spencer Cheng and myself from KDM Analytics have been
on the list of interested parties from the beginning, unfortunately we have
been unable to participate in any active sort of way until recently as we were
heads down working on a couple of projects. Now that the major one is
completed, we are looking forward to reengage with the rest of the team and to
contribute.
I would like to share some of our experiences from a
project that involved using SBVR for the formalization of security requirements
in the context of software assurance.
First, our background. KDM Analytics the company is
actively involved in the OMG software assurance and modernization task forces.
I am part of the SBVR FTF. I am also chairing the Knowledge Discovery Metamodel
(KDM) RTF within OMG. KDM is a normalized representation of existing software
artifacts, and it is aligned with SBVR and also with RDF from W3C. Here is
where you can learn more: http://www.kdmanalytics.com/kdm
and http://www.kdmanalytics.com/sbvr
Our recent project was in the area of building a
standards-compliant framework for tool interoperability for software assurance
of production code. This sounds like a mouthful. The project is about 1)
creating common content for software assurance that can be plugged into the
analysis tools; 2) tools to reverse engineer production code and populate
KDM-compliant repository; 3) static analysis tools that can utilize standard
content and search KDM-compliant repository and validate the formalized
properties.
We are utilizing SBVR and KDM in this framework. The
pilot studies showed that SBVR is a suitable way to formalize security
requirements. The alignment between SBVR and KDM allows for the transformation
of the security requirements into recursive queries against the KDM repository
that contains standardized facts about the application. On the KDM side there
is a growing community of tool vendors, in particular Modisco Eclipse project: http://www.eclipse.org/gmt/modisco/
Regarding SBVR tools. We looked at the Sbeaver tool,
talked to the development team and assessed their entire code base. I am also
part of the early adopter program for the Unisys Rules Modeler tool for a
couple of years now. None of these tools were battle ready.
So we developed our own SBVR SDK using Eclipse EMF.
The objective of the SBVR SDK is to provide guidance in developing semantic
formulations for security-related statements. Security-related statements are
simply statements that describe a certain condition using a controlled vocabulary.
In other words, they are similar to business rules written against a business
vocabulary, even though the community of interest does not call itself
“business people”. We performed a pilot project in which we
formalized security weaknesses taking the content from the so-called Common
Weakness Enumeration (CWE) at http://cwe.mitre.org
The official MOF SBVR SDK is structured in such a way
that does not offer much guidance for authoring using EMF-based tools. It is
flat, while the EMF-based tool need single-parent ownership hierarchy to
generate the editor with good guidance. By guidance I mean the reasonable
pull-down menus (generated from the meta-model) that are reasonable restricted
to the context-sensitive choices of modeling elements (Child and Sibling). The
same type of guidance is useful for generating the EMF validator.
The other problem with the official SBVR (with
respect to authoring tools) is the separation between Meaning, Presentation and
Representation. While very useful as part of the SBVR framework in
general, when naively plugged into a EMF-type tool, this is not useful, because
of this separation leads to great redundancy in a simple use case, where a
vocabulary and the corresponding rules are being authored for a given speech
community. In this simple use case one creates an instance of Meaning element,
and gives it a name (for example Concept “code path”), and then has
to create a Representation element with a string “code path”, and
say that the Concept “code path” is represented by a string
“code path”. As the result, 3 elements are created, which is
redundant.
So we decided to focus only on the Meaning slice of
SBVR. In EMF terms, the name of the element is the presentation of the element,
and the both the presentation and representation parts of the official SBVR MOF
can be autogenerated. Note, this only works for a preselected speech community,
in a more general case the entire SBVR framework is required. However, when it
comes to authoring, there are usually two separate roles of 1) developing the
base vocabulary and 2) translating it into another language.
The third thing we did was to disable all predefined
SBVR vocabulary items (Vocabulary and Rules vocabulary), limiting the EMF
metamodel to core elements. This is done by making these element abstract in
the EMF.
The resulting SBVR SDK is quite useable, at least for
someone who does not mind to work directly with SBVR semantic formulations. The
resulting XMI has exactly the same structure as the semantic formulation
outlines, provided in the specification. Attached is a screenshot of the SBVR
SDK.
On top of the base SBVR SDK we implemented an export
capability that generates the official SBVR XMI.
We used the SBVR SDK to author the vocabulary
corresponding to some 30 Common Weakness Enumerations (from http://cwe.mitre.org)
which provide informal descriptions for security weaknesses; and several
corresponding semantic formulations. As part of the project we have delivered a
detailed SBVR formalization methodology.
I understand that this approach is very similar to
what was reported by Mike Linehan and what is being implemented in the MDT-SBVR
tool metamodel.
I am in the process of doing a detailed assessment of
the MDT-SBVR project so far. As I mention, we are looking forward to contribute
to the MDT-SBVR. There is preliminary agreement that our SBVR SDK should be
available as some kind of open source format.
Looking forward to your feedback,
Nick
Nikolai Mansourov
Chief Technology Officer
KDM Analytics
cell (613) 276-2323
www.kdmanalytics.com
e-mail: nick@xxxxxxxxxxxxxxxx