10 Jun 2013 | Written by Annett Laube-Rosenpflanzer - Contact Annett

PoSecCo relies on two ITIL elements to support configuration management: Configuration Management Database (CMDB) and Configuration Management System (CMS). Configuration Items (CIs, typically hard and software components) are recorded in a CMDB and managed by the CMS by means of a series of standard processes. The data contained in the CMDB are the main source to create and maintain the Infrastructure Layer of the PoSecCo Functional Systems Model. The PoSecCo Functional System Model provides the data basis of all PoSecCo tools and has to be built for the entire landscape of the service provider for which the PoSecCo policy chain should be constructed.

PoSecCo assumes that the service providers’ CMDBs support:

 - the WBEM standard to collect data from the landscape components and to provide information to client applications

and

 - uses a model based on the Common Information Model (CIM).

The PoSecCo CMDBExtractor queries all necessary landscape information from the connected WBEM-enabled CMDBs, converts them from the CIM based model into the PoSecCo Functional System Model and stores them in the PoSecCo model repository. In a second step, the created models have to be verified and completed in a semi-automated manner.

In praxis, only a few of the available CMDBs are using the standards WBEM and CIM (on overview can be found in the PoSecCo Deliverable D1.2 – Reference Architecture). Commercial CMDBs often implement a simple data model, sometimes reusing concepts from CIM. These CMDB are used to maintain the inventory and contain mainly a list of the hardware and software components (licenses) purchased. Information about which software components are running on which systems and how the systems are integrated in the networks, which is essential for the PoSecCo tools, are normally not included.

In PoSecCo, we use an OpenPegasus CMDB in our testbeds. OpenPegasus is one of the Open Source CMDBs that support the WBEM and CIM standard. The OpenPegasus CIM server contains a CIM object manager (CIMOM) and a CIM repository. The CIM Object Manager Repository only contains static data about Configuration Items, normally entered manually with different tools. More interesting is the possibility to retrieve dynamically information about the landscape. This is possible with the help of WBEM providers that monitor the configuration items and provide a snapshot of current state. Unfortunately, only a few providers are available, mostly for hardware components, like computers or firewalls. In PoSecCo, where we focus more on the software components, only the WBEM provider for the operating systems could be used. For all other components, we had to maintain the information manually in the CMDB.

In general, it is not very complicated to write WBEM providers for the components that should be monitored by the CMDB. But as each provider has to be registered in the CIMOM, it makes only sense in a very stable environment. In a quite often changing environment like webservers, where updates of subcomponent (Java VM, security modules, etc.) and of the deployed web applications and web services are daily business, the use of providers does not really reduce the manual effort. An agent based system that scans regularly the monitored systems, seems more promising for future work.

The reader is welcomed to read to through the following documents in order to get additional information about the above-mentioned concepts:

03 Jun 2013 | Written by Antonio Lioy - Contact Antonio

The PoSecCo project proposes an innovative approach to security design and management: it aims at establishing a traceable and sustainable link between high-level requirements and low-level configurations, by means of the Security Decision Support System (SDSS). This link is created at design time, when performing the policy refinement that establishes the policy chain (see 1 Apr blog post).

The last link in the chain is the one between the IT Security Policies and the Security Configurations. IT Security Policies are specified using a formal meta-model, that is a state-of-the-art access control policy specification format. IT Security Policies allow the specification of security requirements for authentication, authorization, and data protection policies. They can be expressed in natural language as:

Customer#1 is allowed to reach the eInvoicing service

or

The communication between the eInvoicing service frontend and the Database must be protected

In PoSecCo, the refinement of IT Security Policies is performed according to two classes of security controls. First, the SDSS evaluates the possibility of using endpoint security controls, e.g. to enforce authorization policies (access control) at operating system or database level, and authentication mechanisms implemented directly at the endpoints. Then, a topology-dependent refinement step is performed for policies whose enforcement may be done also using non-endpoint controls (e.g. network firewalls or security gateways). In the latter case, the IT Security Policies are translated to a different format, named Logical Association, prone to topology-dependent analysis. This is one of the aspects where the SDSS exhibits a significant innovation, with the integration between traditional access control (as supported by operating systems, databases, web servers and application servers) and network access controls.

