Chapter 12. Case study
Abstract
This chapter describes a single case study in which we illustrate the key elements of system assurance and the OMG Software Assurance Ecosystem. In particular, we describe the concept of operations and the security policy of the system using SBVR; highlight the threat identification and the architecture descriptions of the system; and develop fragments of the assurance case, focusing on one security requirement. The case study demonstrates the linguistic analysis of the security requirement, identification of the key characteristics, and development of the portion of the assurance argument based on these characteristics down to the level of simple queries to the KDM fact-oriented repository, from which the evidence is obtained. Additional illustrations for the case study are provided in Chapter 11, explaining the individual KDM viewpoints.
Keywords
knowledge discovery metamodel, assurance case, system facts, evidence, linguistic model, sbvr, kdm
No data yet—It is a capital mistake to theorize before you have all the evidence. It biases the judgment.
Arthur Conan Doyle, A Study in Scarlet
It was easier to know it than to explain why I know it. If you were asked to prove that two and two made four, you might find some difficulty, and yet you are quite sure of the fact.
Arthur Conan Doyle, A Study in Scarlet
12.1. Introduction
In this chapter we use a single case study to illustrate some of the activities of a system assurance evaluation, highlighting the exchanges of content and managing pieces of cybersecurity knowledge in an integrated system model throughout the entire system assurance project. We illustrate the concept documents: the system Concept of Operations (CONOP) document and the definition of the system security policy based on the full vocabulary in SBVR [SBVR]. These documents are the key inputs to the project definition phase of the system assurance project. We then illustrate some of the activities involved in building the baseline system model. Many examples provided in Chapter 11, illustrating the key ideas of the standard protocol for exchanging system facts [ISO 19506] were also derived from this case study. We outline the common content that describes various runtime platforms. Affordable system evaluations depend on the availability of such content for import into the project preparation phase in order to build a comprehensive baseline system model with sufficient assurance that all the primitive system facts have been correctly recognized.
Then we illustrate how the baseline system model is enhanced with the system architecture information and how traceability links are created between the cybersecurity content, such as the elements representing the information assets of the system of interest, and the baseline system facts, such as the tables in the relational database that implement some of the information assets.
We illustrate the development of the assurance case and focus on specific goals describing the evaluation of one security functional requirement, the so-called unobservability property that corresponds to several specific security threats. We show how the goals of the assurance case are systematically developed based on the characteristics of the property, and we consider how they guide the security analysis and evidence collection for the assurance case. The online appendix to this book contains further examples of analysis and evidence gathering for the case study, using KDM-compliant tools.
12.2. Background
The system of interest is called Clicks2Bricks. It is a fictitious system developed by a fictitious company called Cyber Bricks Corporation. Here is the background information. Cyber Bricks is a privately owned company whose business is in the area of the innovative devices called cyber bricks. Cyber Bricks Corporation offers innovative products and services. Their flagship product is iBrick. Cyber Bricks is also the supplier of the iBrickWall product. The RoadToBricks service is another very successful offer by Cyber Bricks. The online iMortar store is closely integrated with both the iBrick and the iBrickWall products and has gained significant popularity over the last nine months.
In order to establish leadership in this new application of cyber bricks, the company decided to launch a website to support the growing online community of suppliers and clients. The new system, called Clicks2Bricks, will work as a marketplace for the suppliers and clients to keep track of the current products and needs. The community will also include service providers who can deliver value-added services based on products. The objective of Cyber Bricks is to promote interoperability between available solutions, identify the gaps, and publish value-added content related to cyber bricks, publish this content on the dedicated interactive website, and support the online user community. The initial version has limited functionality, and focuses on the quality content related to the benefits of the entire cyber bricks community.
12.3. Concepts of operations
This section contains the CONOPS for the Clicks2Bricks interactive Web information system, version 1.0.
12.3.1. Executive summary
This section provides basic information regarding the operation of the Clicks2Bricks interactive Web system, developed by the Cyber Brick Corporation. This section includes a description of the Clicks2Bricks system, including connection details; data sensitivity information; access limitation to the Clicks2Bricks software and hardware; the user community for the Clicks2Bricks system and its related equipment; and personnel or positions responsible for the operation, administration, and maintenance of the Clicks2Bricks system. This document is the basis for security recommendations.
12.3.2. Purpose
The purpose of the Clicks2Bricks system is to support the needs of the growing online community of users. The Clicks2Bricks system will facilitate information exchanges within the cyber bricks community. This initial version of the Clicks2Bricks system has limited functionality. The system allows a user to create an online profile (which includes a login and associated used data). The Clicks2Bricks system allows users to read the online content, allows customers to search for available products and service offerings, allows suppliers to input information about their products and service offerings, and allows service providers to input information about their services. The customer can enter a request for certain capabilities, and the suppliers will describe a portfolio of products and services to match his or her unique needs. The customer can then place an order to acquire the desired capabilities. The Clicks2Bricks system allows adding value-added content to the Clicks2Bricks system. The administrator of the Clicks2Bricks community manages content and users. The information processed and generated by Clicks2Bricks systems is unclassified. The system collects information about the registered users; this information is designated protected.
The diagram shown in Figure 1 provides a high-level illustration of the operations of Clicks2Bricks. The numbers represent the typical sequence of the transaction flows through the system.
 |
| Figure 1 The operational concept for Clicks2Bricks system |
12.3.3. Locations
The Clicks2Bricks system will consist of a server located in the Marketing Department Area of the Cyber Bricks Office Building A, with a dedicated database server located in the Data Center Area, Building A. Users will access the system through the dedicated fiber optics line provided to the Building A by Jolly Byte Stream Internet Service Provider. The SMTP server is located in the Data Center Building A. Employees of Cyber Bricks access Clicks2Bricks system from desktop and laptop computers through connections in the Marketing Department Area, Building A. Users access Clicks2Bricks over the Internet.
12.3.4. Operational authority
The Operational Authority for this system is the Marketing Department of Cyber Bricks Corporation. The server software and hardware are owned, maintained, and managed by the Department of Engineering of Cyber Bricks Corporation.
The Information System Security Office (ISSO) for the Clicks2Bricks system is designated by the Chief Security Officer of Cyber Bricks. The responsibilities of the Clicks2Bricks ISSO are identified in Cyber Bricks Security Policy.
12.3.5. System architecture
The Clicks2Bricks system consists of a Web server running a Clicks2Bricks application and the dedicated database server (See Figure 2). The server will run on the Linux operating system. The unstructured online content is stored in the local directory managed by the Web server. The structured data will run off a dedicated database server running open source database management system MySQL on the Linux operating system. The system will be connected to the Internet through a firewall.
 |
