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