At the IT Security Policy level, only the endpoints are considered, while the structure of the IT system is simply ignored. However, when arriving at the Security Configurations this assumption is no longer true. An IT system is a network composed by many network nodes, each one having specific capabilities (i.e. the security controls) that can be enabled, taken individually or in combination, to enforce the policy. Due to the large availability of security controls, the infrastructure layer offers numerous possibilities to enforce the policy. For instance, data protection can be enforced by establishing secure channels with different technologies (e.g. WS-Security, SSL/TLS and IPsec). Additionally, the previous techniques can be used end-to-end or, in case of site-to-site policies, using the gateways (e.g. OpenVPN or IPsec in tunnel mode). Usually, the bigger and more complex the network, the more the ways to enforce a policy.

This large set of choices is certainly an advantage for security and fault tolerance, however it can create confusion and make the administrators' decision difficult. When many implementations of the policy are possible, our approach uses mathematical optimization to select the "best" implementation of the IT Security Policy. The problem of selecting and configuring the enforcement points is mapped to an optimization problem that, given a description of the IT system and a policy, has to find a set of optimal Security Configurations enforcing the policy. The actual solution is found using an off-the-shelf optimization tool; we experimented with both an open source product (lp_solve) and a commercial one (CPLEX).

With this approach the user has only to select the optimization profile to use to define the concept of "best" (see below picture).

The SDSS will then perform the rest, without asking for any other contribution from the user:

- Generation of the possible implementations: The policy is processed to identify the available security controls in the target network that, individually or in combination, can enforce it.

- Implementation rating: Each generated implementation is evaluated according to a different set of metrics: performance (individual components and overall), security (risk analysis, security controls reputation), and costs (deployment, management). This entails the existence of a company-approved risk analysis and reputation analysis model.

- Model generation and solution: In this phase, we formally model the problem of choosing among different implementations as an Integer Linear Programming problem (ILP), thus we can use standard solvers to compute the optimal set of implementations (an exampleof a generated optimization models is in left figure below) . This approach is easily extensible to different optimization criteria, since they can be represented as new target functions. For instance, the different implementations may be selected to minimize the risk, the maintenance or deployment costs, maximizing the performance, or a balanced mix of these objectives (that can be customized by the user). The optimization is a global one as all the IT policies processed by the Infrastructure Configuration are considered at the same time and not one-by-one. The SDSS permits the visualization of the selected and discarded implementations, as well as the rating (Wwights) and criteria for rejection (see middle figure below).

- Security configuration generation: Once the mathematical solver selected the "best" combination of security controls to enforce the policy, the final step is to generate the configurations: every IT Security policy is interpreted and adapted to fit to the category of security control to configure (e.g. filtering device, channel protection) and it contributes to the configurations with one or many configuration rules (see right figure below).

In summary, with the SDSS, PoSecCo offers to the security manager a tool that evaluates the available options for implementing the security policy, automatically grades them according according to user-specified criteria, and suggests the best solution to satisfy the requirements.

The user is welcome to read the SDSS documentation and try out the tool, as well reading the various deliverables that document the meta-models and the refinement procedure: 

28 May 2013 | Written by Günter Karjoth - Contact Günter

Have you ever wanted not only to configure your system securely but also at the least cost? Unfortunately, the nature of security makes it hard to measure and therefore difficult to both quantify and evaluate. To be able to perform an analytical and more exact description of security, quantitative security measures are needed. Furthermore, security metrics should be meaningful. Yet, metrics are often too simplistic or are aggregated according to nice theoretical models but without empirical basis or business sense.

PoSecCo has studied the applicability of security metrics to the different types of decisions CIOs and other decision makers may encounter within policy and configuration management. As there is no single metric covering all security controls, we focused on a decision framework for identity and access management. Having a model of the Identity and Access Management (IAM) systems deployed in the organization, it supports the involved stakeholders to express and explore their subjective concerns. A metric should reflect the specific needs for Role-Based Access Control (RBAC), widely used in enterprise security and identity management products. Our investigations have been on role modeling pertaining to analysis, design, management, and maintenance.

