SOFIC (Security Ontology For Inter-Cloud) is a cloud security ontology defined in OWL2, which aims at modeling security assessments about Cloud services. These security assessments, obtained from monitoring, are meant to be shared between CSPs and customers to increase the global digital trust in the Inter-Cloud.

The ontology has been tested and validated, as it has been shown in the paper [DOI]. Such a research work provides a Trust Security and Decission Support System (Trust-DSS), which takes into account the security assessments about Cloud Services modeled in SOFIC, to assit customers and CSPs making security deductions, check security constraints, calculate security expectations and quantify trustworthiness about CSPs. In the end, the Trust-DSS allows to help establishing and managing securely federations and trust relationships among Cloud providers.

The SOFIC ontology is linked with the mOSAIC ontology in some points, i.e. the ontology imports mOSAIC in order to make some properties and classes to point to some classes already defined in mOSAIC. The mOSAIC ontology is one of the main outcomes of the mOSAIC FP7-ICT EU Project to describe Cloud resources and services as well as their (wrapped) interfaces. However, mOSAIC ontology does not actually focuses its attention on the description of the security aspects of Cloud computing, and consequently, lack of the taxonomy of the elements to represent security and privacy concerns. The SOFIC ontolgoy fills this gap modelling the main security and privacy concepts about Cloud Service Providers (CSPs) required when performing a Cloud security assessment.

SOFIC has been tailored extensible and open to improvements and changes from the research community and CSPs that may find it interesting to add new security parameters and metrics. Moreover, the ontology is based on the Cloud security concepts identified in different security standards and recommendations, such as NIST's special publication SP800-53 about security and privacy controls, the Cloud Security Alliance's Clouds Control Matrix or the ENISA's guide to monitoring security service levels in Cloud contracts.

The following figure shows and overview of the core components of the SOFIC ontology. Nodes represents OWL classes, directed spotted arcs represents OWL object properties, with Domain in the tail of the arc and Range in the head. Solid lines represent the OWL subclassOf property which indicates inheritance of the class in the target node from the one in the source.

A SecurityAssessorEntity class represents the entity which is performing the SecurityAssessment. It can be either a Cloud Provider, a customer (or Tenant) and a CloudTrustAgencty. SOFIC defines an OWL object property to define this association: SecurityAssessorEntity ⇒ provides ⇒ SecurityAssessment. Notice that Tenant, CloudTrustAgency and Provider extends from SecurityAssessorEntity.

The Component class is defined in the mOSAIC ontology, and it is a superclass from which extends different subclasses like a Resource or an Infrastructure. An Infrastructure can represent a Cloud system or even a Grid, while a Resource is a wider concept since even a Service (e.g. IaaS, PaaS) is a Resource. Therefore, a assessor entity can assess any Cloud component and its subclasses: SecurityAssessorEntity ⇒ assess ⇒ Component. Moreover, a security assessment is performed over any Cloud component: SecurityAssessment ⇒ over ⇒ Component. Additionally a security assessment assess a provider: SecurityAssessment ⇒ assessEntity ⇒ SecurityAssessedEntity.

A security assessment is composed of different assessed parameters. AssessedParameter ⇒ parameterOfAssessment ⇒ SecurityAssessment. There is not a predefined number or set of assessed parameters per each assessment. It depends on the kind of entity performing the assessment, their assessment capabilities or their security interests.

The NIST SP800-144 Guidelines of Security and privacy in Cloud Computing identifies security and privacy issues as well as related recommendations for organizations making use of cloud outsourcing arrangement. It identifies some areas such as Governance, Compliance, Trust, Security Architecture, Identity and Access Management, Software Isolation, Data Protection, Availability, Incident Response. SOFIC relies on most of these security areas; Nonetheless, Software isolation and Trust are not actually identified as principal security control groups in the CSA standard, nor in the SOFIC ontology. Instead of being a category per se, Trust is rather about the adoption and compliance of the proper security and privacy properties defined in the rest of the categories. The NIST's Security Architecture area is considered in our ontology as Infrastructure Security. On the other hand, Governance refers to the process carried out by the CSP with the aim of controlling and overseeing his policies, procedures, standards and so on, which is not actually an applicable area for an external security assessment as defined in SOFIC. The NIST's Availability is a subcategory in SOFIC that falls into the Operational Security category. In addition to NIST's areas, we have included in SOFIC the vulnerability management category identified by the ENISA guide.