| Figure 2 The system architecture for Clicks2Bricks |
12.3.5.1. Clicks2Bricks web server
The Web server processes requests from users of the Clicks2Bricks system through the listening HTTPS port. Clicks2Bricks provides limited services to anonymous unregistered users over the HTTP port, which allows them to browse the Welcome page and some general-purpose content stored at the local disk of the Web server. The Web server processes login requests from registered users and establishes secure sessions during which multiple requests are processed. The registered user is allowed to browse subscription content and add subscription content, based on the registered user's access rights. Requests for the subscription content are processed by the database server.
12.3.5.2. Database server
The database server of the Clicks2Bricks system processes requests for subscription content and allows modification of the subscription content. The database server also contains personal information about the registered users of the Clicks2Bricks system.
12.3.5.3. SMTP server
The Clicks2Bricks system uses the internal SMTP server to send e-mail notifications to the registered users, and to the administrator.
12.3.6. System assumptions
1. The Clicks2Bricks application will be installed on the server that has been secured to current industry guidelines. Current security patches for the server must be installed.
2. The Clicks2Bricks website will use the database server that has been secured to current industry guidelines. Current security patches to the database server must be installed.
3. The database server should be protected from direct access from the Internet by a firewall.
4. The Clicks2Bricks application should be protected from direct access (except for the HTTP and HTTPS ports) from the Internet by a firewall.
5. Communication between the Clicks2Bricks Web server and the database server should be conducted over a private network.
12.3.7. External dependencies
1. The Clicks2Bricks system depends on the security of the operating system of the server it is installed on.
2. The Clicks2Bricks system depends on the security of the database server.
3. The Clicks2Bricks system depends on the security of the network between the Web server and the database server. If the network is compromised, sensitive data could be viewed or direct attacks on the database server could be made.
4. The Clicks2Bricks system depends on the session management of the Web server being secure. If the Web server's session management is not secure, an attacker might be able to hijack another user's session.
5. The Clicks2Bricks system depends on the external Simple Mail Transfer Protocol (SMTP) server to deliver notifications to users and administrators.
12.3.8. Implementation assumptions
1. Clicks2Bricks will use the open-source BareHttp Web server and will extend it with servlets to implement the business logic.
2. Clicks2Bricks system will not address any of the legal, contractual, and financial aspects of the information exchanges. These issues will be resolved by the other departments of Cyber Bricks. Clicks2Bricks will use an external SMTP server to deliver notifications that will integrate into the business processes of the corresponding departments.
12.3.9. Interfaces with other systems
1. The Clicks2Bricks system is connected to the Internet via the Jolly Byte Stream Internet Service Provider.
2. Clicks2Bricks uses the external SMTP server maintained by another department of Cyber Bricks Corporation.
3. Clicks2Bricks system is using the power supply of the Cyber Bricks Office Building.
12.3.10. Security assumptions
1. Personnel security: All employees and contractors of Cyber Bricks have passed through background checks. The Clicks2Bricks user community consists of the employees of the companies working in the cyber bricks industry. Users of the Clicks2Bricks system do not share a common requirement for access rights to the information.
2. Physical security: The servers, desktop computers, routers, and firewall are all located within the confines of Cyber Bricks establishments and are protected under local security orders. Servers, routers, and the firewall are located in the area with restricted access. The laptops used by several key personnel are mobile and can be used anywhere in the world. Use of these laptops and the information stored in them is protected by a password scheme. The installation media and backup media are stored in a secure off-site facility.
3. Procedural security: Information System Security Officers (ISSOs) are appointed for the overall system where the assets are installed and information is processed. The role of the ISSO is to provide security advice, to produce and maintain the security assurance case of the system, to coordinate security incident response, and to respond to security direction from the Chief Security Officer (CSO) of Cyber Bricks Corporation.
4. Information Technology security—The following highlights individual security features of the implemented Clicks2Bricks system's ITSEC facets.
Registration for the Clicks2Bricks system. Any user can submit a registration request; approval of the registration request follows a three-step process. First, the domain of the user needs to match the domain name of the company that the user claims to be employed by. Second, the dedicated contact person for the company is notified and has to confirm the identity of the user and the need to access information. Third, the administrator of the Clicks2Bricks system must grant access rights to the new user. Registration of the new companies subscribing to the Clicks2Bricks system is done manually by the administrator of the Clicks2Bricks system upon request and upon completion of the service contract.
Employees of the Cyber Bricks Corporation are authorized to access the Clicks2Bricks system by the administrator and the ISSO of Clicks2Bricks. In each case, formal access right approval is enforced.
Registered users are required to have login credentials that include a username and a password.
Transmission Security—Communication with the Clicks2Bricks system is performed over Secure Socket Layer.
12.3.11. External security notes
1. The Clicks2Bricks system has no password quality enforcement. Users and authors must choose strong passwords that are hard to guess or discover by brute force.
2. The Clicks2Bricks system must support HTTPS.
12.3.12. Internal security notes
1. All queries to the database are done using only one set of credentials—that of the Web server identity.
2. The Clicks2Bricks system makes use of an SMTP server on the internal network of Clicks2Bricks.
12.4. Business vocabulary and security policy for Clicks2Bricks in SBVR
The specific security requirements for the Clicks2Bricks system are determined by the following policy statements:
1. It is prohibited that the Clicks2Bricks system disclose any subscription content to an unregistered user.
2. It is prohibited that the Clicks2Bricks system disclose order items to an unauthorized user.
3. It is prohibited that the Clicks2Bricks system disclose the identity of a Clicks2Bricks customer to an unauthorized user.
4. It is prohibited that the Clicks2Bricks system accept content from an unregistered user.
Some context is required in order to understand these statements. This context can be defined by a linguistic model for Clicks2Bricks. Linguistic models introduced in Chapter 10 define the noun and verb concepts selected as a conceptualization of some possible worlds; they also state facts of what is necessary, permissible or obligatory in these worlds. Linguistic models provide the conceptual schema for a set of concrete facts, defining one possible world. This section shows the full description of Clicks2Bricks in SBVR, including the vocabulary of the terms specific to the operations of Clicks2Bricks and definitions of the security policy as business rules on top of the Clicks2Bricks vocabulary. The security requirements use the specific vocabulary that is shared by the semantic community of the Clicks2Bricks system. This is the community of interest that includes the stakeholders of Clicks2Bricks, people who are involved with Clicks2Bricks in a multitude of ways. This vocabulary is expressed in English (as presented in this example). However, there is another version of the Clicks2Bricks vocabulary that expresses the same set of concepts in German. It is used by the German-speech subcommunity of the Clicks2Bricks semantic community. The German version of the vocabulary that expresses the same set of concepts is likely to be included in the German language edition of this book.
| Cyber brick | |
| Definition: | a fictitious product |
| Note: | for many a cyber brick is simply a pile of zeros and ones, but when installed professionally it turns into the most powerful information systems in cyberspace |
| Description: | identified for the purpose of this case study as the foundation of a vibrant business ecosystem |
| Cyber Bricks Corp | |
| Definition: | a fictitious company whose business is related to cyber bricks |
| Company | |
| Definition: | a legally recognized organization designed to provide goods or services, or both, to consumers, businesses and governmental entities |
| Source: | Steven M. Sheffrin (2003). Economics: Principles in action. Upper Saddle River, New Jersey 07458: Pearson Prentice Hall. pp. 29. ISBN 0-13-063085-3 |
| Reference scheme: | nameof the company |
| Companyhasname | |
| Companyhasaddress | |
| Companyoperates atlocation | |
| Companyemploysperson | |
| Synonym: | personis employed bycompany |
| Productis acquired bycompany | |
| Note: | the common usage of this verb phrase also includes acquisition of products by persons or by noncommercial organizations |
| Person | |
| Definition: | an individual human being that has legal rights and duties |
| Reference scheme: | nameof the person |
| Reference scheme: | nameof the personandbirthdateof the person |
| Reference scheme: | nameof the personand address of the person |
| Reference scheme: | nameof the personandemail addressof the person |
| Personhasname | |
| Personhasaddress | |
| Personhasbirthdate | |
| Personhasemail address | |
| Product | |
| Definition: | an article or substance that is related to cyber bricksand is manufactured or refined for sale |
| Synonym: | goods |
| Reference scheme: | product-id |
| Productis manufactured bycompany | |
| Synonym: | companymanufacturesproduct |
| Note: | for the purposes of this case study, this also includes transforming raw material into products or refining products for the purpose of selling them |
| Productis supplied bycompany | |
| Synonym: | companysuppliesproduct |
| Note: | a product may be supplied by a different company than the manufacturer of the product |
| Productis shipped bycompany | |
| Synonym: | companyshipsproduct |
| Note: | a product may be shipped by a different company than that the supplier of the product |
| Productis supplied tocompany | |
| Synonym: | productis sold tocompany |
| Synonym: | companyacquiresproduct |
| Note: | the common usage of this verb phrase also includes sale of products to persons or to noncommercial organizations |
| Note: | acquisition of product is beyond the scope of this vocabulary |
| Companyordersproduct | |
| General concept: | Operation |
| Note: | Usually, the order of product by a company causes the delivery of the product to the company. The product is supplied by the supplier of the product and is delivered by the shipper |
| Note: | Usually, the shipment is associated with the transfer of ownership to the product from the supplier to the company that acquired the product and the remuneration from the acquirer of the product to the supplier. |
| Note: | The remuneration to the shipper is done either by the supplier or by the acquirer of the product |
| Manufacturer | |
| Definition: | a companythatmanufacturesproduct |
| Supplier | |
| Definition: | a companythatsuppliesproduct |
| Shipper | |
| Definition: | a companythatshipsproduct |
| Customer | |
| Definition: | a companythatordersproductoracquiresproduct |
| Acquirer | |
| Definition: | a companythatacquiresproduct |
| Employer | |
| Definition: | a companythatemploysperson |
| Employee | |
| Definition: | a personthatis employed bycompany |
| Document | |
| Definition: | a piece of written, printed, or electronic matter that provides information or evidence or that serves as an official record. |
| Product listing | |
| Definition: | a documentthatdescribesproduct |
| Reference schema: | item-id |
| Productis listed bysupplier | |
| Synonym: | Productis listed on behalf ofsupplier |
| Synonym: | Supplierlistsproduct |
| Necessity: | the product listingthat is listed on behalf of a supplieris supplied bythesupplier |
| Product listingdescribesproduct | |
| Product listinghasitem-id | |
| Productis listed bypersonon behalf ofsupplier | |
| Synonym: | Personlistsproducton behalf ofsupplier |
| Necessity: | thepersonthatlistsaproducton behalf ofsupplieris employed bythesupplier |
| Request for solution | |
| Definition: | a documentthat describes a business need and enumerates the list of requirements that should be satisfied by a solution |
| Reference scheme: | request-id |
| Request for solutionhas request-id | |
| Request for solutionis issued bycustomer | |
| Synonym: | customerissuesrequest for solution |
| General concept: | Operation |
| Request for solutionis issued bypersonon behalf ofcustomer | |
| Synonym: | personissuesrequest for solutionon behalf ofcustomer |
| Necessity: | the personthatissues a request for solutionon behalf of a customer is employed by the customer |
| Solution | |
| Definition: | a documentthat is issued by a supplier in response to a request for solution and that enumerates the set of products that address the need of the customer |
| Reference scheme: | solution-id |
| Solutionhassolution-id | |
| Solutionaddressesrequest for solution | |
| Possibility: | Request for solutionis addressed byzero or moresolutions |
| Solutionincludessolution item | |
| Solution iteminvolvesbusiness item | |
| Solutionis issued bysupplier | |
| Synonym: | supplierissuessolution |
| General concept: | Operation |
| Solutionis issued bypersonon behalf ofsupplier | |
| Synonym: | Personissuessolutionon behalf ofsupplier |
| Necessity: | thepersonthatissuesasolutionon behalf ofasupplieris employed bythesupplier |
| Order | |
| Definition: | a documentthatis issued byacustomerthatinvolves the set of productsthat thecustomerintends to acquire |
| Reference scheme: | order-id |
| Possibility: | orderinvolveszero or moreproducts |
| Necessity: | orderinvolvesat least oneproduct |
| Orderincludesorder item | |
| Synonym: | order itemis part oforder |
| Order item | |
| Definition: | documentthatis part of an orderand thatinvolvesaproductthat thecustomerthatissuedtheorderintends to acquire |
| Order itemis delivered tolocation | |
| Order iteminvolvesbusiness item | |
| Order itemis shipped byshipper | |
| Orderis issued bycustomer | |
| Synonym: | Customerissuesorder |
| General concept: | Operation |
| Orderis issued bypersonon behalf ofcustomer | |
| Synonym: | personissuesorderon behalf ofcustomer |
| Necessity: | thepersonthatissuesanorderon behalf ofacustomeris employed bythecustomer |
| Notification | |
| Definition: | a documentthatnotifies the recipientabout a business event |
| Personreceivesnotification | |
| Synonym: | notificationhasrecipient |
| Personis notified aboutbusiness event | |
| Designated contact person | |
| Companyhasdesignated contact person | |
| Product listing notification | |
| Definition: | notificationaboutlisting a productby a supplier |
| General concept: | Notification |
| It is obligatory that thedesignated contact personof a companyis notifiedif a product is listed on behalf ofthecompany | |
| Issuing solution | |
| Definition: | business eventthatcorresponds totheactualitythat asolutionis issued byasupplier |
| General concept: | business event |
| Solution notification | |
| Definition: | notificationaboutissuing solution by a supplier |
| General concept: | Notification |
| It is obligatory that thedesignated contact personof the companyis notified onissuing solutionthataddresses the request for solutionthatis issued bythecompany | |
| Ordering | |
| Definition: | business eventthatcorresponds totheactualitythat anorderis issued byacustomer |
| General concept: | business event |
| Orderinginvolvesbusiness item | |
| Definition: | orderinvolves an order itemand theorder iteminvolvesbusiness item |
| Order notification | |
| Definition: | notificationabout issuinganorderbyacustomer |
| General concept: | Notification |
| It is obligatory that thedesignated contact personof a companyis notified onorderingthatinvolvesabusiness itemthatis supplied bythecompany | |
| Clicks2Bricks | |
| Definition: | a fictitious information systemthatis developed byCyber Bricks Corp |
| Employee of Cyber Bricks | |
| Definition: | a personthatis employed by Cyber Bricks |
| General concept: | person |
| Concept type: | role |
| Administrator | |
| Definition: | an employee of Cyber Bricksthatis responsible for the operations ofClicks2Bricks |
| Concept type: | role |
| Analyst | |
| Definition: | an employee of Cyber Bricksthatanalyzessubscription content of Clicks2Bricks andmaintainsopen pages |
| Concept type: | role |
| Database administrator | |
| Definition: | an employee of Cyber Bricksthatmanages the database server of Clicks2Bricks |
| Concept type: | role |
| Security officer | |
| Definition: | an employee of Cyber Bricksthatmanages security ofClicks2Bricks |
| Concept type: | role |
| registered Customer | |
| Definition: | companythatis registered to Clicks2Bricks as customer |
| General concept: | company |
| Note: | it is assumed that there is no need for a company to play both roles |
| It is prohibited that acompanythatis a registered Supplieris a registered Customer | |
| Registered customerhasidentity | |
| Identityof aregistered customer | |
| Definition: | any document that identifies a registered customer by disclosing the characteristics of the company |
| General concept: | Document |
| Identityofregistered customerinvolvesnameofthecustomer | |
| Identityofregistered customerinvolvesaddressofthecustomer | |
| Identityofregistered customerinvolveslocation at which thecustomeroperates | |
| registered Supplier | |
| Definition: | companythatis registered to Clicks2Bricks as supplier |
| General concept: | company |
| Note: | it is assumed that there is no need for a company to play both roles |
| It is prohibited that acompanythatis a registered Customeris a registered Supplier | |
| Userinteracts withClicks2Bricks | |
| User | |
| Definition: | a personor a computer systemthatinteracts with the Clicks2Bricks |
| General concept: | thing |
| Concept type: | role |
| Anonymous user | |
| Definition: | a userthathas not presentedlogin credentialstoClicks2Bricks |
| General concept: | user |
| Userregisters toClicks2Bricks | |
| Registration notification | |
| Definition: | notificationaboutaregistrationbyauser |
| General concept: | Notification |
| Registering | |
| Definition: | a business eventthatcorresponds to the actualitythat a userregisters toClicks2Bricks |
| General concept: | business event |
| It is obligatory thatadministratoris notified onregisteringby a usertoClicks2Bricks. | |
| It is obligatory thatdesignated contact personof acompanyis notifiedif auserregisters toClicks2Bricksanduserclaims to be employed bythecompany. | |
| Personapprovesregistration | |
| Definition: | personthatis a designated contact person for acompanyapprovesregistrationofanyuserthatclaims to be employed bythecompany |
| Registrationis approved | |
| Definition: | theactualitythatpersonapproves the registration |
| Userreceiveslogin credentials | |
| It is obligatory thatuserreceiveslogin credentialsif the registration of the user is approved | |
| Registered user | |
| Definition: | a personthathaslogin credentials for Clicks2Bricks |
| General concept: | person |
| Note: | registered user is associated with employer |
| Necessity: | registered user is associated with exactly one employer |
| Note: | the actions of a registered user may be performed on his behalf by a computer system. Nevertheless these actions are attributed to a particular person and the employer of this person |
| Registered userhasidentity | |
| Identityof aregistered user | |
| Definition: | any document that identifies the user by disclosing the characteristics of the person |
| General concept: | Document |
| Identity of registered userinvolvesname | |
| Identity of registered userinvolvesaddress | |
| Identity of registered userinvolvesbirthdate | |
| Identity of registered userinvolvesemail address | |
| Subscription content | |
| Definition: | documentthatis issued to Clicks2Bricks byaregistered customeror aregistered supplier |
| Open pages | |
| Definition: | documentthatis issued to Clicks2Bricks byananalyst |
| Userissuesdocumentto Clicks2Bricks | |
| Useris qualified to issuedocument | |
| Definition: | useris qualified to issuedocumentto Clicks2Bricks if theuseris registeredand theuserisaregistered supplierand theuserissuesaproduct listingor asolutionor theuserisaregistered customerand theuserissuesarequest for solutionor anorder |
| Unqualified user | |
| Definition: | userthatisnotqualified to issueadocument |
| Clicks2Bricksacceptsdocumentfromuser | |
| It is prohibited that Clicks2Brick acceptsdocumentfromanunqualified user | |
| UseraccessesdocumentfromClicks2Bricks | |
| Synonym: | documentis disclosed touser |
| Contentis issued byuser | |
| Definition: | documentis issued byuser1ifuser1addedthedocumenttoClicks2Bricksor someuser2addedthedocumenttoClicks2Bricksanduser2is employed byacompanyanduser1is a designated contact person ofthecompany. |
| Useris authorized to accessdocument | |
| Definition: | useris authorized to accessdocumentif theuseris registeredand |
| thedocumentis issued byuseror | |
| thedocumentisasolutionor | |
| thedocumentisaproduct listingor | |
| thedocumentisarequest for solutionor | |
| thedocumentisanorder itemthatinvolvesaproductthatis supplied bytheemployeroftheuser | |
| Clicks2Bricksdisclosesdocumenttouser | |
| Unauthorized user | |
| Definition: | userthatisnotauthorized to accessdocument |
| Unregistered user | |
| Definition: | userthatisnot aregistered user |
It is prohibited that Clicks2Bricks discloseanysubscription contenttoanunregistered user.
It is prohibited that Clicks2Bricks discloseidentityofaregistered customertoanunauthorized user.
It is prohibited that Clicks2Bricks discloseidentityofaregistered usertoanunauthorized user.
The SBVR description of the operational vocabulary and rules for Clicks2Bricks identifies the vocabulary of the system-specific facts to describe operational snapshots of the Clicks2Bricks (descriptions of the business objects, actors, and business operations). The full linguistic model usually defines a larger set of concepts than required for the operational fact model, but it includes the operational conceptual schema as a subset because many statements about the system refer to its business entities and operations (but many also include other concepts, in particular those related to the management and governance life-cycle processes). When the operational conceptual schema is identified, the formal SBVR descriptions can be used to automatically build a rough prototype of the system because formal SBVR definitions contain enough information to generate the database structure to store the snapshot of the operational facts, the stored procedures for the operational queries and updates corresponding to the operation, and even a prototype user interface. This process is valuable for the stakeholder requirements definition phase and the requirements analysis phase. This use of SBVR is outside the scope of this book. Later in this chapter we will show how the Clicks2Bricks vocabulary is imported into the integrated system model to support security analysis and evidence gathering for the assurance case. The vocabulary of Clicks2Bricks is part of the system facts, in addition to the operational and systems viewpoints, introduced in Chapter 4. Other viewpoints relevant for assurance where introduced in Chapter 5, Chapter 6 and Chapter 7 and summarized at the end of Chapter 9. SBVR was used to describe these viewpoints at various degrees of formality. SBVR linguistic models describe all relevant system views, from business/operational facts that correspond to business transactions, to the facts describing the behavior and structure of the business processes, to behavior and structure of the systems that enable the business processes. SBVR descriptions focus on the conceptualizations and statements of what is necessary, permissible and obligatory in the worlds described by the conceptualization. So, SBVR is used to express all common vocabularies for cybersecurity, introduced in this book.
12.5. Building the integrated system model
The process of building the system model has been described in Chapter 3 and Chapter 11. In this section we provide some highlights of how this process is applied to Clicks2Bricks. We will use the fact-oriented process and assume a KDM-compliant fact-based repository to store the views of the system [ISO 19506].
12.5.1. Building the baseline system model
The first step in building the baseline system model is to create the KDM Inventory view of the system. This is a purely physical view of the system's artifacts without any regard to their logical organization. Elements of the Inventory view provide the initial set of “locations” in the system of interest. This view is essential to assure completeness of the baseline models, since the coverage of other views can be validated against the Inventory view. Next we show a fragment of standard KDM XML representation of the inventory facts described in Chapter 11. This XML file [XMI] can be used as a further illustration of the methodology of developing information exchange protocols for the OMG Assurance Ecosystem, described in Chapter 8 involving a seamless transformation between a vocabulary in SBVR, its illustrations using conceptual UML diagrams, and the physical XML format for exchanging facts.
<?xml version=“1.0” encoding=“UTF-8”?>
<kdm:Segment xmi:version=“2.1”
xmlns:xmi=“http://schema.omg.org/spec/XMI/2.1”
xmlns:kdm=“http://schema.omg.org/spec/KDM/1.2/kdm”
xmlns:source=“http://schema.omg.org/spec/KDM/1.2/source” name=“Clicks2Bricks Inventory Fragment”>
<model xmi:id=“id.0” xmi:type=“source:InventoryModel”>
<inventoryElement xmi:id=“id.1” xmi:type=“source:Directory” name=“clicks2bricks”>
<inventoryElement xmi:id=“id.2” xmi:type=“source:Directory” name=“org”>
<inventoryElement xmi:id=“id.3” xmi:type=“source:Directory” name=“savarese”>
<inventoryElement xmi:id=“id.4” xmi:type=“source:Directory” name=“barehttp”>
<inventoryElement xmi:id=“id.5” xmi:type=“source:SourceFile” name=“HTTPServer.java” language=“java 1.5” encoding=UTF=8”/>
<inventoryElement xmi:id=“id.6” xmi:type=“source:SourceFile” name=“HTTPSession.java” language=“java 1.5” encoding=“UTF-8”/>
<inventoryElement xmi:id=“id.7” xmi:type=“source:SourceFile” name=“Main.java” language=“java 1.5” encoding=“UTF-8”/>
<inventoryElement xmi:id=“id.8” xmi:type=“source:SourceFile” name=“Request.java” language=“java 1.5” encoding=“UTF-8”/>
<inventoryElement xmi:id=“id.8” xmi:type=“source:SourceFile” name=“overview.html” language=“generic html” encoding=“UTF-8”>
<inventoryRelation xmi:id=“id.10” xmi:type=“source:DependsOn” to=“id.4” from=“id.8”/>
</inventoryElement>
</InventoryElement>
</InventoryElement>
</InventoryElement>
</inventoryElement>
</model>
</kdm:Segment>
Additional relations between the artifacts and their role in the system are understood when the build instructions for the system of interest are identified and analyzed, resulting in the creation of Build views. All KDM views beyond the Inventory view describe the logical and conceptual organization of the system, so they require compiler-like knowledge extraction tools that understand the syntax and semantics of the system artifacts. For example, the Build view is often created by analyzing the so-called makefiles for the Unix “make” utility. Several other build automation utilities are available, each supporting its own format of the build configuration files. Affordable system assurance relies on the availability of knowledge extractor tools supporting various off-the-shelf and proprietary formats and languages, so that the baseline model can be assembled in a timely fashion. The OMG Assurance Ecosystem emphasizes a standard protocol in which compiler-like tools can export relevant system facts for the purpose of integration into the system model.
The next steps in building the baseline system model involve identification of the programming languages (or machine code formats), the data description languages, and the user interface elements. As a result, the Program Elements, Data, and UI views are created. Several examples of these views are provided in Chapter 11.
The last phase of creating the baseline system model involves identifying elements of the runtime platform and creating the Platform views. Usually, Platform views are created by using the Program Element views as one of the inputs to analyze the platform APIs and libraries, and to apply the platform patterns for generating the corresponding facts that complete the control and data flows of the system of interest. This is a critical step that usually requires a backing assurance argument, since it is responsible for the soundness of the security analysis, as described in Chapter 3 and defined in the generic assurance case goals.
Several examples of Platform views have been provided in Chapter 11. Let's consider the “ThreadPoolExecutor” example. Chapter 11 illustrated potential loss of important facts, and the corresponding loss of soundness of the analysis from insufficient consideration of the control flows defined by the runtime platform. When only the semantics of the Java programming language was considered, the classes HTTPServer, Server, and Session appeared disconnected, and the “Call” methods of classes Server and Session appeared unused. Only when the additional platform resource and the corresponding platform actions are identified and added to the model does it become possible to identify system behaviors and functions, as illustrated in Chapter 11 in the sections on the Event viewpoint and Behavior viewpoint. Otherwise, the system model is not sound for the detailed cause and effect analysis, required for the Architecture Security Analysis, described in Chapter 3.
The particular situation involving the ThreadPoolExecutor is described by the following informal pattern:
• Library: java.util.concurrent
• API: ThreadPoolExecutor, ThreadPoolExecutor::submit
• Maps to KDM resource: ExecutionResource ThreadPoolExecutor (the full identity of this element is determined by the call to the constructor of the class)
• Each call to the submit method must be supported by a unique ActionElement (referred to as an “abstracted action”) contained in the corresponding ThreadPoolExecutor resource, a Calls relationship from the original submit ActionElement to the abstracted action, and another Class relationship from the abstracted action to the method “call” of the class, that is submitted to the ThreadPoolExecutor as the first actual parameter
These patterns represent valuable content for building system models both cost-efficiently and with sufficient assurance. Guidance on using SBVR to formalize such patterns on top of the standard protocol for exchanging system facts was provided in Chapter 10 on Linguistic Models. These patterns are then imported into generic platform knowledge discovery tools to build the Platform views for the system of interest. In Chapter 8 this import was described as the content import protocol of the OMG Software Assurance Ecosystem. Further assurance for the soundness of the system model is provided by cross-analyzing the Inventory views, the Program Element views, and the platform patterns applied, to validate the coverage of all libraries and APIs used in the code of the system.
12.5.2. Enhancing the baseline model with the system architecture facts
The baseline system model, consisting of the Code views, Data views, User Interface views, and Platform views, must be further enhanced to match the level of granularity at which the assurance case is formulated and at which most of the cybersecurity knowledge exists. Within the framework of the standard protocol for exchanging system facts, this is done by adding the corresponding elements of the KDM Abstraction Layer into the integrated system model and establishing the vertical traceability links from the new elements to the existing low-level elements of the baseline system model. The system fact discovery phase includes five steps: adding structure elements, adding functional elements, identifying entry points, adding linguistic elements, and adding rule elements. Enhanced system facts use KDM Structure views, KDM linguistic views, KDM behavior views, and KDM event views. Several examples have already been provided in Chapter 11, when the corresponding KDM views were presented.
System structural elements (subsystems, architectural layers, components, etc.) are identified in the CONOPS document and more detailed architecture description documents. There is a growing trend for system engineering projects to use machine-readable architecture repositories (this is one of the reasons we used DoDAF as an example in Chapter 4). Machine-readable architecture artifacts, such as SysML models, can be imported into the integrated system model and then linked with the baseline facts. In Chapter 8 this import was described as the concrete knowledge discovery protocol. Note, that a SysML or a UML architecture model, while machine-readable, is not fact-oriented, as its foundation is a class with properties and attributes. In order to import information from a SysML or a UML model into a fact-based repository, the corresponding vocabulary of noun and verb concepts must be identified, as described in Chapter 4 and then the properties of classes must be decomposed into elementary verb concepts. The noun concepts of the fact-oriented approach do not have any attributes. Alternatively, high-level structure components can be discovered in the code by a bottom-up process—modeling in reverse—where the analyst reviews the system using the baseline views, rationalizes the organization of elements, and identifies high-level subsystems. This way, the implementations of subsystems are identified first, the new KDM elements are entered second, and the traceability links are established last. When existing machine-readable architecture elements are imported, the new KDM elements are created first, then the analyst identifies their implementations and creates traceability links. The latter is a more efficient process. On the other hand, there are various elements of guidance to identification of the high-level structure in the Inventory and Code views themselves.
Similar notes apply to the functional elements and linguistic elements. SBVR vocabulary can be imported into the integrated system model. In particular, the key terms of the SBVR vocabulary, the ones corresponding to the operational conceptual schema subset of the full linguistic model, are represented as KDM TermUnit and FactUnit elements and connected to the implementation elements by the vertical traceability links. The resulting facts are illustrated in Chapter 11, in the section on Linguistic views.
Let's first look at an example of how a structure model, like the one presented in Chapter 11, in the section on the Structure viewpoint, can be discovered bottom-up by using the baseline model. To begin with, the Code view already contains initial information about the structure of the system, which makes review and manipulation of the Code view very efficient, but which may or may not be relevant to the logical architecture of the system. We are talking about the physical organization of files into directories and packages. The KDM Code view captures these facts. You have already noticed that the KDM views involve many facts with the designator “contains” and “is implemented by.” These facts define the hierarchies of system elements. For example, Figure 3 illustrates what the top elements of the Code view from the baseline model for Clicks2Bricks look like. The nodes at the diagram are KDM Package elements, corresponding to the top-level Java packages. The nodes with the names “ENV:SRC” and “ENV:SNK” represent the rest of the system (the environment of the current diagram).
 |