Different factors influence the complexity and thus the quality of RBAC configurations and their cost of administration. Among the data available to the organization, it is possible to find information that either directly influences the required system administration effort (e.g., number of roles, number of role-user relationships to be administered, etc.) or information that helps role engineers assign business meaning to roles (e.g., business processes, organization structure, etc.). Once an organization has identified the relevant data for access control purposes, this data can be “translated” into cost elements and then combined into a cost function.  We developed a technique for modeling complex systems when analytical models of a situation do not exist. Deploying a multi-dimensional database technology, it supports the identification of ineffective access control mechanisms. In particular, we have explored OLAP visualization of access-control-related information as a source of intuitions and hypotheses and as a way of communicating model data. Using OLAP gives the opportunity to discover previously undiscerned relationships between data items establishing a sound role model.

Balancing protection and empowerment is a central problem when specifying authorizations. The principle of least privilege, the classical approach to balancing these two conflicting objectives, says that users shall only be authorized to execute the tasks necessary to complete their job. However, business processes that require the execution of multiple tasks by different users can have multiple authorization configurations (representing different authorization policies) that satisfy least privilege. Furthermore, the choice of an authorization configuration may be influenced by the cost associated with the respective administrative change. We model the tasks that users must execute as workflows, and the risk and cost associated with authorization configurations and their administration. We then formulate the balancing of empowerment and protection as an optimization problem: finding a cost-minimizing authorization configuration that enables a successful workflow execution.

In summary, the PoSecCo Decision Types and Framework provides cost/benefit models and techniques to support IT managers when making decisions between different configuration options as well as different ways of managing policies and configurations. Having a business focus, this work complements the technical research work packages of PoSecCo. By providing new ways to measure and optimize the cost-benefit ratio, it provide the basis for an economic justification of investments in infrastructures facilitating policy and configuration management.

For more information we refer to the following sources of information:

20 May 2013 | Written by Kreshnik Musaraj- Contact Kreshnik

To guarantee compliance with high-level security policies in PoSecCo, especially in case of change in the landscape, we also rely on vulnerability assessment to provide adapted remediation proposals. The prototype we have implemented intends firstly to help security stakeholders to understand the risk they are facing, by showing the existing vulnerabilities that can be exploited by a malicious user to violate the security policies in place and, secondly, it gives to the defenders the opportunity to select the best counter-measures to be deployed, the ones that offer the best balance between deployment costs and improvement in the compliance level.

The first step to carry out the vulnerability assessment is to build an attack graph based on the current state of the information system. An attack graph contains all the potential series of vulnerabilities exploitation that can be used by an attacker to compromise IT ressources. It takes into consideration the configurations conditions required by an attacker to conduct his attack. The attack graph is generated using the topological information contained in the PoSecCo models (extracted from MoVE), a vulnerability database and an attack graph engine provided by the Fi-Ware Security Monitoring Generic Enabler.

13 May 2013 | Written by Lukas Demetz - Contact Lukas

The PoSecCo project comprises project activities analyzing the economic viability of the developed toolset. That is, we compare benefits of using the PoSecCo toolset to the costs of toolset’s deployment. For this purpose, we are currently conducting an online survey focusing on security and compliance processes. In more detail, in this study we are interested in performance dimensions and in the impact of certain cost drivers on the costs of security and compliance processes.

In doing so, the survey consists of two main blocks. The first block focuses on performance dimensions of security and compliance processes. In this block, we use the point allocation method so that participants can allocate 100 points to the four dimensions execution time, resource consumption, correctness of output, and coverage of input. Such an allocation is done in general and focusing on the six activities selecting control objectives, creating the control design, verifying the control implementation, verifying the control design, checking supplier, and visualizing security models. The second block focuses on cost drivers of security and compliance processes. Here, we ask respondents to indicate the impact of given cost drivers on the costs of security and compliance processes using a seven-point Likert scale.