The following figure shows the seven identified categories of security parameters that can be assessed. All the categories extend from the class SecurityAssessedParamenter.

Some security parameters can be related to the compliance of certain security principles. The ontology represents this by the object property: SecurityAssessedParamenter ⇒ ensures ⇒ SecurityPrinciple. Although some authors identify some other security principles such as authenticity and utility, it can be identified three well known security principles, the classic CIA triad, i.e. confidentiality, integrity, availability. These principles are modeled in classes which extend from SecurityPrinciple.

Additionally, there are a large number of IT governance frameworks, such as NIST 800-53, ISO 2700x, ISAE 3402, SSAE 16, which describe security controls to be adopted by a Cloud service provider to ensure the service is secure and reliable. There are also some others controls specially designed to Cloud computing such as Common Assurance Maturity Model (CAMM), CSA Cloud Controls Matrix CCM, the ENISA Assurance framework, and ISO 27017 (in development). These security controls are meant to be carried out internally, inside the CSP, so it is useless to take into account many of these parameters when assessing the CSP from outside, by another Cloud provider, trust agency or customer. On the other hand, most of the security parameters identified in the ontology can be related to concrete security controls to each of the aforementioned control specifications. The object property AssessedParamenter ⇒ relatedTo ⇒ ComplianceID represent such notion. The ComplianceID class is included to relate each of the security parameters identified in the ontology with the code identifier used in the security standards. Subclasses of ClomplianceID are NIST, CSA, ISO.

The set of the security parameters subject to be measured highly depends on the kind of entity which is carrying out the assessment and the willingness of the assessed entity. Thus, customers can only measure some security metrics and properties based on its interactions. A Cloud provider usually has additional means to assess and monitor certain security properties about another peer Cloud provider. Likewise, a third Trust agency could have special agreements with certain CSPs so that it could be authorized to monitor a larger set of security aspects. To model this, it is defined the object property: Assessedparamenter ⇒ applicableby ⇒ SecurityAssessorEntity.

A measure of a metric can be taken in the client side or server side. The AssessmentDeploymentScope class and the obtainedAt object property model this. Assessedparamenter ⇒ obtainedAt ⇒ AssessmentDeploymentScope. In the ClientSide the monitoring and the resultant assessment are done by the client without awareness and help of the CSP. It is performed based on the client interactions within the CSP, for instance analyzing the behaviour of the tenant's services installed/hired in the CSP and using monitoring agents. The ServerSide can be, in turn, Client-Specific or Enterprise. In the Client-Specific the Assessment Service provides special information about security controls related to client's services. In an Enterprise scope, this service usually provides additional information about the CSP as a whole, and not directly related to the client services.

The SOFIC ontology follows a hierarchical approach where some of the security categories describe their own subareas along with their parameters and metrics. The following figure shows an example of such a hierarchical parameters breakdown.

The ontology features two main types of security parameters. Those measured as booleans, i.e. if the assessed component fulfills such security property or not, and those monitored and measured as values. The measurable security parameters, i.e. those that can be considered metrics, extends from the Metric class. A Metric have three data properties. The measurementUnit represents the unit of measurement of the metric. The metricValue is the measured value whereas the metricNormalizedValue is the value obtained after normalizing the metricValue in the range [0,1]. Example of metrics are Mean Recovery Time (MRT) or Mean Time Between System Incidents (MTBSI). The following figure shows the double inheritance of those parameters that are metrics as well. Evidences of specific security values must be normalized into positive values in range [0,1].

Find below the main parameters and metrics for each of the seven identified security categories of assessment. The SOFIC ontology identifies 70 security parameters in the 7 categories, where 28 of them are quantifiable metrics. Nonetheless, for the sake of space, the parameters and metrics can not be described in details, and therefore, they have been summarized.

This category refers to the ability of the CSP to operate properly and continuously even in the possibility of a security breach. The CSP must guarantee that the system operate according to the SLAs and its information and services are available to customers upon demand. This category is, in turn, split in three subcategories, i.e. Adaptability, Availability as well as Scalability and Load Resilience.