| Figure 3 A view of the top-level Java packages in Clicks2Bricks |
The entire hierarchy can be reviewed one level at a time (see Figure 4). Here, the “org” package contains two packages: “apache” and “savarese”, and the “savarese” package contains individual classes (the class diagram at the third level of the hierarchy is presented in Chapter 11; see the section on the Code viewpoint).
 |
| Figure 4 The Hierarchy of Java packages in Clicks2Bricks |
So, even when the analyst is working bottom-up to discover high-level elements of software systems, he works with a manageable hierarchically organized model.
One can make a query to the KDM fact repository to select all leaf packages (the ones that do not contain further packages) and show them in one view. This view is illustrated in Figure 5. Each node represents a leaf package (containing no further packages). The four highlighted nodes are application packages.
 |
| Figure 5 A view of all leaf Java packages in Clicks2Bricks |
This view strongly suggests that the Clicks2Bricks system uses a Model-View-Controller architecture, based on the names of the packages and the fabric of relationships to the platform packages, such as “net,” “apache,” “servlet,” “io,” and “sql.”
The hierarchy of the baseline Code view is defined by the “contains” facts, which identifies the single parent “defining” hierarchy of each Code element (e.g., a MethodUnit is contained in one and only one ClassUnit). On the other hand, the new view is an ArchitectureView element in a Structure view which uses “is implemented by” facts that are many-to-many relationships between different levels of granularity. As a result, the “barehttp” package can be linked to mutiple hierarchies. For the above illustration we have created a new Structure view called “All leaf packages” with a single ArchitectureView element with the name “package view.” The elements in the above diagram are “implementations” of the “package view.” Let's create another view called “application packages,” containing only application packages (see Figure 6).
 |
