The necessity of a knowledge base for Cyber Security – Static & Dynamic Software Assurance

October 21, 2013

We have recently completed SBIR research funded by DHS relating to Cyber-security and software assurance. In that research the necessity for a knowledge base for software assurance results becomes crystal clear. In this research we looked at relating software assurances methodologies – static analysis (evaluating the system design and source code) as well as dynamic analysis (evaluating tools that attempt to penetrate a system at runtime). We also looked at the integration and correlation of static and dynamic analysis. The really exciting results come from the correlated results.  A video demonstrating these results can be seen here:

There are many tools that analyze systems for vulnerabilities and even some that can integrate the results of multiple tools and provide pretty pictures or reports. However, this is a naïve approach and one that cannot provide the full hybrid analysis capabilities needed to overcome the sophisticated threats to our critical systems.  These more naïve approaches tend to provide a “black box” into which some information goes and then answers pop out.  What this fails to provide is the ecosystem foundation whereby there can be any number of inputs from a wide variety of static and dynamic sources, any number of correlation and analysis algorithms (which must independently evolve as does attackers sophistication) and any number of reporting and visualization capabilities. A closed system (or a set of non-interoperable closed systems) can only, ever, be simple tools – not a technical foundation or the basis of an ecosystem.

The problem with any single point or closed solution is that the job of software assurance is, by necessity, never compete. There will always be new patterns of attack and patterns of vulnerabilities.  In addition, any single tool invariably has many false positives (things marked as weaknesses that are not) and false negatives (vulnerabilities that have been missed).  The false positives can run into the thousands, making true validation impractical, and of course, and SINGLE missed vulnerability can be disastrous. Only when the capabilities of multiple techniques, algorithms, visualizations and tools is combined can a realistic picture of a system’s risk be understood and vulnerabilities mitigated. We need an environment where these different tools, algorithms and visualization capabilities “plug in” to a common repository of facts about a system.  Our tests have indicated that a federated approach to assurance reduces the false positives by an order of magnitude (or more) and improves coverage, providing fewer false negatives – i.e. a more trusted system.

The open knowledge base approach is fundamental to providing an agile, open and essentially unlimited capability to understand, analyze, secure and visualize our systems. With one query a new correlation can be tested, a new path explored or a new report produced. It is the essential move of cyber security from a tool orientation to a knowledge and information orientation.

With a knowledge base as a foundation we have the makings of an ecosystem, not just a product. Anyone can add an adapter to gather new system facts, anyone can add new correlation or analysis algorithms – based on the information from any of the inputs, from anyone else, anyone can then add visualizations or reports to the information produced from any of the inputs or any of the correlation or analysis algorithms. It should be noted that while the ecosystem is open due to the knowledge base, any component may be internally open or closed – based on the commercial or security interests of the authors. This openness and flexibility are crucial for a successful software assurance ecosystem.

Since it is our desire and expectation to have this degree of openness and flexibility, the capabilities of and interfaces to the knowledge base are crucial. It has to be tough enough, scalable enough and capable enough to manage such varied requirements. The approach to the knowledge base we evaluated is to integrate the experience of dozens of experts in the field which have contributed to an open standard – ISO/IEC 19506 (OMG-KDM). Home-grown or ad-hoc approaches to the problem are unlikely to encompass the deep experience encompassed in the standard and reproducing that capability in a non-standard way would be expensive and counter-productive.

Of course any standard must be “field proven” and this project has been a test of that standard to encompass the new capabilities of hybrid analysis. The good news is that there were no changes required to the standard foundation. All that was required is the addition of definitions, in terms of KDM primitives, of the new capabilities – execution traces and penetration results. This addition of new definitions in terms of primitives is the intended way for the knowledge base to grow in scope and flexibility. The KDM based repository performed admirably in this project and exceeded expectations.

It is therefore our conclusion in this research that ISO/IEC 19506 (OMG-KDM) and the knowledge based approach have been validated for hybrid analysis and Cyber Security. There is no reason for proprietary, black-box or closed solutions. Further, it is apparent that it is irresponsible to deploy any system in today’s environment without rigorous software assurance.

Achieving an Architecture Ecosystem