Compliance is about the responsibility of the CSP to operate in agreement with established regulations, standards, laws and specifications. The SecurityManagementProgram property indicates whether the CSP provides the documentation describing the information Security Management program (ISMP), whereas the PolicyStandard security indicates the particular industry standards adopted by the CSP such as (ISO-27001, IS0-22307, CoBIT, etc.). In this regard, the PolicyReview property indicates whether the CSP informs about any change in the information security and/or privacy standards.

The OpenAuditReport indicates whether the CSP release their audit reports under request, while the ThirdPartyAudits indicates whether the CSP allows external audits. The CSP should also ensure tenants Intellectual property rights and have the ability to cancel the service anytime, even more when tenants services are mined for the CSP benefit.

The AuditingStandard parameter aim to enumerate the auditing standards it supports. Individuals of this class are Standards like CloudAudit/A6, Cloud Auditing Data Federation (CADF) from DMTF, CloudTrust or SCAP.

On the other hand, most of the security parameters identified in the ontology can be related to concrete security controls to each of the aforementioned control specifications. The object property AssessedParamenter ⇒ relatedTo ⇒ ComplianceID represent such notion. The ComplianceID class is included to relate each of the security parameters identified in the ontology with the particular code identifier used in the security standards. Subclasses of ComplianceID are NIST, CSA, ISO.

The InfrastructureTools property aims to enumerate the tools adopted by the CSP to prevent and detect security leaks and vulnerabilities at infrastructure level. Among them: EDS (Extrusion Detection System), Firewall, IDS (Intrusion Detection System), and IPS (Intrusion Prevention System). The ThirdPartySecurityServices indicates the adoption by the provider of a third-party services to find out vulnerabilities. Sub-classes of these third-party security services include AvScanners and any VendorTools.

The Segmentation property aims at indicating whether the system and network environments of the infrastructure are logically separated. Likewise, the NonProductionEnvironmentproperty indicates whether the CSP allows to provide tenants with separate environments for production and test processes. The Failover property indicates the CSP provides an infrastructure service failover capability to other providers.

Ensure privacy and confidentiality is of paramount importance in any Cloud system. To deal with this issue, CSPs must provide channel protection mechanisms to secure the communications and avoid undesired access to information. This communication should affect to any kind of interactions. Thus, there are three parameters in this category, CommunicationWithCostumers and CommunicationWithProviders and CommunicationWithServices. The class CommunicationProtocol aims at defining protocols employed to protect communications at different networking levels. Individuals of this classes are: IPSec, SSL, TLS, and XMLEncryption. Then the object property CommunicationProtection ⇒ adoptedProtocol ⇒ CommunicationProtocol relates any kind of communication with the protocols adopted.

This category of parameters refers to the ability of the provider to handle data efficiently and securely. This category encompasses some different subareas. Namely, Backup, data isolation, data migration and redundancy. The DataSecurityStandars property indicates the standards and audit controls adopted by the provider when it comes to the data and content protection. Data durability parameter represents the probability (in percentage) of the provider to lose an individual data block. It is related to the amount of data that could be lost in a period of time. Nowadays some CSPs are starting to inform about this parameter. After decommissioning services, data from storage media should be removed to prevent unauthorized disclosure of information.

The Data integrity indicates whether the CSP provides integrity routines for data input/output. The DataSanitation property indicates whether the provider performs a secure deletion before that any block is provided to other tenants. It should be applied to backup copies as well. Techniques to measure this property are detailed at the NIST 800-88 (Guidelines for Media Sanitation). It is perhaps the most difficult parameter to assess from outside. A Trust Agency could be granted to perform penetration tests to monitor this aspect. Traditional Monitoring tools, like Nagios could be used to measure this kind of stuff, since they are being extended to cope with Cloud virtual infrastructure monitoring and storage services. In fact, Nagios is being applied to open source Clouds like OpenStack and Eucalyptus.

The AIMStandards property indicates the standards protocols and languages employed by the CSP to carry out the identity an access management (AIM). Among these standards it is worth mentioning: OpenID, XACML, SAML, Oauth, SPLML, ws-securitypolicy, ws-trust, ws-federation, ORMS, KMIP, and XKMS. The Authentication property is split in two different sub-properties to indicate if the provider gives the option of One-FactorAuthentication or Two-FactorAuthentication which means that authentication of the CSP comply with two of the three factors: a knowledge factor ("something the user knows"), a possession factor ("something the user has"), and an inherence factor ("something the user is"). The AuthenticationMethod class define the kinds of authentication methods available, e.g. login/password, eID, ... The object property One-FactorAuthentication ⇒ adoptedAuthenticationMethod ⇒ AuthenticationMethod defines the actual supported authentication method.