In this survey, we rely on the experience of professionals in the area of security and compliance management. If you are working for a service provider or an (IT) auditor and are in charge of security and compliance processes, we kindly invite you to participate in the survey.

You can access the survey here. The survey is in English and takes about 15 minutes to complete. Certainly, the data is stored anonymized and is only analyzed for the purpose of this survey. Your participation is highly appreciated. Without the support of professionals, it would not be possible to conduct research like this. In case you know any other person who qualifies as a potential respondent, please feel free to forward the survey.

Once completed, we are happy to share the results with all interested participants and readers of this blog.

The results of this survey will provide valuable input to:

06 May 2013 | Written by Olivier Bettan - Contact Olivier

One main objective of PoSecCo is to promote collaboration activities with relevant external projects and communities. The most advanced synergy were exploited together with the Fi-Ware project.

FI-WARE delivers a novel service infrastructure built upon elements (called Generic Enablers – GEs) which offer reusable and commonly shared functions making it easier to develop Future Internet Applications in various sectors.

The FI-WARE project develops open specifications of FI-WARE GEs, together with a reference implementation of each GE for testing some of which will be submitted for standardization. FI-WARE aims to draw upon results already achieved through earlier research projects to further develop and integrate them; this shared interest for enjoying the benefits of collaboration naturally led to the encounter between PoSecCo and Fi-Ware.

Regarding PoSecCo objectives, the most promising synergy was found within the Security Monitoring GE (see Fi-Ware Wiki for more details). Three main capacities of PoSecCo have allowed Fi-Ware Security Monitoring GE to evolve.

The following figure shows the FI-Ware architecture before PoSecCo elements were incorporated.

29 Apr 2013 | Written by Serena Ponta - Contact Serena

Configuration validation establishes whether actual configuration values of software components comply with desired ones.  In the PoSecCo approach, desired configurations are defined within the policy chain together with the link towards the higher-level policies they are meant to enforce. As long as configuration settings can be altered manually, configuration discrepancies between desired and actual value may exist at operational-time, due to accidental changes or intentional attacks. Configuration validation is thus critical to ensure a secure and compliant configuration at any point in time.

Configuration validation is performed by means of checklists and checks specified with a declarative language based on the Security Content Automation Protocol (SCAP).  SCAP is provided by the National Institute of Standards and Technology (NIST) and is an on-going effort to provide standards for security automation and to foster the exchange of security knowledge among stakeholders. In particular, we rely on XCCDF for the definition of structured checklists, and OVAL for the specification of security checks to detect discrepancies. It is important to note that we extended OVAL, currently focusing on single hosts and operating systems, to support configuration checks for diverse, distributed software components.

The configuration validation tool is composed by an audit interface and a configuration validation back-end.  The audit interface can be accessed by different stakeholders, e.g., internal/external auditors and security administrators, and supports various auditing activities.

The following video exemplifies the validation of configurations settings stemming from PCI DSS and authorization requirements for business services. 

15 Apr 2013 | Written by Stefano Paraboschi - Contact Stefano

The IT Policy has a crucial role in the PoSecCo approach. Its responsibility is to build a strong connection between, toward the upper level, the textual and natural language representation that is the outcome of requirements analysis and, in the opposite direction, the logical description of the security configuration of the system. The representation of the IT Policy is on one hand formal, with the ability to support the automatic verification of several properties, and on the other hand relatively abstract, leading to the identification of properties that are independent of the specific implementation details that characterize each technological solution. The "IT Policy Harmonization" is the process that verifies the consistency of the policy. This process invokes the services of three modules. The modules rely on the use of Semantic Web technologies: the IT Policy is represented as an OWL ontology and the reasoning services are expressed in Semantic Web tools like OWL-DL, SWRL, and SPARQL-DL.

We briefly describe each of the three modules.