| Figure 6 View of the application packages in Clicks2Bricks |
The package “barehttp” is related to the new element “application packages” as “is implemented by” relationship (not visible at the diagram, and only available in the KDM fact base).
The next logical step is to create a Structure view with the Model, View, and Controller subsystems like the one illustrated in Chapter 11 in the section on the Structure viewpoint.
Relationships in the above views are the so-called KDM aggregated relationships. They do not correspond to separate verb concepts; instead, they are aggregations of the low-level relationships as follows. The relationship between the node “barehttp” and the node “servlets” represents all low-level relationships, where the source “is contained” in the “barehttp” node, and the target “is contained” in the “servlets” node. The “is implemented by” relationship also determines aggregated relationships, in the same way as “contains.” In other words, there are two unique locations in the entire code base of the Clicks2Bricks system, where the first location is in one of the elements (transitively) contained in the “barehttp” package and where the second location is in one of the elements (transitively) contained in the “servlets” package. A query to the KDM fact-based repository can list these locations by using the standard links to the source code. The two locations are illustrated below as fragments of source code, both in the class “HTTPSession,” one in the method “processServletRequest” and another one in the static initialization of class members (as illustrated at Figure 7).
 |
| Figure 7 Aggregated relationships provide traceability links |
KDM views support assurance analysis through the mechanism of “environment.” All KDM views are “closed” and contain information about the entire fact base in the following sense: Each KDM view is capable of showing the aggregated relationships to the nodes within the current view from the rest of the system (ENV:SRC) and from the nodes of the current view to the rest of the system (ENV:SNK). Thus, the above diagram supports the claim that “package servlets” is not used by any other package except the package “barehttp.” KDM has the following important property: not only an aggregated relationship in a KDM view is the evidence of a dependency between two elements, but also the absence of an aggregated relationship is the evidence of the lack of dependency between the two elements.
12.6. Mapping cybersecurity facts to system facts
The next step in the assurance project is to identify cybersecurity elements such as trust levels (the categories of external actors), assets, threat events, and threats and to map them to the system model by creating the new elements and establishing the traceability links to existing elements of the integrated system model. Cybersecurity elements are represented by a separate vocabulary described in Chapter 5 that is not part of the standard protocol for exchanging system facts. However, the system facts are the “locations” with which the assets, threat events, and other components of the “security threat” are associated. Adding these elements to the integrated system model is the process of fact-based integration.
Here are some information assets for Clicks2Bricks:
| A1-1. User's login credentials | |
| Description: | The user's login credentials: username and password |
| Trust level: | TL2 Remote user with login credentials |
| A1-4. Customer's identity | |
| Description: | According to the Clicks2Bricks security policy, customer's identity shall be available only to supplier through order addressed to that supplier or to the employees of the customer. Identify of the customer includes the name of the company, the email address, the address, the requests issued by the particular customer, the user names of the registered users that are the employees of the particular customer and the orders issued by the particular customer. |
| Trust level: | TL3 Supplier |
| A1-6. Employee's personal data | |
| Description: | The personal data that the user enters such as contact information, the employer, etc. |
| Trust level: | TL2 Remote user with login credentials (only the user, the administrator and the designated contact person for the employer of the user) |
| A1-9. Orders | |
| Description: | Order is a document issued by customer. The order contains the list of products and services that the customer intends acquiring. Orders shall be available only to the corresponding suppliers. |
| Trust level: | TL3 Supplier |
These elements are added to the integrated system model by creating a new KDM Conceptual view importing each asset element as a new TermUnit, and creating relationships to the trust levels and the corresponding physical elements that implement each asset. Note that for some of the elements (such as “Order”) we only need to link it to the corresponding linguistic element, already imported from the SBVR vocabulary. TermUnits representing assets are collected in a separate Conceptual view with the name “assets.” More elaborate vocabulary integration can be achieved by establishing “is an instance of” relationships from each asset TermUnit to a TermUnit with the name “asset” representing the concept “asset.”
Here are some threat events for Clicks2Bricks:
| C-1. Disclosure of User's login credentials | |
| Description: | |
| Asset: | A1-1 User's login credentials |
| C-5. Disclosure of User's personal data | |
| Asset: | A1-6 User's personal data |
| Consequences: | privacy, illegal in some jurisdictions; possible litigation; potential damage to the reputation of Cyber Bricks |
| C-6. Disclosure of Orders | |
| Asset: | A1-9 Orders |
| Consequnces: | violation of the contract with customers; possible loss of customer; possible loss of revenue; possible litigation |
These elements are also added to the integrated system model as KDM TermUnits and linked with the corresponding assets. Then a systematic analysis of the functional views of the system can be performed to identify the locations that can produce these threat events and “is implemented by” links established to the “threat event” elements.
Here are some threats to Clicks2Bricks:
| Threat 2: Disclosure of Login Information | |
| Name: | Adversary acquires another user's login credentials |
| Descriptions: | If an adversary obtains the login credential of another user, he can perform any task that user can. |
| Consequence: | Information disclosure, Elevation of privilege, Tampering |
| Entry points: | Login page, database stored procedures |
| Assets: | User's login data |
| Threat agent: | Hacker |
| Threat 3: Session Hijacking | |
| Name: | Adversary acquires the session ID of another user |
| Description: | If an attacker acquires the session ID of a logged-in user, he can perform any task that user can |
| Consequence: | Elevation of privilege |
| Entry points: | Web server listening ports (HTTP, HTTPS) |
| Assets: | Login session |
| Threat agent: | Hacker |
| Threat 4: User Data Disclosure | |
| Name: | Adversary retrieves another user's personal data |
| Description: | Disclosing another user's personal data raises privacy issues. Furthermore, the Clicks2Bricks would not be perceived as trustworthy. |
| Consequence: | Spoofing, Information disclosure |
| Entry points: | Web server listening ports (HTTP, HTTPS) |
| Assets: | User's personal information |
| Threat agent: | Hacker |
The “threat” elements are also added to the integrated system model as KDM TermUnits and linked with the corresponding assets, entry points, threat events, and threat agent elements. Once all threat and risk elements have been identified, a systematic analysis and validation of threats can be performed through the integrated system model using the combination of the assurance strategies outlined in Chapter 5.
Exactly the same approach is performed to identify safeguards.
As a result, the integrated system model contains all cybersecurity elements and can be used to manage all system assessment facts. The Common Fact Model and the standard protocol for exchanging system facts provide a uniform extensible and scalable environment for managing facts during the entire assessment project and making these facts available for efficient reevaluations and incremental operational risk analysis.
Information exchanges play an important role in making threat and risk identification systematic and efficient; these exchanges also allow additional assurance of the correctness of the results. The general content for the identification of the threats and risks is available in the form of risk analysis checklists, including asset categories, common injuries, threat classes, threat activities, threat agent categories and safeguard classes. This content, when made machine-readable, can be imported into the integrated system model to organize the individual entities (assets, threat events, threats, specific threat agents, and safeguards) into containers based on the generic categories.
The threat model is determined by the concept of operations, so the corresponding content can be developed concurrently with building the baseline system model. In Chapter 8, this was described as the general knowledge protocol of the OMG Assurance Ecosystem. However, the threat model and the baseline system model must be connected, because of the need to provide assurance that all system-specific threats have been addressed. This connection is established by the systematic architecture-driven threat identification approach, described in Chapter 5. On the other hand, vulnerability detection also connects the generic threat model to the baseline system model, as described in Chapters 6 and 7. Chapter 8 described this connection as the knowledge refinery protocol. In addition, system analysis is driven by the assurance claims and provides further connections between the baseline system model and the threat model by deriving intermediate facts that link the claims, and in particular the safeguard effectiveness claims, which use the vocabulary of the threat model, to the evidence, which eventually uses the vocabulary of the baseline system model. These considerations are essential to understanding of the general structure of the assurance case, described in Chapter 3 and its elaboration in the next section.
12.7. Assurance case
This section illustrates security assurance case [ARM 2010] and [SAEM 2010] for Clicks2Bricks as an illustration to Phase 3 of the System Assurance process described in Chapter 3. Figure 8 provides a simplified version of the top claim focusing on the satisfaction of the identified security requirements. In this case study we focus on a single security requirement, called the “unobservability” which is stated as follows: “the system shall ensure that all users/subjects are unable to observe any operation on any object/resource by any other user/subject”. Figure 9 presents the results of our linguistic analysis of this property to identify the noun and verb concepts involved to provide guidance to the development of the assurance case for this property. The first tier simply lists the original noun and verb concepts used in the formulation of the Unobservability property. The second tier maps these concepts onto the concepts available in the integrated system model. Figure 10 describes the top level assurance case for Unobservability. Figure 11Figure 12Figure 13Figure 14Figure 15 and Figure 16 elaborate the argument outlined in Figure 10 and provide the guidance for analysis of the system and evidence gathering. The online appendix to the book provides advanced technical examples of how the OMG Software Assurance Ecosystem tools are used to analyze the integrated system model and collect evidence to support this assurance case.
 |