January 15, 2010

Having been involved in modeling and architecture standards for a long long time, the problem of modeling “stovepipes” has become increasingly apparent.  Even within one organization, like the Object Management Group, the modeling standards “don’t connect”.  For example the new Business Process “BPMN-2” standard does not have a clean way to share processes, data and services with UML models.  Despite both being defined within the “Meta Object Facility” (MOF) there is no semantic interoperability.  Kenn Hussey commented on the BPMN issues in his blog post “On The Future of BPMN (Too)”.

The problem with this is that architects, developers and analysts are developing information that is closed, hard to find, hard to integrate and not providing the value it could.  At a time when we must do a much better job making effective organizations, collaborating, sharing data and resources – we need this critical information.  

A new group has formed (which I am helping to chair) called the “OMG Architecture Ecosystem Special Interest Group”.  It is the mission of this group to chart the course for solving these problems, for making all of our modeling languages viewpoints on an underlying federated knowledge base.  Modeling in this context includes all forms of structured knowledge representation, including: Business Models, Vocabularies, Ontologies, Object Models, System Models, SOA Models, Data Models, Schema, Process Models, Domain Specific Languages, DoDAF, etc.

 When this capability comes on-line it will be a game changer – no longer will “business modeling” and “systems modeling” and “ontologies” and “vocabularies” be separate islands, but part of the integrated knowledge base of an enterprise, government agency or community.  This will help enable collaboration, information sharing and enterprise transformation.  Being able to share and relate architectures can also help acheave the open government goals.

 One of the approaches we feel has a lot of promises is to utilize the “semantic web” and “linked open data” (LOD) as the foundation for the architectural ecosystem – this will enable multiple models and modeling languages to be connected in the LOF cloud, yet retain their individuality.

 More information on this initiative is available here: http://www.omgwiki.org/architecture-ecosystem

Of course this is not easy – there are technical and a host of political issues, but with the work we have already done on the EKB, we know it can be done.  I hope we will be able to put together a groundswell of participation to achieve the ecosystem.

OMG Issues RFP for Any OMG Model or Architecture (UML, BPMN, SoaML, Etc) to use RDF Linked Open Data

December 17, 2009

At the technical committee meeting last week in Long Beach California, the Object Management Group issued a request for proposals to provide better connectivity between models and modeling languages defined in OMG and RDF Linked Open Data.

The OMG  is the premier standards organization for modeling, middleware and architecture.  OMG standards include UML, BPMN, UPDM (UML Profile for DoDAF), SoaML, SysML, Ontology Definition Metamodel, Model Driven Architecture (MDA), Records Management, Corba and may others.  All of these modeling standards are based on the “Meta Object Facility” (MOF) which uses the XMI interchange format for model interoperability.

The RFP issued last week will result in a standard for representing all MOF based models and modeling languages using RDF and Linked Open Data.  This has multiple advantages:  All OMG-MOF based models (UML, BPMN, SOA, UPDM, Etc) will be able to be published as Linked Open Data and thus take advantage of the LOD tools and community.  This will allow architectural information to be linked, queried with and analyzed with other kinds of information on the web and will also allow architectures to be linked and queried with architectures in incompatible models.  Architectures as data will become first-class citizens in the global data cloud.

The RFP asks for a “Structural mapping” which means that the model vocabulary remains unchanged.  For example, a UML model retains the UML vocabulary.  The structural mapping can then convert any kind of model without information loss, but it does not translate between vocabularies as is done in the UML class diagram to OWL mapping defined in the Ontology Definition Metamodel.  Other semantic mappings and ontologies are expected in the future.

More information on the details can be found in the RFP document here: http://www.omg.org/cgi-bin/doc?ad/2009-12-09

 The objective of the RFP is summarized as follows:

Title: MOF to RDF Structural Mapping  in support of Linked Open Data