- Modality conflicts: this module is responsible for the identification of conflicts between rules of opposite signs that can be applied to the same requests. This occurs when the policy at the same time contains positive authorizations that grant to a user the ability of making a specific access request and negative authorizations that forbid the same access request. The identification of the conflicts takes into account the conflict resolution option specified in the IT Policy.  The results of the analysis is the set of conflicts that are not solved by the conflict resolution algorithm. The figure shows the interface used for the description of the identified conflicts. There is an interface showing an explanation in term of the internal OWL constructs and another interface that expresses the results in a format that is near to the IT Policy representation familiar to the user.

08 Apr 2013 | Written by Ruth Breu (University of Innsbruck) - Contact Ruth

A core task of the PoSecCo Business Layer is to conceptualize information from manifold sources – ranging from standards, legal regulations, service level agreements from customers to information and events from lower levels of the policy chain. A tool at this level of abstraction has the goal to provide executive stakeholders with a cockpit to monitor corporate security requirements. With CoSeRMaS we developed an innovative tool which provides a fundamental solution to a number of challenges.

- Dependency on functional concepts: Security requirements in CoSeRMaS are bound to functional concepts – e.g., a business process, an institution or a business object. On the other side CoSeRMaS is fully generic with respect to the meta model of the business process and functional layer, supporting continuous information exchange with external tools (e.g. an Enterprise Architecture Management tool). That way cost intensive maintenance of the business model can be avoided.

01 Apr 2013 | Written by Henrik Plate (SAP) - Contact Henrik

In very general terms, a policy is commonly understood as a "definite goal, course or method of action to guide and determine present and future decisions" [RFC3198]. In the scope of IT system management, policies are supposed to constrain and determine the behavior of computing systems, and exist in several abstractions, from high-level goal policies to low-level operational policies. The various policy abstractions are typically said to form a policy hierarchy, created in a top-down refinement process. This process starts with the specification of high-level goals that relate to business terms, and is completed by the specification of deployable policies that ultimately enforce the high-level policy in a given IT system, e.g., by the configuration of firewalls or authorization settings.

The specification and refinement of policies requires the collaboration of various stakeholders to ensure, for instance, that all relevant goals have been identified, that lower-level policies are indeed suitable for enforcing higher-level ones, or that policy conflicts are avoided. This collaborative work involves representatives from management, legal or vendor management, as well as security experts knowledgeable in the various technologies that constitute modern IT systems. According to today's practice, policies are typically represented in natural language - in early stages of the refinement process - or by concrete, product-specific configurations. The non-integrated representation of policies belonging to the different levels and the use of different media for policy storing and maintenance, however, hinders the efficient collaboration of involved stakeholders and increases the risk that high-level goal policies and enforcement policies diverge, which in turn can result in security and compliance issues.

PoSecCo aims to develop new methods and tools that support organizations in the policy refinement process. We thereby speak of a "policy chain" to emphasize the tight coupling of policy representations of different abstractions. This chain is established during a design-time refinement and optimization process, whereby the specification of policies on each layer is supported by dedicated tools. Policy designers at the various levels are supported in many ways, e.g., in the identification and resolution of policy conflicts, or the selection and automated configuration of suitable enforcement mechanisms. At runtime, the policy chain can be leveraged, for instance, to support audit activities, or to understand the impact of security misconfigurations.

The three different elements of the policy chain, Business Policies, IT Security Policies and Security Configurations, are represented by corresponding information models, each one of them linked to a corresponding model for functional matters. In other words, Business Policies (that comprise Security Requirements) are defined over a Business Model describing concepts such as Business Service, Customer or Supplier, IT Security Policies are defined over an IT Service Model that describes the architecture of an IT system by pointing to its main building blocks, interfaces, and communicatin channels, and the Security Configuration is defined over a Infrastructure Model that describes system details such as the network topology, application instances or actual communication endpoints, all of which has been modeled close to the DMTF standard CIM (Common Information Model).

The following video illustrates a simplified example of a PoSecCo policy chain by showing one functionality of the PoSecCo tool supposed to support audit activities. The JavaScript-based visualization of the policy chain shall allow judging the design effectivness of an organization's control framework, i.e., to understand whether designed security controls are suitable for achieving certain goals. The video at hand takes a example of a security requirement stemming from PCI DSS, which asks for the protection of cardholder data.