| Figure 8 The top-level claims |
 |
| Figure 9 Analysis of the unobservability property |
 |
| Figure 10 Unobservability claims: G1-G10 |
 |
| Figure 11 Unobservability claims: G3 |
 |
| Figure 12 Unobservability claims: G4 |
 |
| Figure 13 Unobservability claims: G5 |
 |
| Figure 14 Unobservability claims: G6 |
 |
| Figure 15 Unobservability claims: G7 |
 |
| Figure 16 Unobservability claims: G8 |
The process of building confidence in security posture of cyber systems is a knowledge-intensive process. The OMG Software Assurance Ecosystem approach focuses at what knowledge is needed, how it is described, collected and exchanged in order to build confidence. Knowledge sharing is essential to the productivity of the organizations performing assessments, for the simple reason that it allows division of labor.
Assurance case organizes system analysis into several systematic, and coordinated goal-based activities. The elements of the assurance case are facts that are based on a certain conceptual commitment, involving a vocabulary of noun and verb phrases as well as statements of what is necessary, permissible or obligatory. The decomposition of the assurance claims into subclaims coincides with the refinement of this vocabulary, until the vocabulary of the leaf sub-claims is aligned with the vocabulary of the facts available in the integrated system model. System analysis supports this refinement of the vocabulary as it derives more comprehensive facts from the low-level system facts. In practice, the assurance case offers a semi-formal justification because the goals of the assurance case guide the analyst to perform the remaining system analysis to bridge the gap between the sub-claims and the elementary facts in the repository, rather than always work as fully-formal queries into the repository. So, assurance case is a practical tool to manage the system analysis process and communicate its results to the system stakeholders in a clear, comprehensive and defendable way.
System assurance is a lot similar to detective work, where most of the effort is spent on looking for evidence. Evidence gathering is guided by the assurance case where all evidence gathering activities are planned and their contributions to support of the assurance claims are made explicit. Assurance case brings clarity to presentation of the evidence and the corresponding system analysis findings because it explains why the evidence supports assurance claims. Assurance case is used to manage evidence items as they are gathered, explains any counter evidence and provides a rational justification why the security posture of the system is adequately strong and can be relied upon. Last but not least, assurance case documents the assumptions made, so that when the operational context changes, a re-evaluation can be done incrementally, so that all accepted risks will not accumulate unreasonably.
The OMG Assurance Ecosystem defines several standard protocols for exchanging knowledge for assurance. The foundation of these standards is the vendor-neutral and language-independent protocol for exchanging facts about systems – the Knowledge Discovery Metamodel. The OMG Assurance Ecosystem involves a rigorous approach to knowledge discovery and sharing where the individual knowledge units are machine-readable facts. These facts can be verbalized by human-readable statements in structured English and stored in efficient repositories or represented in a variety of machine-readable formats, including XML. Vendor-neutral protocol for describing system facts allows building and exchanging other machine-readable content for assurance, such as vulnerability patterns or descriptions of common platforms. The OMG vendor-neutral standards enable machine-readable content that can be unlocked from proprietary tools and can be developed and exchanged independently of its producers and consumers to allow evolution towards the industrialization of cybersecurity and taking advantage of the economies of scale. OMG Assurance Ecosystem is a step towards fact-oriented, repeatable, systematic and affordable assurance of cybersystems.
Bibliography
Object Management Group, Argumentation Metamodel (ARM). (2010) .
ISO/IEC 19508 Architecture Driven Modernization—Knowledge Discovery Metamodel. (2009) .
[KDM] Object Management Group, Knowledge Discovery Metamodel (KDM) 1.2. (2006) .
Object Management Group, Software Assurance Evidence Metamodel (SAEM). (2010) .
[SBVR] Object Management Group, Semantics of Business Vocabularies and Rules (SBVR) 1.1. (2009) .
[XMI] Object Management Group. XML Model Interchange (XMI)
[XML] W3C, Extensible Markup Language (XML) 1.0. 5th ed (2008) ; W3C Recommendation.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.