RDF and Linked Open Data (LOD) have become important technologies for exposing, managing, analyzing, linking and federating data and metadata.  This set of RDF based technologies, sometimes known as the “Semantic Web” or “Web 3.0”, are emerging as the lingua franca of data on the web. Major initiatives such as the President’s open government initiative are moving to the use of RDF & Linked Open Data as the foundation for publishing all government data and metadata in support of transparency.  OMG & MOF based models should be a part of the LOD and Web 3.0 data cloud.
The objective of this RFP is to define a structural mapping between OMG-MOF models and RDF to provide for better integration of MDA and LOD, to enable the ability to apply LOD capabilities to MOF compliant models and to make the information available in MOF compliant models available as LOD web resources.  Any MOF based model should be able to become a LOD resource.

The model/LOD connection is also very good news for the Open Government Initiative which calls for government to be more open, visible, collaborative and participatory.  Government architectures are the primary source of structured information about government processes, services, rules and data.  As such the data contained in these models, which will become visible as Linked Open Data, will further the open government initiative.

ModelDriven.org has done a preliminary open source implementation of this mapping as part of the Enterprise Knowledge Base (EKB) project.  Those interested in participating in the standards and/or open source efforts are welcome to contact us for more information on how to engage.  Cory Casanave, who championed the RFP, may be contacted at: (cory-c at modeldriven dot com).

Please feel free to send  this notice to other interested parties in the ontology and modeling communities.

Lean Architecture – Architectures for Doing More with Less

November 9, 2008

I have been giving some thought to the practice of architecture and what we need to do in these times where we need to do more with less while enabling positive change.  My thoughts on the subject have come around to what I would call “Lean Architecture” – Architectures for doing more with less.  Community input would be appriciated as we develop the idea further.

What is Lean Architecture?

In these times of needing to do more with less, of having more responsibilities with less budget, we need to work and apply our resources smarter – a lot smarter.  Lean architecture is intended to bring together best practices across business and technology to do more with less. Lean architecture complements other successful approaches such as the Zackman framework, agile methods, total quality management and lean sigma.

Lean architecture applies at multiple levels; from enterprise and business architecture, through systems architecture to technology implementation.  It can include service orientation, business processes, information and business rules – depending on the problems and opportunities to be addressed.

Architected solutions can out-perform a chaotic system, if applied correctly and at the right levels.  However, not everything should be architected, as some things just worked better if they are self-organizing.  Lean architecture is understanding when and when not to architect a solution, and in how much detail.  It is understanding how a plan, process or design can say enough to be effective and efficient without stifling creativity and diversity.

Lean architecture delivers value, if it doesn’t – it shouldn’t be done.  The art of lean architecture is maximizing the value derived from planning and design of our enterprises, or missions and our technologies.

Five Core Principles of Lean Architecture

We have summarized five core principles of lean architecture.  These have been derived from decades of architectural experience – including those that delivered value and those that didn’t.  These are principles for deriving value from architecture to solve problems, reduce costs, foster agility and take advantage of opportunities.

A lean architecture should;

  1. Enable doing more with less using positive chnage
  2. Target a specific set of problems or opportunities important to stakeholders
  3. Express an actionable & verifiable plan or specification without stifling creativity and diversity
  4. Be agile and iterative based on stakeholder participation and measurable results
  5. Be tactically and strategically effective with the backing of an authority to act

 

Best Practice in Enterpise SOA

March 2, 2008

What is best practice for Service Oriented Architecture? The work Model Driven Solutions and GSA have done suggests a best practice at the enterprise level.

What this best practice develops is Enterprise-SOA as BOTH a business and technology style of architecture. Enterprise SOA is consistently represented by well defined models that are independent of the technologies that ultimately provide solutions integrating new and legacy functionality. Solutions, at this scale are for collaborative and virtual enterprises, integrated communities and “systems of systems”. SOA must, ultimately, facilitate better business, better mission execution, collaboration and mutual value.

In my opinion, this represents the most central principles of SOA best practice:

  • That the SOA architectural style focuses on how participants work together using services to achieve business value
  • That business services are the driver of the architecture
  • That technology services and business processes are defined to support the business services
  • That both “top down” and “bottom up” concerns must be taken into account in any architecture
  • That these architectures are independent of implementation technologies but can support multiple implementation technologies