The Authorization subarea is also split in three sub-properties according to the three main kinds of authorization mechanisms that can provide a CSP. The ACL property indicates that the CSP can authorize customers base on Access control list, the ConditionalAC indicates that the access control can be done based on context such as graphical locations, time of day or access protocol employed (e.g. SSL). The RBAC indicates if the CSP provides Role based access control mechanisms.

This category also embraces the key management procedures and the standards adopted such as the Key Management Specification (XKMS) and he OASIS Key Management Interoperability Protocol (KMIP), which is an emerging standard for interoperable key management in the Cloud. The IdentityBasedEncrytion property indicates whether the CSP allows tenant to use IBE so that they can encrypt data to an identity without access to a public key certificate.

CSPs should also provide Accounting functionalities and disclose their results in transparent manner, providing records and accurate logs. The LogAccuracy property aims to indicate whether logs contain events which are not related to tenants being informed. The LogAvailability property indicates whether customers are able to access to their logs (i.e. the logs managed by the provider). The AuditReportingPeriod metric reflects the mean frequency during reporting period. The RealTimeAudit property indicates if the logs can be accessible in real time from any global location.

This security category covers parameters about incident handling and reporting. The Information Technology Infrastructure Library (ITIL), defines an Incident as any event which is not part of the standard operation of the Incident Management service and which causes, or may cause, an interruption or a reduction of the quality of the service. Notice that this area does not pretend to describe a set of possible incidents in the Cloud but the way these incidents are handled and notified to tenants. The CSP can adopt a well-known incident format to describe their incidents. The IncidentStandards class represent this. Individuals of this class can be, for instance, the Incident Object Description and Exchange Format (IODEF) and the Intrusion Detection Message Exchange Format (IDMEF).

The metric MTBSI (Mean Time Between System Incidents) measures the average time from failures. Besides, the IncidentResolved metrics measures about the number of incidents resolved for a given period of time. In this security category it can be identified the IncidentReporting security sub-area, which refers to the ability of the CSP to deal with the incident reporting to their customers. This area is composed of three main metrics. The IncidentsReported metric reflects the number of incidents reported on time divided by the total number of reported incidents.

The TimeDelayDetectionAndReporting metric measures the average time between the time to detect services incidents and the time required by the provider to report such incident to customers. Likewise, the TimeToRespondeToIncidents metric refers to the average time required by the CSP to respond to incidents reported by its customers.

A vulnerability is a weakness that could be used to endanger or cause harm to an asset. This security category aims to asset CSP procedures while handling vulnerabilities. It is usual that providers may not disclose detailed information about vulnerabilities for security reasons, it could be done afterwards, once they are patched. Moreover, CSPs usually do not allow customers to perform vulnerability scans such as fuzzy testing or DoS checking. In any case, the are some parameters and metrics to take into account in this category.

The AdoptedVulnerabilityTools property aims to enumerate the tools adopted by the CSP to prevent and detect vulnerabilities. Among them: EDS (Extrusion Detection System), Firewall, IDS (Intrusion Detection System), and IPS (Intrusion Prevention System). The ThirdPartySecurityServices indicates the adoption by the provider of a thirdparty services to find out vulnerabilities. Sub-classes of these third-party security services include AvScanners and any VendorTools. The VulnerabiltyReport parameter indicates if the provider informs customers about vulnerabilities and their impact score. For instance, the list of the latest common vulnerabilities. Vulnerability score can be calculated using for instance CVSS.

The MitigatedVulnerabilities metric measures the number of vulnerabilities identified and mitigated in a time period divided by the number of vulnerabilities identified in such a time period. Likewise, the TimeToVulnerabilityFixing measures the average time since vulnerabilities are found out and they are fixed. The VulnerabilityCertificationSchemes indicates if the provider uses standards to describe its vulnerabilities. The Common Vulnerabilities and Exposures (CVE) and Common Weakness Enumeration (CWE) can be utilized.

The complete definition of the SOFIC ontology and mOSAIC in OWL format can be downloaded below.