This approach has been realized by GSA in terms of several projects, one example is their “Financial Management Enterprise Architecture” (FMEA). This has had several layers of development:

  • A wide-scale enterprise architecture (composed of both SOA and Value Chain viewpoints)
  • A more detailed business architecture for financial management, including business processes and services
  • A “systems of systems” level technology services architecture, based on the business architecture
  • An open source Model Driven Architecture provisioning capability to produce a large percentage of the application from standards based models
  • An open source SOA infrastructure that supports 24/7 operation with redundant, distributed deployment
  • A SOA implementation for one area within this architecture with adapters to COTS and legacy systems
  • Use of the latest modeling, MDA and platform standards

Is this all done and perfect – of course not! There are business, technical and process issues. There are issues with business stakeholders understanding why SOA is even needed (business or technical)!

Is this “best practice” – I think so! Particularly in the government – and a great benchmark for any large organization.

 

Note that a tutorial is being given on this subject March 13th in the OMG meeting near DC, see Model Driven Service Oriented Architecture

The open source road for making technologies pervasive

February 13, 2008

Is open source the right road? This is not an easy question. I can relate it to my own experience in that I was in the commercial product business (for 20+ years) with tools and infrastructure so I fully understand the challenges and questions of making something and having it succeed as a commercial product. On the commercial road there is the huge up-front investment combined with concerns about small companies delivering crucial infrastructure, marketing costs, long sales cycles and the risk of being eclipsed by open source. On the open source road there are all the business model questions, what is open, what not, under what terms to support a realistic business model.

So this is where we are going and why; As I said, I have had commercial products and was along the way to developing more. It became increasingly obvious how hard that direction would be to sell, fund, market etc. In that we are trying to be part of making an emerging technology pervasive, we also look at the potential for a “big win”, something that really has an impact in the marketplace. So our conclusion was that without (at least) $40 Mil it was a non-starter, even with such funding it is risky. The open source road looks better. The only way what we are doing may become a “happening” in the industry, is open source – if it becomes a happening, we will find the ways to profit from it.

The odd fact that seems to be now proven is that by giving it away it doesn’t mean you can’t also sell it!

So we have done a reversal on “I.P.”, anything we do (or use) we want to be open source so that we have the best chance of being behind something that is pervasive and compelling. We call this “funded open source”, we are not in it for fun and games. The business model includes funded development of assets, related projects to apply the technologies, supported commercial versions, training and “community income” from a (potentially) active community. Of course there are also buyout options. We are not opposed to commercial products at all, and see a lot of opportunity in helping to promote products and services that work with the open source base. Part of what we are trying to build-out is the capability for fully executable models – models that become applications very easily. There seems to be a great opportunity for open source models and both open source and commercial application components built on these models.

Then there is also the business model of commercial licensing – using an open source license that is sufficiently restricted (like GPL) that commercial users must pay. We have not yet done this, but is something we are thinking about – I am interested in peoples thoughts about this.

So this is why we are starting “modeldriven.org“, it is not really active yet because we are just getting to the point of having sufficient open source assets – but we will be announcing some very soon. Modeldriven.org will focus on embracing all things around models – this includes “MDA” (Model Driven Architecture) kind of models and the semantic web. We want open tools, infrastructure and open domain models (with the corresponding executable applications). A lot of this is being funded by the visionaries at GSA (www.osera.gov) like George Thomas and Richard Murphy.

So this is why we are going open source and would be interested in others thoughts.

Introduction

February 2, 2008

As a short introduction, I am Cory Casanave, president of ModelDriven.com and founder of ModelDriven.org. I have been active in the software and architecture communities since 1990 and the software business since 1978. My focus has been on architecture and distributed systems. Architecture, as I use it, applies to business, enterprise, I.T. systems, information, processes, etc. A common theme through all of my various projects, roles and companies has been better architecture and making those architectures “real” with technologies. This has brought be to Model Driven Architecture, SOA, BPM, Metadata management and the semantic web.  We are doing this in the open source community to make them pervasive.  These are intended themes of this blog.

As I have been active in communities for years, I really should have had a blog sooner, but alas, I am just experimenting with it now. So this blog is, for now, an experiment. Perhaps together we can make the experiment work.!


Follow

Get every new post delivered to your Inbox.