Compliance Audit of Linux Environments

Masaryk University Faculty}w¡¢£¤¥¦§¨ of Informatics!"#$%&'()+,-./012345

Thesis

Šimon Lukašík

Brno, May 2013 Declaration

Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

Advisor: RNDr. Jan Kasprzak

ii Acknowledgement

I would hereby like to thank my advisor RNDr. Jan Kasprzak. I must also ac- knowledge the extraordinary efforts of my consultant from Red Hat Czech s.r.o, Jan Pazdziora Ph.D. for his professional help, support, and every day inspiration.

Red Hat, Red Hat Enterprise Linux, JBoss, Fedora are either registered trademarks, or trademarks of Red Hat, Inc. in the United States and other countries. Linux® is the registered trademark of Linus Torvalds in the United States and other countries. OVAL, CVE are registered trademarks and OCIL, CCE, and CPE are trademarks of The MITRE Corporation. XCCDF and SCAP are trademarks of the National Institute of Standards and Technology. Oracle® and Java® are registered trademarks of Oracle and/or its affiliates. All other trademarks are the property of their respective owners.

iii Abstract

SCAP is a U.S. Government standard facilitating automated compliance audit. OpenSCAP is an open source scanner which allows assessment of target system in line with SCAP standard. Spacewalk is an open source management solution for Linux systems. The main goal is to integrate OpenSCAP and Spacewalk projects enabling system administrators to audit their Linux systems in fully automated way. The coales- cence of subset of SCAP data model into Spacewalk database allows administrators to search and compare archived scan results in centralized user interface.

iv Keywords

Security Audit, Compliance Management, Reporting, System Assessment, Remedi- ation, System Management, Security Content Automation Protocol, Linux, Open- SCAP, Spacewalk.

v Contents

1 Introduction ...... 5 1.1 Related Technologies ...... 5 2 Compliance Audit ...... 7 2.1 Customization of Security Policy ...... 7 2.2 Implications of Heterogeneous Environments ...... 8 2.3 U.S. Government Program ...... 9 2.4 SCAP—Security Content Automation Protocol ...... 9 2.4.1 SCAP Adoption ...... 9 2.4.2 SCAP Components ...... 10 2.4.3 Document Formats ...... 12 2.4.4 XCCDF ...... 12 2.4.4.1 Short Description of XCCDF Elements ...... 13 2.4.5 OVAL ...... 14 2.4.5.1 OVAL Document Formats ...... 16 2.4.6 DataStreams ...... 17 2.4.7 Asset Reporting Format ...... 17 2.4.8 Forms of SCAP Security Policy ...... 17 2.4.9 SCAP Challenges ...... 18 2.4.9.1 Human and Machine Readable Format ...... 19 2.4.9.2 Limitation of Interoperability ...... 19 3 OpenSCAP ...... 21 3.1 OpenSCAP Library ...... 21 3.2 OpenSCAP Tool: oscap ...... 21 3.2.1 Output of oscap xccdf eval ...... 22 3.3 SCE: Script Check Engine ...... 23 3.3.1 Exemple of SCE Content ...... 24 3.4 Security Guidances Related to OpenSCAP ...... 24 3.4.1 Platform Limitations of Security Guidances ...... 24 3.4.2 OpenSCAP Example Content ...... 25 3.4.3 SCAP Security Guide ...... 25 3.4.4 SCE Community Content ...... 26 3.5 OpenSCAP Competing Projects ...... 26 3.5.1 OVALDI Project ...... 26 3.5.1.1 Comparison with OpenSCAP ...... 26 3.5.2 XCCDF Interpreter ...... 27

1 3.5.3 jOval Project ...... 27 3.5.3.1 Comparison with OpenSCAP ...... 28 3.5.4 Modulo Open Distributed SCAP Infrastructure Collector . . 28 3.5.4.1 Comparison with OpenSCAP ...... 29 4 Spacewalk ...... 30 4.1 A Short History of the Spacewalk ...... 30 4.2 Spacewalk Deployment Model ...... 31 4.3 Spacewalk Competing Projects ...... 31 4.4 Server Architecture ...... 32 4.4.1 HTTP Server ...... 32 4.4.2 Backend Tools ...... 33 4.5 Database ...... 33 4.5.1 Differences between PostgreSQL and Oracle ...... 34 4.6 Concept of Software Channels ...... 34 4.7 Concept of Configuration Channel ...... 34 4.8 Remote Client Actions ...... 35 4.8.1 Life-cycle of RHN Action ...... 35 4.8.2 Client Tools Supporting Remote Actions ...... 36 4.8.2.1 rhn_check utility ...... 36 4.8.2.2 RNSD Daemon ...... 37 4.8.2.3 OSAD Daemon ...... 37 5 Spacewalk and OpenSCAP Integration ...... 38 5.1 Requirements Analysis ...... 38 5.1.1 Summary of the Functional Requirements ...... 38 5.1.2 Constraints Arising from Technologies Used ...... 39 5.1.2.1 Status of the OpenSCAP Project ...... 39 5.1.2.2 Spacewalk Life Cycle ...... 40 5.1.3 Infrastructure Deployments: Pull versus Push Approaches . . 40 5.1.3.1 Pull versus Push for the Purpose of Auditing . . . . 41 5.1.4 Content Delivery ...... 41 5.1.4.1 Forms of Security Policy Content ...... 42 5.1.4.2 Timing of Content Delivery ...... 42 5.1.5 Support of Older OpenSCAP Libraries ...... 42 5.1.6 Audit Results Processing ...... 42 5.2 Design ...... 43 5.2.1 RHN Action to Facilitate Compliance Audit ...... 43 5.2.2 OpenSCAP library vs oscap Choice ...... 44 5.2.2.1 Limiting Interface Available to User ...... 45 5.2.3 Security Policy Distribution ...... 45 5.2.4 Audit Results Processing ...... 46 5.2.4.1 Intermediary Format for Results Reporting . . . . . 46 5.2.4.2 Choosing XCCDF over OVAL ...... 46 5.2.4.3 XCCDF Items For Aggregation ...... 47 5.2.4.4 Examplary XCCDF Résumé ...... 48

2 5.3 Conceptual Data Model ...... 48 5.3.1 Definition of Existing Kernel Sorts ...... 49 5.3.2 Definition of New Kernel Sorts ...... 49 5.3.3 Definition of New Associative Sorts ...... 50 5.3.4 Definition of Existing HIT Attributes ...... 50 5.3.5 Definition of New HIT Attributes ...... 50 5.3.6 Entity Relationship Diagram ...... 50 6 Implementation ...... 52 6.1 Client Side Changes ...... 52 6.1.1 Plugin Interface ...... 52 6.1.2 Execution of the oscap Command ...... 53 6.1.2.1 Preprocessing of Command-Line Arguments . . . . 53 6.1.3 XSLT for Results Processing ...... 53 6.2 Database Schema Changes ...... 54 6.2.1 New Tables Definition ...... 55 6.2.1.1 Choosing Data Type for XCCDF Identifiers . . . . 55 6.2.2 Database Constraints ...... 56 6.2.3 Indexes for Performance Porposes ...... 56 6.2.4 Reference Tables Content ...... 57 6.2.5 INSERT Anomalies ...... 57 6.2.6 Stored Procedures ...... 57 6.2.7 Schema Upgrades ...... 58 6.3 Backend Server Changes ...... 59 6.3.1 Assembling Input for Clients ...... 59 6.3.2 Storing Scan Results from Client ...... 59 6.4 Web User Interface ...... 60 6.4.1 Technologies Used ...... 60 6.4.1.1 How is Single Web Page Served ...... 61 6.4.1.2 Components of the Model ...... 61 6.4.2 Audit Scheduling ...... 62 6.4.3 Audit Reporting ...... 63 6.4.3.1 Scan Details Page ...... 63 6.4.3.2 XCCDF Diff Page ...... 63 6.4.3.3 Results Summary Pages ...... 65 6.4.3.4 Using XCCDF Diff for Simple Comparison . . 66 6.5 API for Fully Automated Audits ...... 67 6.6 Full Text Search ...... 67 6.6.1 OpenSCAP Search Dialog ...... 67 6.6.2 Lucene Search Post-Processing ...... 68 6.6.3 Indexing with Lucene and Quartz Frameworks ...... 69 6.7 Spacewalk Reports ...... 69 6.7.1 OpenSCAP Reports ...... 69 6.8 Source Code ...... 69 7 Conclusion ...... 71

3 7.1 Further Work ...... 72 A Example of XCCDF Document ...... 81

4 Chapter 1 Introduction

During the last 30 years, almost every organization moved its operations into the digital world. The computer security has became increasingly important as these entities have realized the need to protected their interests. Two major approaches can be recognized in computer security: reactive and proactive. The reactive approach is involved in disaster recovery plans which mainly comprise of eliminating threat, switching to alternate systems, attack surface analysis, investigation, and remediation of compromised systems. Per contra, this work relates with the proactive approach which consists of any actions that reduce the risk of damage or compro- mise. To be able to mitigate consequences of possible attack, the assets at risk must be recognized prior to the attack. Importance of correct determination of possible attack targets is illustrated by great number of approaches to risk analysis. The security guidance on how the computers shall be set up to mitigate the risk for the organization is rendered on the basis of risk analysis. To properly implement the guidance, not only target computers need to be hardened but it is essential to ensure that these computers remain compliant for their whole lifetime. That can be achieved by compliance audit which repeatedly asserts that all the expected settings are in place. The major focus of this work is to accommodate compliance audit in large infrastructure deployments using the open source software. This shall be accomplished by integration of existing open source technologies which are already adopted by enterprises. The objective is to enable users to perform the security audit on multiple remote systems from single, centralized environment.

1.1 Related Technologies

The first three chapters present the concepts, standards, and technologies relatedto this work. Major technologies used are SCAP—the compliance automation protocol, OpenSCAP—the compliance scanner, and Spacewalk—the systems managing system. Figure 1.1 illustrates relationships between them. Dotted relationships are concern of the last two chapters and of this work. Open source projects OpenSCAP and Spacewalk have been selected as building blocks for their leadership in their respective domains. Both projects were founded

5 1. Introduction by Red Hat, Inc. and later adopted by community of users and developers.

SCAP oscap Workbench use Command-line GUI tool

use

use use

SCE implement OpenSCAP Spacewalk

Systems Management Script Check Engine OpenSource Solution Library

implement

process

implement SCAP compose instantiate OVAL SCAP Content

A Security policy XCCDF NIST Standard DS CVE ARF CPE OCIL CCE

Figure 1.1: Technologies and Standards Used

6 Chapter 2 Compliance Audit

Compliance audit is a process of figuring out whether a given object follows allthe rules written out in a compliance policy. Compliance policy is defined by security professionals who specify desired settings (often in the form of a checklist) that are to be used in the computing environment. The policy is then used by a security auditor (either in person or using a program) that goes through the checklist and asserts if the defined settings are in place on the target computer systems. Note that some of security policy requirements cannot be easily expressed in the form of checklist and thus such requirements are not subject of compliance audit.

2.1 Customization of Security Policy

The policy checklists can vary vastly across organizations and even across different systems within the same organization. Differences among these checklists are based on the purpose (or application) of these systems and importance of that purpose for the organization. The non-default software settings and deployment characteristics also raise a need for custom policy checklists. The security or compliance policy is rarely written from scratch. ISO 27000 standard series, derivative works, and other sources provide security policy templates and practice recommendations which should be helpful to start with [1]. However, organizations building theirs information security program need to amend the policy templates to align with their needs. The policy template should be chosen on the basis of its relevancy to the company environment and then the template has to be tailored because either the template contains build-in assumptions which cannot be applied to the organization, or the template explicitly requires that certain decisions have to be made. The default shipped settings of software systems are often not satisfactory from security point of view as these settings are developed by aligning security with usability requirements. Many people believe that there is an inherent trade-off between security and usability [2]. On one hand, software vendors strive to make their default settings as secure as possible. That is based on their notion that people will not tighten security unless they are paranoid, and they will rather relax it if the

7 2. Compliance Audit hardened setting impacts their applications. On the other hand, software vendors need to consider out-of-the-box usability as well.

2.2 Implications of Heterogeneous Environments

Another reason for the differences in policies arise from variations in deployments. Be it software stack on single computer or high level architecture of network, each deployment and its characteristics have an impact on the resulting security policy. With regard to the fact that checklist are focused on single machine, a different policy may apply to a server behind network firewalls compared to the public facing computers. The very same example can be found on the client side where mobile device might be subject to harder requirements than a desktop computer which will never leave a private network. On top of that, organizations often have to maintain heterogeneous set of computer platforms. Most commonly, one can see POSIX compliant systems deployed on the servers, Microsoft Windows or Mac OS on desktops, and mixture of these on mobile devices. Some of the security requirements are platform independent. For example, system password must be of some minimal length, system passwords must not be stored in plain-text, user must not be allowed to mount portable devices, or that telnet service must not be enabled. However, many of security requirements are not applicable or even not available on all platforms. Examples of POSIX- only requirements are the following: umask must be set to 027, access to the su tool must be limited to the wheel group. Moreover, there might be different requirements for Solaris, BSD, or Linux. For instance, for mandatory access control, Solaris provides Trusted Extensions [3] while Linux integrates Security Enhanced Linux (SELinux) [4]. Likewise, any requirements about Windows registry settings are applicable only to the Microsoft Windows platform. Even for the requirement which is applicable to multiple platforms, chances are that the implementation of the automated check for this requirement will differ among these platforms. Another phenomenon that is worth considering is that the emerging cloud environments call for a new approaches of compliance management, when compared with a traditional (on-premise) datacenters of a single owner. The multi-tenant environments are facing heterogeneous requirements – some of the tenants have a very high security expectations, while others might have medium or none. In addition, the checklists develop in time and need to be maintained. A policy maker has to consider changes in requirements as well as environment changes. Therefore, the checklists are better defined in clear, comprehensive, and technically accurate way, so any misconception between multiple editors becomes borderline impossible.

8 2. Compliance Audit 2.3 U.S. Government Program

Federal and state government departments have long history of considerable involve- ment in the compliance management and the aforementioned challenges of compliance management were of concern to them. In response, they developed Information Security Automation Program (ISAP). ISAP, pronounced “I Sap”, is a U.S. Govern- ment multi-agency initiative to enable automation and standardization of technical security operations [5]. While this is government initiative, it is standards-based and opened for comments and commercial use. Thus, other information security operations can implement and benefit of ISAP. ISAP’s technical specifications are contained in the related Security Content Automation Protocol (SCAP).

2.4 SCAP—Security Content Automation Protocol

SCAP, pronounced “S-CAP”, is a synthesis of interoperable specifications that stan- dardize the format and nomenclature by which software flaw and security configuration information is communicated, both to machines and humans [6], [7]. SCAP is a multi-purpose framework of specifications that supports automated configuration, vulnerability and patch checking, technical control compliance activities, and security measurement. In other words, SCAP is vendor neutral way of expressing security policy. As such it enjoys significant use in modern enterprises [8]. SCAP specifications create an ecosystem where the format of security content is well known and standardized while the implementation of scanner or policy editor is not mandated. Such status enables organizations to build their security policy (SCAP content) once, no matter how many security vendors do they employ.

2.4.1 SCAP Adoption According to the National Institute of Standards and Technology (NIST) Special Publication 800-126r2, "SCAP is achieving widespread adoption by major software and hardware manufacturers and has become a significant component of large information security management and governance programs" [7]. The key step in the implementation of SCAP within the organization is having the security policy in the form of SCAP. This section points out to the government and community initiatives to build SCAP content for Linux systems. Government agencies publish security guidances for their peers. With standardized SCAP format, agencies have guarantee that the consumers will be able to process their guidance. NIST publishes United States Government Configura- tion Baseline (USGCB), formerly known as Federal Desktop Core Configuration (FDCC). Defense Information Systems Agency (DISA) publishes Security Tech- nical Implementation Guide (STIG). Both guidances are available online to the public. Implementation of the government guidances within government bodies is effectively enforced by implementation of Federal Information Security Management

9 2. Compliance Audit

Act (FISMA) [9]. Consumers who have already adopted SCAP begin to exert pres- sure on proprietary guidances such as PCI-DSS [10] in banking or HITRUST in health care sector to provide the guidance in SCAP format. Therefore, security vendors are forced into more competitive1 and open environment, compared to their proprietary stacks. Previously, the security policies were not portable among vendors of security scanners. Finally, third-parties start to produce their own content and build libraries with public content, or even sell content as a service. SCAP Security Guide [12], the Fedora hosted community project, is building a comprehensive SCAP content for Red Hat Enterprise Linux 6 and JBoss Application Server (AS). There are two proprietary vendors building SCAP search engine: Lunarline, Inc. has built SCAP Sync [13] and SecPod Technologies has built SCAP Repo [14]. Both libraries enable users to search SCAP content online.

2.4.2 SCAP Components In its first version, SCAP encompassed six underlying standards, the others were added in later versions. There are also other emerging guidances defining interoperability between SCAP and other standards2. The component standards of SCAP 1.2 include:

• Languages:

– XCCDF: eXtensible Configuration Checklist Description Format [15]— a language to express, organize, and manage security guidance. – OVAL®: Open Vulnerability and Assessment Language [16]—a language for making logical assertions about the state of an endpoint system. – OCIL: Open Checklist Interactive Language [17]—a language to provide a standard way of querying a human user. – AI: Asset Identification [18]—a language to provide a data model for identifying assets, methods for identifying assets, and guidance on how to use asset identification. – ARF: Asset Reporting Format [19]—a language to express the trans- port format of information about assets, and the relationships between assets and reports.

• Enumerations:

1. Strictly speaking, the competition between vendors indeed increases with well-defined and standardized data model, but it may eventually decrease if certification for a given data model is distributed only to a limited number of participants. As per 2013/02/20, National Vulnerability Database lists 32 different companies with SCAP Validated product [11]. 2. SCAP Messages for IF-M [8], defining a format of SCAP messages transfered within Trusted Network Connect environments, is an example of interoperability of SCAP with other standard.

10 2. Compliance Audit

SCAP Component Standards Enumeration Assessment Language CCE CVE CPE use OVAL OCIL SCE

use

Checklist

XCCDF instantiate

CVE XCCDF OVAL Shell Feed Benchmark Deﬁnitions Scripts CCE CPE OVAL OCIL List Dictionary Results Questionare SCAP 1.1 Document Formats

SCAP 1.2 Document Formats

include Asset Reporting Source Format DataStream

Figure 2.1: SCAP Component Standards and Their File Formats

– CCE™: Common Configuration Enumeration [20]—an enumeration of security-relevant configuration elements for applications and operating systems. – CPE™: Common Platform Enumeration [21]—a structured naming scheme used to identify information technology systems, platforms, and packages. – CVE®: Common Vulnerabilities and Exposures [22]—an enumeration of security-relevant configuration elements for applications and operating systems. • Metrics: – CVSS: Common Vulnerability Scoring System [23]—metrics to assign a score to software vulnerabilities to help users prioritize risk. – CCSS: Common Configuration Scoring System [24]—metrics to assign a score to security-relevant configuration elements to help users prioritize responses. • Integrity:

11 2. Compliance Audit

– TMSAD: Trust Model for Security Automation Data [25]—a set of recommendations on how to use existing specifications to represent signatures, hashes, key information, and identity information in the context of an XML [26] document within the security automation domain.

2.4.3 Document Formats For each of the SCAP components mentioned in section 2.4.2, the standard defines a document format with syntax and semantics of the internal data structures. All the component standards are based on Extensible Markup Language (XML) and each component standard defines its own XML namespace. Group of XSD schema filesis released as part of the language specification. Hence, a consumer of document may use this schema to verify formal validity of any SCAP document before accepting it. The ability to validate input data and to determine version of the language specification of the input document is profound for tool implementation. Anytool which is certified against SCAP 1.2 is required to understand all of the previous versions of the component standards. Different versions of the same component standard (language) are often distinguished by different XML namespace (Table 2.1). Unfortunately, this rule doesnot apply to all standards. For example, XCCDF and CPE standards have different XML namespaces for each minor version, on the other hand, the OVAL 5 language has the only one namespace for all of its 11 minor versions. In any case, the format and version of an SCAP document can be determined from the very first XML elements. A elementary SAX-based parser (Simple API for XML) can be built for this task.

Component XML Namespace ARF http://scap.nist.gov/schema/asset-identification/1.1 CPE http://cpe.mitre.org/dictionary/2.0 CVE http://scap.nist.gov/schema/cve/0.1 OCIL http://scap.nist.gov/schema/ocil/2.0 OVAL http://oval.mitre.org/XMLSchema/oval-definitions-5 DS http://scap.nist.gov/schema/scap/source/1.2 XCCDF http://checklists.nist.gov/xccdf/1.2

Table 2.1: XML Namespaces of the Latest Versions of SCAP Components

2.4.4 XCCDF The XCCDF acronym stands for Extensible Configuration Checklist Description Format. As the name suggests, the language is used to describe the security checklists. The language is designed to support information interchange, document generation, organizational and situational tailoring, automated compliance testing, and

12 2. Compliance Audit compliance scoring [27]. The language contains no commands to perform the scan and it is mostly descriptive. Other component documents may be referred from the XCCDF, so one could come to the conclusion that the XCCDF binds all other component standards together. If the XCCDF document is written carefully, it is possible to achieve document which is portable among all the target platforms, and only the assessment documents (OVAL, OCIL) would differ. Like all the SCAP languages, the XCCDF is based on XML and defines its XML elements and attributes. Figure 2.2 represents a simple XML DOM structure of XCCDF document. The XCCDF documents tend to be several hundred lines long. Short example of XCCDF document may be found in Appendix A. The following section describes main XCCDF elements briefly, focusing on the relation between them. The language specification describes all the elements in greater detail, andit can be consulted in the NIST Interagency Report 7275 Revision 4 [15].

Benchmark Profile 1 selector Profile 2 set-value Value 1 refine-value Rule 1 refine-rule Group 1 Rule 2 Rule 3 Rule 4 fix Rule 5 check TestResult rule-result

Figure 2.2: Basic Structure of XCCDF Benchmark Document

2.4.4.1 Short Description of XCCDF Elements The element encompasses the whole document, it may contain metadata regarding checklist as whole (title, description, list of authors, date of the latest modification, and status of the checklist’s acceptance). Each requirement of the checklist needs to be represented by element, which contains text description of the requirement and perhaps rationale behind the requirement. The

13 2. Compliance Audit

child element refers to the external resource which defines how to evaluate the given rule. The external resource may be either OVAL, OCIL, or SCE (Script Check Engine—the OpenSCAP extension of SCAP) document. The child element on the other hand defines, how to remediate systems which are not compliant with the rule. Similar and elements can be gathered together by element or by an orthogonal method—through cluster-id. Using nested elements, the requirements in XCCDF document can be formed to the tree structure based on the same context or connection between domains of requirements. The XCCDF standard allows different security policies to be stored in a document. That is made possible by turning elements on and off. Each element represents different policy and contains elements which modify behaviour of the , , and elements. Usually, only one profile is used during the XCCDF scan on the target system. In security guidances, there are some requirements bound to a certain value. On one hand, the requirement for server accounts can be to not allow passwords shorter than 16 characters, on the other hand, on desktop accounts passwords long only 12 characters may be tolerable. In such cases, the variables can be extracted to the elements. The element defines all the possible settings of given variable and the final choice is made for each by or element. The XCCDF format not only allows to store scanning instructions, but it also allows to save the results of scan at the end of the same document. Each finished scan is represented by single element. Each should refer to the which was used to define the policy for this particular scan. should also include information about the evaluated system, like IP address or other target-facts. Results from the security scan are stored within the rule-result element. For each selected element from the policy, there is at least one rule-result element. Table 2.2 shows 7 possible results for the evaluation as defined by XCCDF specification.

2.4.5 OVAL The OVAL acronym stands for Open Vulnerability Assessment Language [16], it is very essential and the oldest component of SCAP. The main goal of the OVAL standard is to enable interoperability among security products. That is achieved by standardization of the following three domains:

1. Representation of the configuration information of a system.

2. Analysis of the target system for the presence of a particular machine state.

3. Reporting the results of the comparison between the specified machine state and the observed machine state.

14 2. Compliance Audit

Result Description pass [P] The target system or system component satisfied all the conditions of the . fail [F] The target system or system component did not satisfy all the conditions of the . error [E] The checking engine could not complete the evaluation, therefore the status of the target’s compliance with the is not certain. This could happen for example if a testing tool was run with insufficient privileges and could not gather all of the necessary information. unknown [U] The testing tool encountered some problem and the result is unknown. For example, the result of ‘unknown’ might be given if the testing tool was unable to interpret the output of the checking engine (the output has no meaning to the testing tool). notapplicable [N] The was not applicable to the target of the test. For example, the might have been specific to a different version of the target OS, or itmighthave been a test against a platform feature that was not installed. notchecked [K] The was not evaluated by the checking engine. This status is designed for elements that have no elements or that correspond to an unsupported checking system. It may also correspond to a status returned by a checking engine if the checking engine does not support the indicated check code. notselected [S] The was not selected in the benchmark. informational [I] The was checked, but the output from the checking engine is simply information for auditors or administrators; it is not a compliance category. This status value is designed for elements whose main purpose is to extract information from the target rather than test the target. fixed [X] The had failed, but was then fixed (possibly by a tool that can automatically apply remediation, or possibly by the human auditor).

Table 2.2: Possible XCCDF Results for a Single Test as Defined in XCCDF 1.2 [15]

Unlike other tools or custom scripts, the OVAL language describes a desired state of resources in declarative manner. The OVAL language code is never executed directly, but by means of an OVAL interpreter tool (scanner). The declarative character of OVAL language ensures that the state of assessed system will not be

15 2. Compliance Audit accidentally modified, which is important as security scanners are often runwith highest possible privileges. The elements of the OVAL language correspond to resources of an operating system. These elements are classified into groups based on the operating systems which they support. For example, the following three groups are applicable on Linux systems: independent, unix, and linux. The OVAL language specification is opened for public comments and contribution. Indeed, various IT companies join their efforts and collaborate under the heading of MITRE Corporation, federally funded not-for-profit organization. The OVAL specification is continuously evolving. Different editions are distinguished by version number. The current version 5.10.1 was released in January 2012. For comparison, the OVAL 3 (the oldest version available) was published in May 2005.

2.4.5.1 OVAL Document Formats Like all other SCAP components, the OVAL language is based on XML file format. The OVAL standard defines several file schemas. Each of them includes different kind of information and each serves a different purpose. • OVAL Definitions is the most common file format as it is used directly for scanning. The definitions describe desired configuration of the system. The OVAL Definitions document consists of five parts: definitions, tests, objects, states, variables. Each configuration requirement included in the document is divided into these parts. The elements within the definitions part describe which of the tests shall be fulfilled to satisfy the given definition. The tests elements links objects and states together. During the evaluation, a test is considered passed when a resource (of the assessed system) denoted by the given object element correspond with the given state element. The variables section defines external variables which may be used to adjust states elements. • OVAL Variables document contains definition of the variables which amend the OVAL Definitions document. • OVAL System Characteristics holds information about the assessed system. Prevailing are the objects elements which correspond with objects elements of OVAL Definitions. • OVAL Results is the most comprehensive form of results of the evaluation. This document contains copy of the evaluated Definitions, binded Variables (if any), System Characteristics, and results of tests which are computed based on the comparison of the system characteristics and the definitions. • OVAL Directives is rare compared to aforementioned formats. Directives can be used to tailor verbosity of the OVAL Results document by either including or eliminating certain details.

16 2. Compliance Audit

2.4.6 DataStreams DataStream is a new file format introduced by SCAP 1.2 specification [7], its sole purpose is to bundle other SCAP component files into a single file. That is based on the insight that one file is much easier to handle when compared to agroupof files. The DataStream is a simple XML format consisting of a heading which represents a table of file contents and a list of elements. Each of encompasses a SCAP component file format—XCCDF, OVAL, or CPE. A DataStream file may include multiple components of the same type, therefore it may contain all the security policies needed by an organization.

2.4.7 Asset Reporting Format Similar to the DataStreams which concatenate multiple security policies into a single file, the Asset Reporting Format (ARF) consolidates multiple result files (OVAL results and XCCDF results). ARF can be used to merge results from the repeated assessment of a single target or results from multiple targets. The ARF consists of three kinds of information: description of assets (target systems), report requests (the SCAP policies), and reports (results of evaluation) [19]. ARF maintains relationship between these three components—each report is assigned to a single asset and single report request.

2.4.8 Forms of SCAP Security Policy Security policy expressed in SCAP can take one of the following four forms: 1. Single OVAL file—This form is the oldest and by its nature it does not allow flexibility beyond the OVAL language. Use cases for this option are limited. The OVAL language does not allow to specify different profiles for different targets, neither it allows different code for different platforms. The policy in single OVAL file is effective in cases when the requirements are confined in some way, that is when the policy is targeted to a single platform, to single piece of software, or to single setting. Such policy often does not fully comply with all requirements of organization and is suitable only for use in conjunction with other policies. For example, the software company may provide a guidance for one of its products, the guidance which is independent on the product usage and deployment. That is the case for Red Hat which provides OVAL definition for each of Red Hat Security Advisories, allowing customers to use the OVAL definition to verify that their systems are updated with the most recent security advisories [28]. 2. Group of XML files—The group must contain an XCCDF file representing policy checklist. This XCCDF file points to the assessment resources, multiple OVAL, OCIL, or SCE files. Furthermore, there may be CPE dictionary

17 2. Compliance Audit

file and OVAL file defining objects for CPE dictionary. Optionally, there might be OVAL patch file. SCAP 1.0 and 1.1 standards define naming con- vention for these files in the group [29], [30]. Each file shall have thesame prefix and the filename suffix determines type of the file as described inthe Table 2.3.

Component Filename Suffix XML Document Element XCCDF Benchmark *xccdf.xml OVAL Compliance *oval.xml OVAL Vulnerability *oval.xml OVAL Patch *patches.xml OCIL Questionnaire *ocil.xml CPE Dictionary *cpe-dictionary.xml CPE Inventory *cpe-oval.xml

Table 2.3: SCAP Vulnerability Assessment Data Sources [30]

The table also shows root XML element of each component standard together with commonly seen XML namespace shortcut, the full XML namespace depends on the version of the standard used.

3. Single zip file—an archive that contains files as described in the item above. While such zip archive is not a part of standard, it is very common. Na- tional Institute of Standards Technology uses this form for guidances they publish [31] and the majority of security policies available under National Checklist Program Repository at National Vulnerability Database [32] use this form as well. There is even U.S. Military scanner, SCAP Compliance Checker (SCC), that requires content to be packaged in a zip file [33].

4. DataStream—DataStream is new file format available since SCAP 1.2. It is basically bundle of the component files from item 2. DataStream also contains an index and catalogue to enable splitting into the component files.

Note that for a security scan based on policy format 2, multiple filenames need to be passed down to the scanner tool. For options 3 and 4, the scanner tool is able to extract all the required components from the archive.

2.4.9 SCAP Challenges

Even though SCAP is open standard and authors listen to community ideas, one can still have concerns which are worth mentioning.

18 2. Compliance Audit

2.4.9.1 Human and Machine Readable Format SCAP languages (formats) are based on XML and intended to be readable by machines and to some extent also by humans. Nevertheless, there is inherent trade- off between these two requirements. Parts of the format which are easier forhumans to write will always be harder for machines to process and other parts which are easier for machines to process might never become obvious to humans. As a result, compromises made in format design have drawbacks for both, humans and machines. As an example, consider XCCDF selectors and their processing, the mechanism which allows users to define selection of certain XCCDF Item based on XCCDF profile. The selection of an XCCDF Item is determined by multiple factors, eachof the following settings can have true/false values:

• selected attribute of the given item (default setting)

• selected attribute of the groups containing the given item

• selector elements within the profile referring to the given item

• selector elements inherited from the parent profile

• selector elements in the tailored profile

• selector elements referring to the cluster-id of the given item

• requires/conflicts dependencies, child elements of the given item

This separation of information is to minimize duplicate definitions. While it seems to be easy for humans to write, it may not be that easy to read as the final value needs to be calculated in line with the standardized algorithm. Thus, the content author may become unsure about the outcome at the time of writing. Similarly, there is a barrier for computers which can use the algorithm to figure out the final value but might have hard time writing the selectors in automated manner.

2.4.9.2 Limitation of Interoperability Secondly, even though there are detailed specifications to avoid misconceptions and to ensure interoperability, there is still a risk for the SCAP languages that multiple “dialects” will emerge around different implementations. There are several reasons why it could happen. First of all, consider the wide scope of SCAP standard and the rapid growth of features that are being added, it is not an easy task to develop SCAP scanner in line with the standard. Next, consider a published content which has been authored in line with some reference implementation (that which was available to authors in the time of writing). Such content may include workarounds for the given implementation as well as nonstandard features. Finally, having a content containing something non-standard effectively pushes the following products to implement these non-standard parts as well. Although there is a process for

19 2. Compliance Audit independent third party testing, a process to certify SCAP implementation which ensures that a given implementation will be interoperable with others, the users shall keep in mind that there is still risk for corner cases to stay non-portable. Furthermore, parties which decide to develop SCAP scanner are neither able to make predictions about SCAP future versions nor they can be sure to be able to afford implementation of the future versions. This together with possible floodof new features may have an adverse impact on a number of implementations. Besides of the benefits for users of different SCAP vendors compete each other, it’salso needless to admit that there might be the same benefit for vendors if there were multiple standards competing for implementations.

20 Chapter 3 OpenSCAP

OpenSCAP is an open source implementation of SCAP. According to the project web page, it is an initiative to create a framework of libraries and tools to improve accessibility of SCAP and enhance the usability of the information it represents [34]. The main parts are a library which provides interface to SCAP document processing and evaluation, and a command-line SCAP scanner (called oscap) which makes use of the library exposing the most common functionalities on the command-line.

3.1 OpenSCAP Library

The OpenSCAP library is written in C language and it exposes its capabilities as shared library named libopenscap.so. Major part of the library is code parsing SCAP documents from XML files to a data model. Data model provides one-to- one mapping between SCAP objects and C language structures. For each of the structures, there are multiple functions manipulating it and performing various algorithms as defined by SCAP specification. These functions allows users of the library to manipulate SCAP documents similarly as the XML DOM. However, the abstraction of the library keeps users to stay focused on their domain. Library allows users to load, scan, modify, and export SCAP documents. Besides the command-line tool, a graphical front-end to SCAP called SCAP- Workbench has been build on the top of the OpenSCAP library. SCAP-Workbench can help with scanning, tailoring, editing, and validation of SCAP documents [35].

3.2 OpenSCAP Tool: oscap

In 2009, the OpenSCAP project started as an effort to create shared library in C language to facilitate processing of data in form of SCAP. Later during the development when the library was mature enough to perform the scan, it became clear that the command-line tool to process SCAP is the only missing piece, and thus natural next step for the development. The shared library offers wide selection of SCAP functionalities, however onlya limited set of features is needed in day-to-day use of SCAP. The oscap command-

21 3. OpenSCAP line utility is a simple front-end to the OpenSCAP library, it groups its functionalities into sub-commands called modules. The tree of available modules is illustrated in Figure 3.1. The first level of modules is named after the component standards they implement, the second and the third level determine the operation which shall be accomplished. Each module defines its own command-line switches which are described in great detail inmanual page [36]. Brief description can be invoked by --help switch supplied to the given module, like oscap xccdf eval --help.

oscap

xccdf generate report eval guide resolve ﬁx validate custom export-oval-variables

ds sds-split sds-compose oval collect sds-validate eval rds-create analyze rds-validate validate generate report list-probes

cpe match check cve ﬁnd validate validate

cvss describe score

Figure 3.1: Schema of oscap Command-Line Modules

3.2.1 Output of oscap xccdf eval When the oscap command finishes the evaluation of XCCDF, it produces numerous outputs which can be captured by caller (parent process). 1. Return Value—After successful scan oscap tool returns 0 value. The value 1 indicates an internal error during the evaluation and value 2 indicates that scan finished successfully but the assessed system was not in compliance with the policy. More precisely, the value 2 is returned when there was at least one rule-result element which ended up with result either fail, error, or unknown (semantics of these results is described in Table 2.2).

22 3. OpenSCAP

2. Text Output—During the evaluation, oscap command produces a text on the standard output (stdout). For each selected xccdf:Rule, multiple lines are printed-out. One is the content of xccdf:title element of the given xccdf:Rule, next are the @id attribute and the result of evaluation. Newer versions of OpenSCAP (since version 0.9.1) output also assigned CCE or CVE identifiers assigned to the Rule. Unfortunately, this text output is not suitable for machine parsing. First of all, the format has been slightly changing, but even more importantly there is no limit on what the xccdf:title may contain. OpenSCAP 0.9.3, introduced new command-line option --progress which forces the oscap tool to produce machine readable output. 3. XCCDF Results File—The output which is compliant with SCAP standard and described in Section 2.4.4. This file consists of the input XCCDF file and newly created element which is appended at the very end. This output is optional and can be invoked by --results command- line option. 4. OVAL Results Files—The input XCCDF document may reference OVAL definitions files. Whenever the OpenSCAP scanner uses such OVALdefi- nitions to assess system characteristics, the scanner creates OVAL results model. The OVAL results models are exported to the respective files (one for each definition file on the input) when the --oval-results command-line option is supplied. 5. ARF File—Asset Reporting Format file as described in Section 2.4.7. The command-line option --results-arf which generates this output is available only since OpenSCAP version 0.8.4. 6. HTML Report—Non standard output which summarizes scan results in a human readable document. It can be invoked by --report

3.3 SCE: Script Check Engine

OpenSCAP project was established on Fedora hosted and it is well maintained in Fedora repositories. Even though the project has active community of contributors and enterprise users, an average Fedora user (as an opposite to enterprises) is not using SCAP to audit his environment. The problem with SCAP adoption is related to its complexity and especially to a difficulty of setting things up. An SCAP content is hard to write for humans. The most complicated is the OVAL language which is, in comparison with XCCDF, much harder to write or even comprehend. Furthermore, not every security specialist is an expert on writing OVAL content, but most of them can handle a scripting language. In attempt to overcome the problems mentioned, OpenSCAP community has developed Script Check Engine (SCE), an equivalent or a substitution to OVAL [37].

23 3. OpenSCAP

With the SCE-enabled OpenSCAP, users are able to develop their content using scripts instead of OVAL. Of course, it is still necessary to write XCCDF but that is significantly easier. As a benefit, they are able to develop their SCAP checklist in short time and apply OVAL only when needed. SCE is not a part of official SCAP standard, however it already has twoinde- pendent implementations: OpenSCAP and jOval.

3.3.1 Exemple of SCE Content The following is an sample script named telnet_server.sh. This script can be executed by a scanner (either OpenSCAP or jOval) when the scanner attempts to evaluate the second element from the exemplary XCCDF in Appendix A. The scanner exports certain variables to the run-time environment of the script. These variables represents possible XCCDF results as described in Table 2.2. The script is supposed to return a single one representing the result of the assessment. #!/bin/sh

if rpm -q --quiet telnet-server; then echo "The telnet server is installed!" exit ${XCCDF_RESULT_FAIL} fi

exit ${XCCDF_RESULT_PASS}

3.4 Security Guidances Related to OpenSCAP

The OpenSCAP community not only provides tools for SCAP content (data) processing, but there are also efforts to create said content. The objective of these efforts is to create high-quality guidance for security hardening of Linux operating system and open source applications. The OpenSCAP project subserves as a tool and the test bed for these content authors.

3.4.1 Platform Limitations of Security Guidances For the time being, the efforts to create security guidance for Linux focus mainlyon Fedora Linux, because of the community of authors who are particularly concerned with audit of Red Hat Enterprise Linux, the commercial derivate of Fedora Linux. Even though the SCAP specification ought to increase portability of security policies, there are still certain limits for migration across different Linux distribution. While the description (XCCDF) part of the content may be written in the way that it conforms to majority of the Linux distributions, the execution layer, the OVAL part of the content, needs extra adaptation for each distribution.

24 3. OpenSCAP

Security policy for Linux operating system closely relates to the system settings and to the installed package set, which are domains in which various Linux distributions differ. For instance, OVAL 5 language defines different objects for DPKG, RPM, and Slackware package managers [38]. Some of the OVAL statements for one package manager can be transformed to conform with another, however that is not possible in general case because the features of package managers exposed to OVAL language are not fully compatible. The properties of RPM package manager in particular are the most exposed to the OVAL language. That may be related to the inclusion of RPM to the Linux Standard Base [39] and therefore the canonization of some RPM structures. Unlike others, OVAL objects for RPM allow to query or verify package signatures and content of installed packages. This section introduces three projects which focus on developing SCAP content for Linux. These projects were used as reference and testing content for the integration work which is the topic of this thesis.

3.4.2 OpenSCAP Example Content

During the autumn 2010, sample SCAP content has been developed for Fedora Linux 14 and it is since distributed as a part of OpenSCAP project [40]. This content is most likely based on United States Government Configuration Baseline (USGCB) for Red Hat Enterprise Linux 5 Desktop and amended for use on newer Fedora Linux. Nevertheless, this project can be hardly seen as a full-fledged security guidance, that was not even the goal. The aim was to a develop content for Fedora Linux and demonstrate the use and the benefit of SCAP to the open source community. This content is no longer applicable to the latest Fedora Linux (Fedora Linux 19 in the time of writing) because of the recent changes in Fedora Linux, mainly the new init system [41] (systemd is not compliant with POSIX run levels) and the /usr move [42].

3.4.3 SCAP Security Guide

SCAP Security Guide project is currently the most evolved and elaborate SCAP policy for Linux systems. The project provides practical security hardening advice for Red Hat products and also links it to compliance requirements in order to ease deployment activities, such as certification and accreditation [12]. The project started in 2011 as open collaboration of U.S. Government bodies to develop next generation of United States Government Baseline (USGCB) available for Red Hat Enterprise Linux 6. There are multiple parties contributing to the project besides the public sector, Red Hat and Tresys companies support it as well. In addition to the policy for Red Hat Enterprise Linux 6, which is the major focus of the project, there are policies growing for other Red Hat products (JBoss Application Server 5, OpenStack, and Red Hat Enterprise Virtualization Manager

25 3. OpenSCAP

3). Even though current focus of the authors is on Red Hat products, they claim the interest in other Linux distributions as well [43].

3.4.4 SCE Community Content SCE Community Content serves as a repository for any SCE content developed by community [44]. The project was started by Red Hat in early 2012 as a demon- stration of SCE standard draft and its implementation within OpenSCAP scanner. The project currently holds policies for the following three security guidances in various stages of development. • Security Technical Implementation Guide (STIG) • National Industrial Security Program (NISPOM) • Payment Card Industry Data Security Standard (PCI DSS) All three guidances originate from third parties, the SCE Community Content only holds their implementation in SCE.

3.5 OpenSCAP Competing Projects

OpenSCAP is not the only project implementing the SCAP standard. This section briefly enumerates notable SCAP projects which are open source. Closed-source (proprietary) implementations of SCAP standard were not consider for this work even though large firms offering security software often have their own implementation of the SCAP in their product portfolio.

3.5.1 OVALDI Project The OVAL Definition Interpreter is a freely available reference implementation that demonstrates the evaluation of OVAL Definitions [45]. It was developed by MITRE Corporation to promote usage of open security content (OVAL) in early stages of the OVAL development. The OVALDI project was open-sourced in early 2008 but its copyright notice mentions year 2002 as a starting point. The OVALDI supports only OVAL, other component standards are not included in the interpreter. The OVALDI is written in C++ and licensed under the BSD license. The OVALDI is primarily a reference implementation and therefore some of its features are limited.

3.5.1.1 Comparison with OpenSCAP In comparison with OpenSCAP, OVALDI project: • has broader base of supported platforms, even though there were successful attempts to compile OpenSCAP on Microsoft Windows, the OVALDI project is distributed and actively being used on Microsoft Windows.

26 3. OpenSCAP

• implements only a limited set of OVAL objects (probes) in comparison with OpenSCAP, which implements all OVAL objects which are applicable to the Linux platform.

• supports only the latest version of OVAL language. However, there is a certification requirement that the SCAP-validated tools has to support older versions of component standards.

• implements only OVAL component standard, while the increasing number of guidances include XCCDF and CPE components.

• provides no library interface, only the command-line utility. OpenSCAP provides wider range of capabilities.

3.5.2 XCCDF Interpreter Similarly as MITRE Corp. provides the OVALDI reference implementation of its OVAL standard, the National Institute of Standards and Technology (NIST) provides the reference implementation of the XCCDF called XCCDF Interpreter. It is written in Java and published as public domain. The XCCDF Interpreter is distributed together with OVALDI and OCIL Interpreter. The comparison to OpenSCAP and the XCCDF interpreter, is analogous to the OVALDI. From a comparison to OpenSCAP, the XCCDF Intepret comes out very much like OVALDI.

3.5.3 jOval Project The jOVAL project is open source implementation of SCAP 1.2 in Java language [46] published under Affero GPL 3.0 [47]. The project was started in the middle of2011 and since then it is led by a single developer, David A. Solin. jOVAL uses Java Architecture for XML Binding to load SCAP XML documents [48]. JAXB framework provides the ability to parse XML objects to Java objects and to marshall them back to the XML. This feature significantly eases development of SCAP tool, as the majority of the input and output processing code can be generated from XML Schema Definitions (XSD) which are distributed together with each component standard. Unfortunately, this abstraction may entail limits on the support of multiple SCAP version. JAXB is able to generate Java classes from single XSD, while each SCAP component version brings its own XSD. Each JAXB generated class (or property), may define only single XML namespace by namespace= annotation. Conse- quently, the JAXB-based parser is able to parse only one version of SCAP component. Currently, when jOVAL is used to parse XCCDF 1.1 document, it calls embedded XSLT transformation to convert the document to XCCDF 1.2 in memory before un-marshalling.

27 3. OpenSCAP

3.5.3.1 Comparison with OpenSCAP In comparison with OpenSCAP, jOval project: • supports more operating systems platforms. The jOval claims to support Unix, Cisco, Juniper, Microsoft Windows, MacOS X, and Mobile (iOS) [49]. The OpenSCAP concentrate primarily on Linux systems, but it can be run on Oracle Solaris and BSD Unix. • incorporates XML digital signature validation (through XPERT), while the OpenSCAP requires user to validate the signatures prior to the scan. • natively supports SCAP 1.2 but not SCAP 1.1 while the latest OpenSCAP supports both standard versions natively. • implements OCIL component standard which is not implemented by Open- SCAP • does not implement remediation while the latest OpenSCAP does. • offers plug-ins (under commercial licence) for offline and remote scanning. The OpenSCAP does natively support neither, even though there is proof of concept for remote scanning [50] and the offline scans for KVM guests are actively being worked on. • is written in Java, thus requires Java Virtual Machine (JVM), while system requirements of OpenSCAP are minimal. • uses shell commands to assess system that allows jOVAL to scan remote machines, even without having agent software on the target machine. This is in contrast with OpenSCAP which uses its own binaries (called probes) to assess the system characteristics. While this difference is hidden from user, it has certain implications. For example, OpenSCAP probes are highly optimized for their respective objectives. Separate binaries can also have distinguished SELinux context. Overall, the jOval tool is a mature project and can be considered for the integration with other tools. Nevertheless, in early 2012 when this work has started, the OpenSCAP had considerably bigger user base. At that time, the state of the SCAP 1.2 conformance was similar among both projects, however the OpenSCAP had already supported SCAP 1.1.

3.5.4 Modulo Open Distributed SCAP Infrastructure Collector Modulo Open Distributed SCAP Infrastructure Collector, abbreviated to modSIC, is open source implementation of OVAL standard by Modulo Security, LLC as a part of their Modulo Risk Manager product [51]. The modSIC is written in C# and published under 3-clause BSD Licence. The project was started in early 2012, therefore it could not be considered for integration with Spacewalk.

28 3. OpenSCAP

3.5.4.1 Comparison with OpenSCAP In comparison with OpenSCAP, the modSIC project • implements only the OVAL component standard. • implements only the OVAL version 5.9, while other tools in this section support the latest (5.10.1) version.

• has better support of non-Linux systems as it focuses on Microsoft Windows customers.

29 Chapter 4 Spacewalk

Spacewalk is a complex, web based systems managing system, designed for Linux clients with the RPM package manager [52]. Besides the systems, Spacewalk is able to manage packages, errata, package channels, and custom non-RPM content. Spacewalk can administer client systems from a source provisioning1 through the whole life cycle. Spacewalk is able to establish remote commands, remote package management, configuration, and monitoring. To understand the details of architecture, one might find it helpful to learn the history and the purpose first. Spacewalk features and capabilities are not described in a detail2 with the exception of Software Channels and Configuration Channels and remote client actions which are essential for this work.

4.1 A Short History of the Spacewalk

The project was started in June 17, 2008 by opensourcing Red Hat Network Satel- lite [53]. However, its genesis dates back to 2000, when the Red Hat Network was opened for public [54]. Since then, Red Hat Network, abbreviated as RHN, serves as a publicly available mechanism for maintaining Red Hat Enterprise Linux machines. Besides of the updates and the distribution of installation media, the RHN allows customers to manage their systems and subscriptions. Centralized architecture of RHN used for a package delivery leads to a high load of RHN and high Internet bandwidth usage for customers with multiple subscriptions. To address this problem, Red Hat Network Proxy has been released. It is deployed at customers where it caches the packages to speed up a secured download [55]. The Red Hat Network Proxy can also be an assistant for building separate network segments. Considering rapid growth of customer base, the solution of RHN Proxy had still need of improvements. Management capabilities were limited by design and the content delivery system was highly dependent on the Internet access. Such depen- dency was not acceptable for local area networks disconnected from the Internet, e.g. because of the security concerns.

1. The automated installation of the operating system. 2. Spacewalk features and capabilities are well documented on the project wikipage [52].

30 4. Spacewalk

In February 2002, Red Hat released Red Hat Network Satellite, providing users much greater functionality and allowing customization [55]. The first releases of the RHN Satellite were based on the code of the RHN. Later, development of the RHN and the RHN Satellite has dispart and each team has focused on a different set of features. By opensourcing RHN Satellite, Spacewalk project was brought to life and it became an upstream of the next releases of RHN Satellite (the 5.3.0 and higher). Over the years, Spacewalk project received great interest from community as evidenced by live communication on the mailing lists [56]. In December 2010, Novell joined Red Hat in productization of Spacewalk and announced SUSE Manager 1.2 as an appliance based on Red Hat and community work [57].

4.2 Spacewalk Deployment Model

Figure 4.1 shows the comparison of the deployment models focusing on the management and the capabilities of the content delivery. Customer A uses a direct connection to the provider while customer B has the management system (Space- walk in this case) deployed in his private network [58]. Having all the machinery in the private network gives the customer B extra abilities like monitoring, which might not be doable through the wide area network (the Internet in this case). In addition, customer B can be separated completely from the rest of the computing world, which might be needed for high security deployments.

web web interface interface

Content Spacewalk delivery network

systems systems

IT custom applications content

customer A customer B

Figure 4.1: The Comparison of the Deployment Models [58]

4.3 Spacewalk Competing Projects

There is no other open source project with comparable set of systems management capabilities. Administrators maintaining Linux environments and not using Spacewalk either write their own scripts to help with systems management or use

31 4. Spacewalk multiple small projects which focus only on single domain of systems management, for instance Puppet is popular configuration manager. Recently, together with cloud-computing trend, multiple systems management projects have been started. Of them the closest (feature wise) to Spacewalk is Katello project which is umbrella project integrating three existing stand-alone projects: Candlepin for subscription management, Pulp for repository and content management, and Foreman for provisioning and configuration management [59]. Other cloud concerned projects like OpenStack or OpenShift do not focus on management of single system, but rather on providing infrastructure or platform as-a-service. Nevertheless, the above mentioned emerging technologies are developed in rapid pace, they often lack the user base which is concerned with compliance audit. Given its widespread adoption [60], OpenStack could be good candidate to integrate with SCAP scanner.

4.4 Server Architecture

Spacewalk consists of the server code deployed on the Apache HTTP server, the backend tools, the daemons, and the database [61]. Majority of Spacewalk functionalities are available through the web user interface and web services for automation, although the root access to the underlying machine might be needed for some of the management actions. For example, the whole stack can be turned on and off by rhn-satellite command-line tool.

4.4.1 HTTP Server The code deployed on the Apache HTTP server compounds of several programming languages, each of stacks has separate responsibilities. There is a Python code which handles the communication with the clients, a Perl code serving a minority of the Web pages [62], and finally a Java rendering most of the Web pages and providing frontend API calls. The Apache handlers communicate by XML-RPC3, HTTP and HTTPS protocols [64]. The client systems invoke the remote procedure calls (XML-RPC), which are dis- patched by the Python backend stack [65]. This model is used for most of the client actions, the example might be the registration of a new client which involves many backend calls. However, the XML-RPC is not the only way for the client communication, clients may use the HTTPS for package download, XMPP for real-time messaging, ssh for the monitoring, or tftp in the very beginning of the client’s life cycle4. The Perl and the Java parts form the Spacewalk web user interface, exposing most of the Spacewalk management capabilities. The Java also serves the frontend XML-RPC interface providing an equivalent to considerable part of web’s management capabilities. The custom IT applications (on Figure 4.1) are utilizing just the

3. The protocol for remote procedure calls encoded in XML [63]. 4. The tftp protocol is used during the network boot of a client, when the system is being provisioned (Kickstarted).

32 4. Spacewalk

Spacewalk Server Search Database Taskomatic Server

OSA Dispatcher

Apache Web Server Perl Tomcat Python Cobbler Monitoring Jabber Handlers Handlers Daemon Daemon Daemon

Front-end Web User Back-end Provisioning SSH XMPP XMLRPC API Interface XMLRPC API FTP & HTTP Probes

XMLRPC Web RHN PXE Client, RHNMD OSAD Client Browser Client Tools Anaconda Daemon Daemon Client System Managed by Spacewalk

Figure 4.2: Spacewalk Architecture: Principal Daemons and Services and Commu- nication Channels Towards Clients [61] frontend API. The long-running actions (scheduled either on a Web or XML-RPC interface) are inserted into the queue and executed asynchronously by the Tasko- matic daemon [66].

4.4.2 Backend Tools The backend tools are command-line tools on the Spacewalk server providing additional management functionality to the Spacewalk administrator. These tools can manipulate a database, export and import software channels, generate various reports, or upgrade the Spacewalk.

4.5 Database

All the data stored by Spacewalk server is integrated in a single database instance. The Spacewalk server supports two database backends: Oracle and PostgreSQL. Traditionally, Spacewalk runs on Oracle database, but since June 2008, there have been an effort to support the PostgreSQL as well [67]. At present, PostgreSQL port is considered to be functional [68] and any future development of Spacewalk must not break neither of Oracle or PostgreSQL support.

33 4. Spacewalk

4.5.1 Differences between PostgreSQL and Oracle Each of the database engines (PostgreSQL and Oracle) supports different dialect of SQL language. Some of the SQL statements can be written in form conforming both databases, however sometimes the application requires certain database feature which has different syntax in each dialect [67]. As an example consider stored procedures. Oracle has its own extension SQL called Procedural Language/Structured Query Language (PL/SQL) [69]. PostgreSQL has similar extension called PL/pgSQL [70]. Even though some of the syntax prim- itives are similar among the two, there is a lot of differences. The same data types have different name, consider PostgreSQL’s numeric versus Oracle’s number. Or- acle offers the SELECT without INTO clause, but in PostgreSQL, this needs to be converted to a stored procedure using the perform statement [71]. The excep- tions which can arise during executions are different, compare PostgreSQL’s when unique_violation to Oracle’s when dup_val_on_index. The autonomous trans- actions in PostgreSQL can be nested within the procedure using the dblink_exec, while Oracle requires the whole procedure to be autonomous. In Spacewalk, majority of the DML (Data Manipulation Language) queries is written in form which is compliant with both database engines. Some of the DDL (Data Definition Language) statements are written separately for each database engine, others are derived from the common source in the compile time using text substitution tool (sed).

4.6 Concept of Software Channels

Packages managed by Spacewalk server are grouped to sets called software channels. Channels are associated to the clients and their purpose is to define the content intended for the client. A software channel can be either base or child. The client system can be associated with one base channel and a number of its child channels. From the client perspective, the channel is very similar to any other software repository. Thus, Spacewalk has to provide equivalent repository metadata for each of managed channels. However, the difference between channels and standard repositories is a client authorization. Spacewalk does not serve the content unless the client is authenticated and authorized to consume it. Each client request is evaluated respectively considering the client system, the channel and the package identifier.

4.7 Concept of Configuration Channel

Spacewalk is able to manage configuration files on the client system. Remote configuration files can be read, deployed, and compared by Spacewalk. The configuration files distributed by Spacewalk to the client systems canbe grouped into channels in similar way as software packages. However, these two groups of channels are strictly separated. While package channels are inherent to

34 4. Spacewalk the Spacewalk infrastructure, the configuration channels are optional and they need to be explicitly enabled on the client system by installing rhncfg packages.

4.8 Remote Client Actions

Spacewalk has a concept called RHN Actions for execution of commands on the remote system it manages. Any event which happens on the client system and which is issued by Spacewalk falls into this category. All events are grouped into types based on the semantics of the event and each type takes different arguments. Table 4.1 shows number of selected RHN action types out of total of about 50 types.

Type Identifier Type Description package.refresh_list Request to refresh list of installed packages hardware.refresh_list Request to refresh hardware profile packages.update Request to update given packages packages.remove Request to remove given packages packages.verify Request for verificationrpm ( -V) of given packages kickstart.initiate Request for reinstallation of the operating system reboot.reboot Request for system reboot configfiles.upload Request to upload given file to Spacewalk configfiles.deploy Request to deploy given file from Spacewalk script.run Request to execute given script virt.start Request to start given virtual domain virt.shutdown Request to shut given virtual domain down

Table 4.1: Selected types of RHN Action

The RHN Action types provide an abstraction to Spacewalk server. The server does not need to know the exact command which needs to be executed on the managed client to implement the action. The implementation may vary among different Linux distributions or distribution versions. For example, systems with Apt package manager and Yum package manager are transparent for the Spacewalk server considering packages.* actions.

4.8.1 Life-cycle of RHN Action When a Spacewalk user schedules an action for a managed client system, the action is stored in the Spacewalk database. The database keeps track of the following information: type of the action, arguments of the action, applicable systems, user who issued the action, time of its earliest occurrence and the state of the action which is at beginning set to Queued. The action transitions to the Picked Up state once the client system reads the action from server. The client system executes the action and reports back to the Spacewalk, based on the results the RHN Action transitions either to Completed

35 4. Spacewalk

Figure 4.3: State diagram of RHN Action or Failed state. If the client fails to report the result back, the action stays in the Picked Up state. The action which Failed to finish properly can be rescheduled by Spacewalk administrator.

4.8.2 Client Tools Supporting Remote Actions

On the client system, there is an agent software which pulls the actions from Space- walk and which is able to execute these actions. The majority of the client code is written in Python like the Spacewalk server backend which handles communication with this client.

4.8.2.1 rhn_check utility

On the client, as a part of rhn-client-tools package, there is a rhn_check utility which communicates with Spacewalk through XML-RPC protocol as illustrated on Figure 4.2. The rhn_check authenticates client system with Spacewalk server and downloads a list of scheduled actions together with arguments. The rhn_check has pluggable interface for implementation of RHN Actions. Each action type is registered as a separate method and groups of actions are installed as separate packages. That allows administrators to restrict the set of actions that the given system is able to execute. Spacewalk XML-RPC protocol includes method to exchange capabilities to notify the other party about available and available features. Once the action is scheduled on managing server, it waits for the rhn_check tool on the managed client to pick up the action. The rhn_check tool can be launched by RHNSD, OSAD daemon, or manually.

36 4. Spacewalk

4.8.2.2 RNSD Daemon The RHNSD stands for Red Hat Network Server daemon. The RHNSD is a mini- malistic daemon which only launches the rhn_check utility in defined period. Each launch time is adjusted by random number of seconds to minimize a risk of server overload. Default time period for RHNSD is 4 hours thus any RHN Action can be expected to complete on the managed clients in 4 hours after being schedule.

4.8.2.3 OSAD Daemon OSAD stands for Open Source Architecture Daemon, it is able to receive a notification from the Spacewalk managing server in an instant. The OSAD daemon uses XMPP instant messaging protocol to connect to Spacewalk jabberd service as illustrated on Figure 4.2. Spacewalk server connects to the jabberd service as well. That enables client-server communication in real time. Spacewalk challenges managed client to pick an action whenever there is a new action in queue for a given client. On OSAD enabled clients, RHN Action can be expected to complete immediately.

37 Chapter 5 Spacewalk and OpenSCAP Integration

This chapter describes security audit in light of the technologies used in this work, that are the Spacewalk systems managing system and the OpenSCAP scanner tool. The first section is devoted to the analysis of requirements, the second to thedesign of the solution.

5.1 Requirements Analysis

This section refers to all the requirements that should be reflected in the design of the Spacewalk and OpenSCAP integration. The main requirement for the Spacewalk– OpenSCAP integration is to accommodate remote configuration and vulnerability scanning of computer system infrastructure and thus ease the work of administrators who already have installed Spacewalk and who are interested in using SCAP scanner, either because they find it useful, or they are required to use it as aresult of legislation or internal regulation. The term Spacewalk administrator in this chapter refers to the person who has access to the Spacewalk web interface or the interface of the derivative product— either Red Hat Network Satellite or SUSE Manager.

5.1.1 Summary of the Functional Requirements Major concerns of the target group of administrators can be expressed as a following list of functional requirements. Other concerns cannot be easily expressed as functional requirements and therefore these are more thoroughly discussed in the second part of this section.

• To distribute SCAP content (security policy) to the computers which are the targets of evaluation.

• To perform assessment and evaluation of the systems.

• To archive scan results and allow for search and export.

• To perform assessment periodically in automated manner.

38 5. Spacewalk and OpenSCAP Integration

• Security policies can evolve over time and there is a need to have means to verify that the scan is based on certain version of the policy.

• Important prerequisite of security audit is to verify authenticity and integrity of input data. Otherwise the scan could proceed with a modified checklist and report success (false negative).

More specific requirements can only be anticipated. That is because the target group is hard to be determined and reached and even then this group cannot share every idea as it might be subject of the confidentiality agreement with their em- ployer. Based on private communications, the requirement for periodical assessment is the most critical for Spacewalk users.

5.1.2 Constraints Arising from Technologies Used In addition to the functional requirements from users, it is necessary to take into account any limitations associated with the technologies used. The limitations arise from the current status of the OpenSCAP project and from the nature of the life cycle of the Spacewalk project

5.1.2.1 Status of the OpenSCAP Project The latest version of SCAP, the SCAP 1.2, is almost backward compatible with earlier versions of SCAP, however there are few minor and subtle differences. SCAP 1.2 brings new file formats, new object elements, and it defines some of the earlier requirements more precisely. The most visible change in SCAP 1.2 is introduction of DataStream file format. The security policy in the form of DataStream is theonly XML file, otherwise policy consists of multiple files. Although SCAP 1.2 andDataS- treams are currently not common, it can be assumed that these will be adopted over time. That is why the integration with Spacewalk should enable processing of both SCAP versions—the version 1.1, in which majority of today’s content is written, and version 1.2. In early 2012 when this work started, SCAP content version 1.2 was rare even in the National Vulnerability Database. The oldest version, the SCAP 1.0 and especially XCCDF 1.0, can be omitted from consideration as it was not sufficiently widespread and there were no security guidances for the Linux environment, as there were no SCAP 1.0 tools. In early 2012, OpenSCAP conformed to a part of SCAP 1.1 standard and the full support of the SCAP 1.2 was only planned. It was unclear how to implement DataStreams support in the OpenSCAP library and how to design command-line interface of oscap scanner for handling DataStreams. The same problem arose regarding the implementation of CPE applicability. These uncertainties are crucial for the integration as the unstable interface of the oscap tool may have an adverse effect on the maintainability of the work. The open source community has negligible influence on SCAP development, and a next version of SCAP standard might bring new objects or policy formats breaking

39 5. Spacewalk and OpenSCAP Integration current implementations. Overall, there are limits on how tight the integration of OpenSCAP into another project may be. These limits however might be lowered if an intermediary data format is found and that format is flexible enough to overcome modifications in SCAP data model or OpenSCAP interface.

5.1.2.2 Spacewalk Life Cycle Over the years of Spacewalk development, a lot of new features have been added to the client and server side of the architecture. New features get introduced with each new Spacewalk release. However, not all users of Spacewalk update to the latest Spacewalk version at the moment when it is available. There are Spacewalk server installations which remain untouched for several years because their administrators employ the rule to not fix something which is not broken. Hence, any modification of the client code base needs to be compatible with older Spacewalk releases. The very same rule applies for Spacewalk server code which needs to support all previously released Spacewalk clients. Once bits are released, Spacewalk development community needs to support all released bits for extensive amount of time. That has implications on the development practices. New interface can be added to the server only when it is assured that older client code remains in service. And the other way round, new functionality cannot be added to the client part unless it is merely optional or all the servers are forced to upgrade. As an example for the latter case consider SHA-256 support in RPM packages [72]. SHA-1 signatures were used up until Fedora 10 and Fedora 11 adopted SHA-256. This change on the client part of the Spacewalk infrastructure had significant impact on the server part as the Spacewalk stores RPM packages, manipulates them, and serves them to the client systems. The data model of Spacewalk and signature handling code was rewritten [73] and support for SHA-256 signatures were released as Spacewalk 0.8 [74]. All administrators interested in support of Fedora 11 or higher had to upgrade their Spacewalk server to version 0.8. Nevertheless, Fedora 10 and older version were still supported. This example is the only exception to unwritten rule of Spacewalk that no change in a component may require the upgrade of whole. Spacewalk community can be hardly expected to willingly upgrade their infrastructures whenever the SCAP or OpenSCAP development make incompatible changes. The integration work must reflect this and design must be flexible enough to minimize risk of incompatibilities.

5.1.3 Infrastructure Deployments: Pull versus Push Approaches There are two well-known approaches managing network of systems. The first one is called push and it assumes that managing server reaches its managed clients whenever there is some command for them. The second one is the pull paradigm when managed clients proactively ask managing server if there is a command ready for them [75].

40 5. Spacewalk and OpenSCAP Integration

Naturally, each of the two paradigms has its advantages and disadvantages. The push model may provide more control over managed targets, as it can be synchronous and errors can be corrected immediately. On the other hand, synchronous push may suffer from limited scalability or unavailability of target systems. Un- availability of the system may be either caused by system outages or by network architecture and firewall settings. In addition, the infrastructures based solely on the push approach must include a special process for new clients to notify server about their availability. The pull approach, if implemented correctly, improves scalability of the infrastructure. The above mentioned scenario of newly booted client system can be fully automated with the pull approach. On the other hand, the pull approach limits the control which the managing system has over the infrastructure, as its commands are not executed in the real time. The current trend of system management in cloud computing is to combine pull and push approaches. Spacewalk system is historically based on the pull model, Spacewalk clients periodically poll with the server. Yet Spacewalk also includes option for XMPP protocol. With XMPP protocol, Spacewalk server is able to notify its managed clients and to ask them for pull immediately. This method is similar in many respects to the push approach as it combines advantages of both approaches. Nevertheless, the XMPP protocol is only optional in Spacewalk deployments and the Spacewalk community is looking for ways how to improve the situation [76].

5.1.3.1 Pull versus Push for the Purpose of Auditing

At first glance, one might come to the conclusion that push approach wouldbe natural choice for security audit. The security audit is synchronous, it is often driven by an auditor and it needs to be completed by certain time. On the other hand, there can be found auditing use-cases for which the pull approach seems to be more suitable. Consider periodic security audits and infrastructure of mixed downtimes. For example, desktop systems in corporations tend to have irregular outages.

5.1.4 Content Delivery

A compliance audit of remote targets requires certain information to be transferred to the targets. Typically, such information is a security policy document and a command to evaluate this policy. However, there are cases when this is not necessary. As an example consider jOval tool which does not transfer a policy to the remote system, jOval transfers shell commands instead. These shell commands are based on the evaluated policy and the output of these commands is used to generate scan results on the managing system. Such procedure is not currently possible with the OpenSCAP tool, even though there has been a proof of concept announced [50]. This leads to the conclusion that if the OpenSCAP is used, security policy files needs to be deployed to the clients.

41 5. Spacewalk and OpenSCAP Integration

5.1.4.1 Forms of Security Policy Content The security policy can take one of the four forms as described in Section 2.4.8, while the OpenSCAP at the time when this work started had supported only the first two form—single OVAL file and group of multiple files driven byXCCDF. As discussed in Section 5.1.2.2, it is highly advisable for the integration to be flexible enough to not break with a new policy format. And if the integration has to support multiple data formats, it will have implications on transmission channel of the policy from Spacewalk server to client targets.

5.1.4.2 Timing of Content Delivery Another issue that is worth considering is whether the security policy should be distributed to the client systems at the time of scan or whether it should be already in place prior to the scan. In other words, are the scan and the policy deployment two unrelated events? Shall the administrator have full control over both events? Here it should be also noted that the security policy in SCAP form may reach the size of a several hundred kilobytes. Thus, if the scan was run on many systems at the same time, it could cause a significant load on Spacewalk server, especially if the process of policy serialization was time consuming operation. Moreover, the policies for compliance audit tend to not change over time, once they are accepted and adopted. It can be expected that scans will be issued many times with the very same policy.

5.1.5 Support of Older OpenSCAP Libraries The integration work shall support older versions of OpenSCAP library which do not include SCAP 1.2. Even though there are no statistics published, based on the questions asked on Spacewalk mailing lists, it can be assumed that majority of Spacewalk administrators maintain older systems in their infrastructures. By older we mean systems based on version of Fedora Linux which is no longer supported, mainly Red Hat Enterprise Linux and its clones from release 4 to release 6. The Red Hat Enterprise Linux release 4 can be excluded from consideration, since the OpenSCAP was never distributed for this release. Older versions of OpenSCAP distributed along with the Red Hat Enterprise Linux 5.8 and 6.4 support SCAP 1.1, but they do not comply with SCAP 1.2. Hence, these systems cannot comprehend DataStream and ARF file formats. The requirement to support older versions is not the must, nevertheless if the older clients were supported, it would significantly help with early adoption of the work.

5.1.6 Audit Results Processing Up to this point, discussed requirements were related to the scan run and necessary prerequisites of the run. However, the above requirements may be also applicable

42 5. Spacewalk and OpenSCAP Integration for the result handling. Handling of scan results is material concern of this work, as the results are expected to be of interest for users who schedule the scan. Users might not be interested only in viewing results of single scan run, but also in archiving all finished scan results. Archived results can turn out to be usefulas they describe the systems configuration in time. For instance, they can be used by forensic analysis after an incident. In that case, ability to search through archived results could accelerate the forensic analysis. The compliance audit is often executed on the basis of statutory or internal requirements, however that does not imply that the compliance audit cannot reveal serious misconfiguration. The misconfiguration might not be observed promptly as they happen. Especially in the complex infrastructures where administrator’s resources are limited, a software should be helpful and not allow problems to remain unnoticed. To summarize, past audit results should be stored in centralized place and allow to be searched. This centralized repository shall enable a comparison of two different results.

5.2 Design

The requirement analysis and the architecture of Spacewalk server give a rise to a need for the following design decision which have to be made:

• How to issue scan on the remote target system?

• How to distribute SCAP content to the target system?

• Which result data should be aggregated from target system?

• How the result data should be stored and presented on Spacewalk to the user?

5.2.1 RHN Action to Facilitate Compliance Audit Spacewalk has a concept of remote actions as described in Section 4.8. If this concept is utilized for OpenSCAP scans, the implementation will take advantage of the code which is already written to facilitate RHN Actions. The only disadvantage which comes with reusing RHN Actions is that it uses pull approach to reach managed clients. While that might be perceived as counter- intuitive, the Section 5.1.3.1 suggests that using the pull approach for compliance audit may not be solely disadvantageous. It is worth remarking that on OSAD enabled client, the server can challenge client to pull immediately which effectively emulates push approach. OpenSCAP compliance audit will be introduced as a new RHN Action type. The current implementation of RHN Actions delimits what needs to be done in order to introduce a new action type. On the client side, there needs to be a new

43 5. Spacewalk and OpenSCAP Integration

Figure 5.1: Sequence Diagram of an Audit facilitated by RHN Actions Concept python function plugged into the rhn_check utility. The function will execute the given action and report results. On the server side, a new action type needs to be introduced into multiple components. Each action type is basically specialization of the general action. In database, the specialization is represented by new table. On the presentation and controling layer, the specialization is represented by new class (Java Enterprise Edition) or module (Python handlers).

5.2.2 OpenSCAP library vs oscap Choice OpenSCAP shared library (libopenscap.la) and command-line tool (oscap) can assess systems characteristics. The question is which one is more suitable for the integration with Spacewalk. The Spacewalk client code is written in Python language and the libopenscap.la offers bindings for Python. The shared library offers wider range of SCAP functionality, however that range may not be needed. Writing a simple XCCDF scanner on top of the OpenSCAP library requires several hundred lines of code. That is mainly due to various data formats and settings which can be used to configure the scan. In early 2013, author of this work has introduced high level API for the OpenSCAP library which has significantly lowered this barrier for own writing scanner [77]. If the oscap tool is used for the integration instead of the library, not only the implementation would be easier, but also the interfaces would be limited, thus the chance for future breakages would be lower. The command-line interface of OpenSCAP changes less often than the shared library. It is worth noting that there is a possibility for oscap tool to be certified as SCAP-Validated scanner [78], hereupon the Spacewalk would use the certified way

44 5. Spacewalk and OpenSCAP Integration to assess the system. In the current wording of SCAP Validation Program there is not option to certify a library.

5.2.2.1 Limiting Interface Available to User

As described in Section 3.2, oscap command-line interface is complex and offers a lot of sub-commands and options. Some of the options are available only in the newest versions of oscap and thus cannot be used by Spacewalk in default. The availability of such oscap feature on the client could be aggregated to Spacewalk server by means of RHN Capabilities and then the feature could be made available to the user on the Spacewalk Web interface. However, that would still require to update (not necessarily upgrade) the Spacewalk server each time there will be new oscap feature. To limit the scope of the integration, author decided to expose command-line interface of oscap to the user. User will be able to specify command-line options of the scan on the Spacewalk web interface. That way the responsibility for the correct input is pushed on user, who is on the other hand rewarded with greater flexibility. This decision may be perceived as sub-optimal from user experience perspective, however it can be improved in next iteration of development—if that is identified as limiting factor.

5.2.3 Security Policy Distribution

As ensues from the Section 5.1.4.2, separation of policy deployment process from scanning processes would result in more flexible solution compared to the solution which deploys security policy in time of the audit. Nevertheless, the question how to distribute SCAP policy to the client system still stands. There are two major communication channels between Spacewalk and its client for data exchange. A client reaching server can use either backend XML-RPC API or HTTPS for RPM download. There are technical limits on size of messages which can be transfered through XML-RPC protocol. The protocol is usually implemented by XML DOM parser and thus it has to fit in the memory of the server and the client. The sizeof SCAP documents can reach several hundred kilobytes. That could cause issues when multiple clients would attempt to read documents at the same time. To overcome such issue, the protocol would have to chunk a document into multiple smaller messages. The Spacewalk allows distribution of separate files by the concept of Configu- ration Channels (Section 4.7). However, the use of configuration channels requires certain packages (rhncfg) on the client and settings on the server for each client. With products derived from Spacewalk, the customers are charged for each client system entitled to receive such configuration. Additionally, this concept currently does not chunk transfered documents.

45 5. Spacewalk and OpenSCAP Integration

The exchange of RPM packages on the other hand is the default way to exchange data between server and clients. The packages are highly integrated into Spacewalk and Spacewalk monitors installed package set and is able to verify integrity of packages on the client. At the same time, the packages are preferred way to install a content on Linux systems. Users who are advanced enough to write their own security policy in the form of SCAP should be also able to build and sign an RPM comprising of this policy.

5.2.4 Audit Results Processing For sake of achieving, searching, and comparison of SCAP results on the Space- walk server, it would be helpful to have audit results stored in the SQL databse of Spacewalk. The results produced by oscap scan are described in Section 3.2.1. The question is which of these results are the most suitable for aggregation by Spacewalk. On the one hand, the return value of the oscap command can be easily processed, but the usefulness of this value to the auditor is limited. On the other hand, full SCAP results in form of OVAL Results file and xccdf:TestResult element contain entire information about the assessed system, however the aggregation and processing of these is significantly more challenging. The XCCDF and OVAL standards define about a hundred of XML elements, these elements can be parsedand stored to the database, however the usefulness of results in database remains limited (when compared to the results in the form of XML files).

5.2.4.1 Intermediary Format for Results Reporting Alternatively, the results for aggregation can be carefully selected from the SCAP data model and only a résumé could be sent to the Spacewalk server. Such résumé could be abstracted from various SCAP versions and thus it could serve as the interface between server and clients. If this résumé is in the form of XML it could be composed by an XSLT transformation on the client from SCAP Documents. The Spacewalk server would only understand this intermediary (non-SCAP) XML format and the server would parse the résumé into the database tables.

5.2.4.2 Choosing XCCDF over OVAL The official guidances are dependent on the XCCDF component (the XCCDF exports its xccdf:Value to the OVAL variable model), hence the XCCDF should not be excluded from consideration, although, the full finding are available only in the OVAL results model, the OVAL does not need to be aggregated as the summary of results is available within the XCCDF. Even though the OVAL component is always used to assess the system characteristics, the results from OVAL are exported back to the XCCDF. For each evaluated , the contains at least one xccdf:rule-result element which represents output of the OVAL evaluation.

46 5. Spacewalk and OpenSCAP Integration

One could argue that the security policy may not include the XCCDF—being based solely on the OVAL (Section 2.4.8). Notwithstanding, from each OVAL policy, the XCCDF document can be easily generated by XSLT [79], [80].

5.2.4.3 XCCDF Items For Aggregation The level of has been selected as the greatest detail of aggregated results. The OVAL results will not be available in the Spacewalk. For each the following items will be aggregated:

• the content of the child element, which represents XCCDF Result (Table 2.2)

• the @id atttribute of the respective which identifies the Rule within a given policy

• the list of elements which may refer to a common identifier (within CCE, CVE, or other naming scheme). Such identifier can be used to recognize the very same requirements among different policies. This item may enable a comparison of two scans even in cases when they are based on different policies.

• the @system attribute for each element to determine the naming scheme

Additionally, for the scan as whole the following items should be aggregated:

• the @id attribute of the to identify the SCAP content which was used to scan

• the content of the , child element of the

• the @id attribute of the element to identify the security policy used

• the content of the child element of the to provide user with human readable resume of the security policy

• the @id attribute of the element

• the @start-time attribute of the element

• the @end-time attribute of the element

The above mentioned items can be presented to the server in the following form. This intermediary format can be generated from any XCCDF Result by an XSLT transformation on the client.

47 5. Spacewalk and OpenSCAP Integration

5.2.4.4 Examplary XCCDF Résumé CCE-14559-9 CCE-4268-9 CCE-3562-6 CCE-4076-6

5.3 Conceptual Data Model

This section defines conceptual model of Spacewalk and OpenSCAP integration. There are certain connections (relationships) between the existing Spacewalk data model and newly added part. Thus, relevant entity sets (or entity sorts) of existing data model are also described in the detail. Selection of newly added entity sets (kernel sorts) is based on the above analysis, relationships, and cardinality relation-

48 5. Spacewalk and OpenSCAP Integration ships are mainly based on the XCCDF standard. The data model has to be able to store XCCDF Résumé as described in Section 5.2.4.3. This section follows concepts, terminology, and procedures of HIT modeling method as described in HIT Tutorial [81].

5.3.1 Definition of Existing Kernel Sorts • An object of category (#rhnServer) is every client system registered with Spacewalk server.

• An object of category (#rhnAction) is every event scheduled by Spacewalk server. That also includes already finished events.

• An object of category (#rhnServerAction) is every event scheduled by Spacewalk server for particular (single) client system.

• An object of category (#rhnActionType) is every type of RHN Action. Examples can be found in Table 4.1.

5.3.2 Definition of New Kernel Sorts • An object of category (#rhnXccdfTestResult) is every finished XCCDF scan which has been scheduled by Spacewalk server.

• An object of category (#rhnXccdfBenchmark) is every representation of element which has been used to scan a client system.

• An object of category (#rhnXccdfProfile) is every element which has been used to scan a client system.

• An object of category (#rhnXccdfRuleResultType) is every possible result of evaluation as defined in Table 2.2.

• An object of category (#rhnXccdfIdent) is every identifier which has be assigned to a element1.

• An object of category (#rhnXccdfIdentSystem) is every semantics of identifier. This is often the @system attribute of an element as defined by Table 10 in XCCDF 1.2 standard [15].

• An object of category (#rhnActionScap) is every representation of arguments defining the run (course) of the scan.

1. Even though the kernel sorts (#rhnXccdfIdent) and (#rhnXccdfIdentSystem) correspond with the element (the child of ), they can be used to hold any text information about given rule.

49 5. Spacewalk and OpenSCAP Integration

5.3.3 Definition of New Associative Sorts • An object of category (#rhnXccdfRuleResult) is every representation of relationship among an ident, a TestResult, and a rule-result with the following semantics: Rule results (#rhnXccdfRuleResultType)-s that originate from the evaluation of elements with given indent (#rhnXccdfIdent) as a part of given scan (#rhnXccdfTestResult) / 0,M:0,M

5.3.4 Definition of Existing HIT Attributes 1. Server (#rhnServer) for which is scheduled given server action (#rhn- ServerAction) / 1,1:0,M 2. RHN Action (#rhnAction) which encompasses the given server action (#rhnServerAction) / 1,1:0,M 3. Type (#rhnActionType) of given RHN Action (#rhnAction) / 1,1:0,M

5.3.5 Definition of New HIT Attributes 4. RHN Action (#rhnAction) which is specified by given (#rhnAction- Scap) / 1,1:0,M 5. SCAP scan prescription (#rhnActionScap) which was followed when executing the given scan (#rhnXccdfTestResult) / 1,1:0,M 6. Client system #rhnServer which was assessed by given scan (#rhnXc- cdfTestResult) / 1,1:0,M 7. XCCDF Benchmark (#rhnXccdfBenchmark) which was evaluated by given scan (#rhnXccdfTestResult) / 1,1:0,M 8. XCCDF Profile (#rhnXccdfProfile) which was evaluated by given scan (#rhnXccdfTestResult) / 1,1:0,M

9. Semantics (#rhnXccdfIdentSystem) which is assigned to given XCCDF identifier (#rhnXccdfIdent) / 1,1:0,M

5.3.6 Entity Relationship Diagram The entity relationship diagram on Figure 5.2 is derived from the HIT attributes. The diagram contains also descriptive sorts which were omitted from description above as their definition trivially results from the XCCDF standard. They areXML attributes of the modeled XML elements. The descriptive sorts named identifier on the diagram are not primary keys, they refer to the @id or @idref XML attributes.

50 5. Spacewalk and OpenSCAP Integration

Figure 5.2: Entity Relationship Diagram for XCCDF TestResult within Spacewalk Data Model

51 Chapter 6 Implementation

The implementation of OpenSCAP audits affects majority of Spacewalk components. Changes are needed within the following components: on the client system (Python, XSLT), database (SQL, PL/SQL), backend server (Python, SQL), frontend server (Java EE, JSP, Hibernate, Perl, SQL) and the search server (Java, Lucene, SQL). A detailed description of all the changes is beyond the scope of this chapter, however the chapter contains rationale and justification of implementation decisions.

6.1 Client Side Changes

Changes which need to be made on the client are isolated from the current client code base. The rhn_check provides an interface for plug-ins which may add capabilities (new RPC procedures) to the client. One such capability will be the newly added action which will execute the oscap xccdf eval command, gather the ré- sumé from the results, and send it back to the server. The name of this action will be scap.xccdf_eval (compare the name with existing names presented in Table 4.1). The client code for compliance audit will be distributed as a separate package called spacewalk-oscap. The package will be optional for client system and thus the administrator may disable the auditing capability of the system by uninstalling this package.

6.1.1 Plugin Interface The plugins are python modules installed within /usr/share/rhn/actions/ file path. The file name of the plug-in corresponds with the first part of the name, latter part of the name represents function name within the module. Accordingly, the the scap.py module shall embody the xccdf_eval() function. Functions pro- vided by a plug-in are available to the rhn_check by the __rhnexport__ variable within the module as follows. __rhnexport__ = [ ’xccdf_eval’ ] The are two possible arguments of the xccdf_eval function, the file path to the XCCDF Document and possible additional argument for the oscap tool. Addition- ally, each pluggable function has compulsory cache_only argument.

52 6. Implementation

Arguments of the xccdf_eval function are the interface between the server and clients. A client receives these arguments in form into which the Spacewalk server serializes them to XML-RPC. Hence, the argument list shall not change, or at least not often. That requirement might be achieved by using a dictionary structure as a single argument, rather than a fixed length list of arguments. Should an argument need to be added to the function, it could be simply added to the dictionary. The same way as the dictionary is used on the input of the function, it can be used on the output. It will contain two items, the XCCDF results résumé and text of any errors which occur during the scan. The Section 6.3 can be consulted for understanding of the server implementation of this interface.

6.1.2 Execution of the oscap Command The scap.py plug-in of the rhn_check will execute the oscap xccdf eval as a child process, ignoring its stdout output but capturing the stderr. The stderr output together with the return value of the command should be gathered and presented to the Spacewalk user.

6.1.2.1 Preprocessing of Command-Line Arguments User is able to specify command-line arguments in the Spacewalk. However, user shall not be able to specify any arguments as their usage might put the system in risk. The user of Spacewalk could then use such arguments (either intentionally or unintentionally) to damage the client system easily. The example of a dangerous usage of argument is --report /etc/passwd which instruct the oscap to save the HTML report to the passwd file. The unexpected content of the passwd file would result in denial of service. The arguments of oscap which do not take filenames do not put the system at risk. Hence, the client system shall maintain a list of allowed arguments. The arguments given by user shall be verified by the client system. Potentially dangerous commands shall be excluded from the scan.

6.1.3 XSLT for Results Processing After the scan finishes, the XSLT transformation will be used to convert XCCDF result file to the intermediary résumé (Section 5.2.4.3). Only XSLT version 1.0 language elements can be used for the implementation because the xsltproc command does not support XSLT 2.0. Even though there are open source implementation of XSLT 2.0 written in Java, they are not commonly installed and the compliance audit shall not depend on the presence of JVM, if it can be avoided. However, the XSLT transformation needs to consider both XCCDF standard versions the 1.1 and 1.2. Even though there are not significant changes in the items processed to the résumé, there are different XML namespaces for each version.

53 6. Implementation

The are basically 4 options how to write XSLT 1.0 transformation which will be applicable to two different XML namespaces.

1. Separate XSLT transformation for different namespaces—This has the disadvantage that there must be a code which chooses correct transformation. 2. Namespace-agnostic XSLT. That can be achieved by using the following syntax in each XPath query instead of plain Element. *[local-name()="Element"] 3. Each XPath query to include both namespaces. That intensively increases length of all XPath queries. *[local-name()="Element" and (namespace-uri()=’http://checklists.nist.gov/xccdf/1.1’ or namespace-uri()=’http://checklists.nist.gov/xccdf/1.2’)] 4. Separate XSLT set of templates for each namespaces. The set of templates would differ only in the namespaces. For example, the headings of twoequiv- alent templates mathing the Benchmark element would look like the following (assuming appropriate xmlns declarations). and

Each of the listed solution magnifies the size of the XSLT by adding repeti- tive commands. Such duplication of code may lead to increased maintenance costs. Hence, the author decided to choose fifth option.

5. An XSLT designed for a single namespace which is compiled into the another XSLT in the build time. The resulting XSLT basically matches the option 4 from the original list.

The solution then becomes more complex as there will be three XSLT transformations as illustrated in Figure 6.1. The first one applies only to the XCCDF 1.1and it is never distributed. The first XSLT serves only as the input of the second XSLT (Multiplexing) transformation. This one duplicates all elements from the first XLST to form the third transformation. The third XSLT contains elements applicable to both XCCDF standard versions. Only the third XSLT executed on the client systems to transform XCCDF document to the résumé.

6.2 Database Schema Changes

Database schema changes consists mainly of creation of new tables based on the designed ERD. However, it is worth considerating, what else can be implemented

54 6. Implementation

Build Time Multiplexing XSLT

XSLT for xslt XSLT for XCCDF Run Time XCCDF 1.1 proc 1.1 and 1.2

XCCDF xslt XCCDF Document proc Résumé

Figure 6.1: XSLT Transformations Used on the Client and During the Build Time on the database layer, because the newly created database objects will be accessed from several different environments. The following components of Spacewalk will be manipulating OpenSCAP scans within the Spacewalk database: Java, Python, and Perl stacks, a search server, and a reporting utility. The database remains the only place where the common logic can be implemented using stored procedures.

6.2.1 New Tables Definition Nine new database tables were introduced to the Spacewalk database schema. Seven tables named rhnXccdf* as defined in the entity relationship diagram (Fig- ure 5.2), the rhnActionScap table, and the rhnXccdfRuleIdentMap junction table which decomposes many-to-many relationship between rhnXccdfRuleresult and rhnXccdfIdent. Each table except the junction table has numeric id column defined as primary key.

6.2.1.1 Choosing Data Type for XCCDF Identifiers The tables are used to store text identifiers from the XCCDF documents. In the database, a text can be stored in fixed-maximum-length structures (VARCHAR) or large object structures (LOB). In the XCCDF document, the length of such identifiers is theoretically unlimited, that would suggest the use LOB. On the other hand, database engines do not allow constraints to be built on top of LOB [82] and search operation is not efficient in comparison to VARCHAR (full text indexes cannot be built on top of LOB). For VARCHAR, it is necessary to find the length constant which is large enough to hold the majority of the possible identifiers and also not excessively large, since the implementation VARCHAR commonly allocates its maximum length. Identifiers

55 6. Implementation in XCCDF documents available to author do not exceed length of 25 characters. The VARCHAR(100) structure can be used to store them. If the limited-length structure is used to store possibly unlimited strings, it may happen that the input data will not fit into the structure, leading the inserting transaction to fail. The inserting code (Spacewalk backend in this case) needs to handle longer inputs, either by trimming inputs or by failing gracefully.

6.2.2 Database Constraints The primary key constraints were placed on each id column. Foreign key constraints were placed on each column referring to such id. Each foreign key is introduced with ON DELETE CASCADE clause to allow deletion of a client system. Beside primary key constraint, the following unique key indexes were introduced to prevent duplicate entries. • rhnXccdfTestresult (server_id, action_scap_id) • rhnXccdfProfile (identifier, title) • rhnXccdfBenchmark (identifier, version) • rhnXccdfRuleresultType (label) • rhnXccdfRuleIdentMap (rresult_id, ident_id) • rhnXccdfIdentsystem (system) • rhnXccdfIdent (identsystem_id, identifier) • rhnActionScap (action_id) For example, the first one ensures that for a given RHN Action (action_scap_id) and a given client system (server_id) only one scan result (rhnXccdfTestresult) is reported. The second ensures that there will not be duplicate rhnXccdfProfile entries, thus scan results for given could be easily found.

6.2.3 Indexes for Performance Porposes Two (non-unique) indexes were created for performance reasons. • rhnXccdfRuleresult (testresult_id) • rhnXccdfRuleIdentMap (ident_id) On the web user interface, there will be SQL queries benefiting from these two indexes. These queries aggregate all of given scan based on the assessed results. These count occurrences of pass, fail, error, notchecked, etc. According to explain plans for these queries, indexes significantly improved expected execution cost. On tested setup, with one thousand of scans the indexes improved cost 28 and 2 times, respectively. Without the following indexes database engine executed full table scan.

56 6. Implementation

6.2.4 Reference Tables Content There are two reference tables which are loaded with default data during the installation. The first is the rhnXccdfRuleresultType which contains seven possible XCCDF results as defined by Table 2.2. The second one is existing enumeration of RHN Action types (rhnActionType) which needs to include newly introduced scap.xccf_eval action.

6.2.5 INSERT Anomalies . When two scans of the same policy finish, it can be assumed that most of the result data (such as identifiers of Profile, Benchmark, and Rules) will be the same. The results may differ only in assessed results. The data model takes that into account. The identifiers and results are separated into different database tables. Database constraints described in Section 6.2.2 prohibit duplicate identifier entries. As an example, consider simple policy named no_hashes_outside_shadow that contains a single Rule ensuring that all user password are stored in /etc/shadow file. Such rule may have CCE identifier assignedCCE-14300-8 ( for Red Hat En- terprise Linux 5). When the first client system is evaluated with a given policy, the results are stored in four database tables and cross-linked. A new row within rhnXccdfBenchmark table refers to the policy name, a new row within rhnXccdfIdent table refers to the CCE identifier, a new row within rhnXccdfTestResult represent the scan itself, and new row in rhnXccdfRuleresult represents mapping between the scan, CCE identifier and the assessed result. The next scan of thesame policy shall create new rows only the latter two tables, reusing entries in the former two tables. As evidenced by example, the first inserting operation creates new rows while any of the subsequent operation may reuse these rows. Considering multiple client systems reporting their results in the same time, there is a need for special atomic operation which can be described as insert if not exists and return the primary key (lookup). Such operations can be implemented as stored procedures.

6.2.6 Stored Procedures There are four tables which need the capability described in the previous section. Each of the tables needs two stored procedures. First one will insert the data as autonomous transaction. Second one will lookup the value and call the first one if the look-up fails. Both procedures will return found (or created) primary key of the table, so they can be used immediately as foreign key. The following is an example of both procedures for the rhnXccdfProfile table written in Oracle PL/SQL language. CREATE OR REPLACE FUNCTION insert_xccdf_profile(identifier_in IN varchar2, title_in IN varchar2) RETURN number

57 6. Implementation

IS PRAGMA autonomous_transaction; profile_id number; BEGIN INSERT INTO rhnXccdfProfile (id, identifier, title) VALUES (rhn_xccdf_profile_id_seq.nextval, identifier_in, title_in) RETURNING id INTO profile_id; COMMIT; RETURN profile_id; END;

CREATE OR REPLACE FUNCTION lookup_xccdf_profile(identifier_in IN varchar2, title_in IN varchar2) RETURN number IS profile_id number; BEGIN SELECT id INTO profile_id FROM rhnXccdfProfile WHERE identifier = identifier_in AND title = title_in; RETURN profile_id; EXCEPTION WHEN no_data_found THEN BEGIN profile_id := insert_xccdf_profile(identifier_in, title_in); EXCEPTION WHEN dup_val_on_index THEN SELECT id INTO profile_id FROM rhnXccdfProfile WHERE identifier = identifier_in AND title = title_in; END; RETURN profile_id; END;

6.2.7 Schema Upgrades Each change of the Spacewalk database schema needs to be written twice. First is the SQL statement which will be executed during the installation of a new Spacewalk instance. Second is the statement which will be executed on existing installations to bring their schema to the state equivalent with the new installation. Not always are the both implementation the same. On the one hand, the command creating an index or a stored procedure is identical for upgrade and fresh installation. On the other hand, an alteration of existing tables during the upgrade is not needed during the fresh install which only deploys the final table.

58 6. Implementation 6.3 Backend Server Changes

The client systems establish the communication with the backend server part of the Spacewalk. Most of the infrastructure handling RHN Actions is already implemented, only the OpenSCAP specific functions needs to be written. There will be two Python modules, first one to compose instructions for the client, the second one to parse output of the client. Both modules will be named scap.py and contain the xccdf_eval function, because the action type of Open- SCAP scan is named scap.xccdf_eval.

6.3.1 Assembling Input for Clients The first module located within the server/action directory will look-up scan attributes for a given action_id from the rhnActionScap table. The result will be returned in dictionary structure with two keys, the ’path’ key will reference the path to the XCCDF document on the client system, the ’params’ key will reference optional command-line arguments of oscap xccdf eval.

6.3.2 Storing Scan Results from Client The second module located within the server/action_extra_data directory will receive the result dictionary from the client after the scan finishes. The dictionary will encompass two items, the ’errors’ representing any errors which occur during the scan, and the ’resume’ containing the XCCDF Résumé format as described in Section 5.2.4.3. The XCCDF Résumé will be encoded by Base64 encoding [83] to avoid difficulties of including XML document within the XML-RPC protocol. Once the résumé is decoded, the xml.dom.minidom Python module can be used to parse it. The information from the XML DOM model will be then inserted into the database. The SQL INSERT commands will benefit from stored-procedures (Section 6.2.6) for look-up of the existing entities. It is not possible to insert all the information by a single INSERT command. The constraints introduced to the database enforce a certain order of commands. For example, the TestResult can be inserted only once the Benchmark and Pro- file elements are inserted. Nevertheless, this triplet can be inserted withoneSQL command by using the look-up procedures as illustrated by the following query. insert into rhnXccdfTestresult(id, server_id, action_scap_id, benchmark_id, profile_id, identifier, start_time, end_time, errors) values ( sequence_nextval(’rhn_xccdf_tresult_id_seq’), :server_id, (select ras.id from rhnActionScap ras where ras.action_id = :action_id),

59 6. Implementation

lookup_xccdf_benchmark(:bench_id, :bench_version), lookup_xccdf_profile(:profile_id, :profile_title), :identifier, TO_TIMESTAMP(:start_time, ’YYYY-MM-DD HH24:MI:SS’), TO_TIMESTAMP(:end_time, ’YYYY-MM-DD HH24:MI:SS’), :errors ) Further, the rule-result elements can be stored after the TestResult, since the rhnXccdfRuleresult table contains foreign key referring to the rhnXccdfTestresult table. Finally, all the idents can be inserted in one bulk command (third and last insert). In case of errors, whole transaction shall be rolled back and the errors shall be written to the Apache error log.

6.4 Web User Interface

The web user interface will allow users to schedule scans and to view results. There will be two dialogs for scan scheduling, the first for a single machine, and the second for a set of machines. Further, there will be also multiple pages presenting the scan results:

• Detailed view on a single scan result ()

• Detailed view on a single rule result () • List of scans for a given machine

• List of all scans available to a given user

• List of scan results corresponding to a search query

• List of rule results corresponding to a search query

• Comparison of two scan results

6.4.1 Technologies Used Even though there are a few pages served by the Perl stack, the majority of Space- walk web is written in Java EE and derives benefits from open source Java EE technologies. The Apache Tomcat servers as application server executing Java Server Pages (jsp) [84]. Apache Struts is web application framework which enforces MVC (model-view- controller) architecture and binds together these three components [85]. The application developer is responsible for writing MVC components and defining their relationships in the struts-config.xml. The controller part is tightly linked with the Struts, as the framework provides interfaces for controller classes and other

60 6. Implementation artefacts (for example objects for manipulating HTTP Session and its server side context). Hibernate is open source framework for object-relational mapping (ORM) providing persistence [86]. There are two ways how to define object-relation mapping using the Hibernate framework and the Spacewalk project uses the later option exclusively. 1. Java Annotations assigned to the POJOs (plain old java object) and to the properties of such class. 2. EntityManager which allows user to defined its own SQL queries to fetch POJO objects from the database.

6.4.1.1 How is Single Web Page Served For each web page (URL) in Spacewalk web interface there is a single section within the struts-config.xml mappings. The section defines what actions to take. It usually refers to a JSP file which represents the view of the page. Further, it refers to a Java class witch represents the controller of the page and usually extends org.apache.struts.action.Action. The Struts framework calls execute method of this class. The execute method uses model to load values expected by the JSP file.

6.4.1.2 Components of the Model The model of Spacewalk Java consists mainly of the following four types of classes. • DTO which stands for Data Transfer Object is a simple POJO class which holds raw data from the database. They are often distinguished by Dto suffix in the code. DTO objects can be filled in by custom SQL queries, therefore they offer greater flexibility and efficiency when compared to the Persistent Classes. • Persistent Class is also POJO class which is used to represent entities of the real world and allow greater abstraction from the raw data when compared to DTO. For example, instead of having a foreign key as a property loaded from the database table, the persistent classes hold another persistent classes. The persistent classes can form a network-like structure which is easy to use. User creatorUser = server.getCreator(); Org organization = creatorUser.getOrg(); OrgConfig configuration = organization.getOrgConfig(); Bool stagingContent = configuration.getStagingContentEnabled(); Hibernate generates the SQL commands to fetch persistent classes automatically from the database. Therefore, a developer has lose control of the SQL queries.

61 6. Implementation

• Manager classes which are used to fetch DTO objects. The manager classes use custom SQL queries independent on the Hibernate. The queries are defined in an XML file. • Factory classes extend HibernateFactory and provide static methods to fetch persistent classes. However, factory classes use different hibernate technology when compared to custom SQL queries of the manager classes. Each factory class is supplied with (hibernate-mapping) XML file which defines properties of the given persistent class processed by the given factory class. All four types of classes are used for OpenSCAP integration. Persistent and factory classes are used to manipulate single scan results. DTO and Manager classes efficiently facilitate manipulation of raw data.

6.4.2 Audit Scheduling

Figure 6.2: User Interface for Scheduling OpenSCAP Audit

The dialog for the scan schedule is located in a newly created Audit sub-tab of the managed system (Figure 6.2). The dialog is only available to the client systems which have the auditing capability, those which have the spacewalk-oscap package installed.

62 6. Implementation

After the dialog is submitted, the controler class uses ActionManager class from the model to store form items into the rhnActionScap table. Then the audit is scheduled for the client and is executed within a next check-in (pull) of the client. Struts DynaValidatorForm is used for the validation of the form input fields. Constraints for the given form are not defined in Java code but in separate XML schema definition file. Similar dialog page is also available through the System Set Manager (SSM) concept. The SSM allows users to select multiple systems on the Spacewalk web interface and execute actions on them en masse. That dialog is moderately more complex because it also displays targeted systems. It is followed by confirmation dialog which shows which of the selected systems are capable of the OpenSCAP scan.

6.4.3 Audit Reporting When an audit finishes and results are available in the Spacewalk database, there are multiple possible views how to present the information. The basic view is a page focusing on results for a single scan. Another views are to aggregate multiple scan results on a single page.

6.4.3.1 Scan Details Page The view of the details of a single scan consists of two tables. The first table contains all the descriptive information associated with the given scan, the second table is the list of rule-result elements and the result of their evaluation. As descriptive information is considered not only the name of the xccdf:profile and xccdf:benchmark, but also the time of the scan, the scan parameters, and the user who scheduled it.

6.4.3.2 XCCDF Diff Page The XCCDF Diff page (Figure 6.3) serves for comparison of two scan results. This page contains the same information as the Scan Details Page except that instead of a single data column, the diff page contains two data columns. The rows whose columns vary are highlighted by beige to enable the user to better focus. The diff page provides three different viewing modes, user can switch themusing a control panel in the upper right corner. The Full Comparison mode is the default and it shows all the data. The Only Changed Items mode conceals all the rows which do not differ. Finally, the Only Invariant Items mode displays only the rows which are common to the two scans. Spacewalk supports web browsers with disabled JavaScript, therefore this filtering cannot be implemented on the view layer of the application, but on the model. Figure 6.4 illustrates Java classes that together form the diff pagee. The XccdfDiffSubmitAction is the controller, therefore it drives the query and it is tightly bound with the Struts framework. The execute() method uses

63 6. Implementation

Figure 6.3: The Web Page Comparison of Two XCCDF Scans (Diff)

TestResultDiffer class to compare two scans (TestResults) and forwards this comparison to the JSP, which renders them as the first table (Figure 6.3). The getResult() method forwards the output of RuleResultDiffer to the second table. The RuleResultDiffer merges two lists of XccdfRuleResultDto elements into a single list of RuleResultComparators based on the @idref attribute within the XCCDF document. The RuleResultComparator represents a row within the second table. Classes (POJOs) in the lower part of the diagram represents data from the database. The ScapFactory fetches XccdfTestResult elements using Hibernate and the ScapManager wraps custom queries to load the DTOs (XccdfRuleResultDto and XccdfIdentsDto).

64 6. Implementation

Figure 6.4: Diagram of Classes Assembling the XCCDF Diff Web Page

6.4.3.3 Results Summary Pages

There are two pages aggregating results from multiple scans and showing them briefly together. The first one focuses on all the scans completed on a single client system (Figure 6.5), the second one lists all the scans available to a given (logged-in) user. Both pages will consists of a single table, where each scan will be represented by a single row. The user interface should offer users a simple indicator that would enable them to compare scans. Since the evaluation of an XCCDF Rule may produce seven different results, it is not clear how to express the summary result ofthewhole scan. Even though XCCDF standard defines several scoring algorithms, none of them can be used. The Flat scoring model might be misleading because it disregards notchecked results which may be returned in case of scanner failure. Other scoring models cannot be used since they are not guaranteed to be present in the results. A simple indicator which expresses the percentage of compliance with the given policy may be computed as:

P ass Compliance = T otal−Selected−Informational

Figure 6.5 illustrates benefit from this non-standard compliance ratio, when compared to the sums of occurrences of the individual results (Pass, Fail, Error, Unknown, Not Applicable, Not Checked, Not Selected, Informational, Fixed).

65 6. Implementation

Figure 6.5: Summary of the Scan Results for Single System

6.4.3.4 Using XCCDF Diff for Simple Comparison The XCCDF Diff can be used to further visualize differences between finished scans on the summary pages. It should be obvious that comparing each scan to all other is of no use. Nevertheless, for each scan a comparable scan could be found. Comparable is such scan that completed earlier on the same machine and it is based on the same and elements. The following outcomes might be encountered when comparing previous scans: • No comparable scan was found. That will happen if it is the very first scan of a given profile. (That is vizualized by a grey question mark icon onthe Figure 6.5). • The comparable scan was identical (green check mark icon). • A deterioration from the comparable scan. That is when there is at least one Rule which was satisfied within the comparable scan and not satisfied within the latter scan (red X mark icon). • The comparable scan is not identical, however it has not deteriorated (yellow exclamation mark icon).

66 6. Implementation 6.5 API for Fully Automated Audits

Spacewalk exports sub-set of functionalities available on the web interface also to the programmable interface (XML-RPC API) enabling administrators to automate (script) their common tasks. The following API functions for handling auditing information has been added to the protocol. • getXccdfScanDetails() – returns details of a single given XCCDF scan. • getXccdfScanRuleResults() – returns list of rule-results elements of a single given XCCDF scan. Each element is assigned with the result of evaluation and list of elements. • listXccdfScans() – returns a list of completed XCCDF scans for a given client system. • scheduleXccdfScan() – schedule new XCCDF scan a given client system or a list of client systems. This function allows to choose earliest possible occurrence of the scan deferring the execution. Neither the search nor the scan comparison features have been exposed as API, considering their interactive character.

6.6 Full Text Search

The existing search system of Spacewalk can be employed to implement full-text search of OpenSCAP scan results. Within Spacewalk architecture (Figure 4.2), there is a stand-alone daemon called search server which is built upon the Apache Lucene infrastructure [87]. The search server maintains a connection to the Spacewalk database and indexes certain database tables as defined in its configuration. When the user submit a search query on the Spacewalk web interface, the query is forwarded from Java EE application to the search server through XML-RPC protocol. The search server interprets the query, looks-up a result in its index files and returns it through XML-RPC to the Spacewalk Java. Spacewalk Java may further process the results by either filtering it or appending (elaborating) other attributes. Spacewalk server already indexes systems, packages, errata, and documentation.

6.6.1 OpenSCAP Search Dialog The rhnXccdfIdent table will be indexed. That will allow user to search scans () or results () by the identifier or by assigned CVE or CCE. The search interface shall allow more complex queries beyond the full-text of CVE or CCE identifier. For example, the query demonstrated on Figure 6.6has the following meaning: find all evaluation results of CCE-3818-2 which have failed within a given time range on a given sub-set of client systems.

67 6. Implementation

Figure 6.6: The User Interface of the Search

6.6.2 Lucene Search Post-Processing

Nevertheless, such complex queries cannot be implemented using the Lucene framework solely. In the aforementioned exemplary case, the search server lookups the "CCE-3818-2" within indexed documents and returns a list of matches. The returned structure contains a list of primary keys to the rhnXccdfIdent table. The controller of the search web page (XccdfSearchAction class) forwards this list to an SQL query which implements the other conditions such as that the result is failed and within the given time range. That SQL query is based on the user inputs, therefore for each combination of switches on the Search Web page there needs to be a special SQL query. The appropriate query is selected dynamically by ScapManager class. According to the user selection of Show Search Results As, the query returns a list of XccdfRuleResultDto or XccdfTestResultDto objects.

68 6. Implementation

6.6.3 Indexing with Lucene and Quartz Frameworks With Lucene, a document object is the unit of search and index. To enable search of xccdf:ident elements, each row of the rhnXccdfIdent table needs to be converted to the document. That is accomplished by XccdfIdentDocumentBuilder class which serializes the primary key and the identifier string from each row. Within the rhnIndexerWork table, the search server keeps the greates ID of already indexed rhnXccdfIdent rows. The Quartz scheduling framework is then periodically activates an indexing task which builds documents from not yet indexed rows.

6.7 Spacewalk Reports

Since Spacewalk includes the results of XCCDF scans in its data model, it may be useful for users to have a way to export the data globally for their whole infrastructure for further processing. For such task, there is a command-line utility called spacewalk-report facilitating the export of certain information from Spacewalk database into CSV format. This utility is available only on Spacewalk server. It contains multiple highly optimized SQL queries to fetch full list of database objects into a file. It includes reports of users, systems, packages, or events assigned to the systems, errata advisories, and others.

6.7.1 OpenSCAP Reports The data model of OpenSCAP scans within Spacewalk can be presented by two views (reports). The first view called scap-scans includes list of scans and details which can assigned to a scan. These are the time of the scan, identifiers of Benchmark, Profile, and TestResult elements, and the identifier (primary key)of the assessed system and the scan. The second view (scap-scan-results) encompasses of the scan results (representing elements) grouped by the given scan. Each line of this report contains identifier (primary key) of the scan and the rule-result, the @idref attribute of the rule-result, the result of the evaluation, and the list of assigned elements together with their respective @system attributes.

6.8 Source Code

The code of Spacewalk and OpenSCAP integration is open source. The contribution has been accepted by Spacewalk community into the main development branch. Hence it is available for anyone to read or run as a part of the Spacewalk project. The following two commands can be used to download the Spacewalk source code and to review changes of the OpenSCAP integration in time.

69 6. Implementation git clone git://git.fedorahosted.org/git/spacewalk.git/ git log --patch --author=lukasik --since=2012-02-01 According to statistics, there have been over 10,000 lines of code added and over 1,500 lines removed. Majority of the changes were made in Java, Python, and SQL programming languages. In order to try the integrating code, one needs to install Spacewalk server and register at least one client machine with the server. The installation of Spacewalk is complex procedure that is described in detail on Spacewalk project wiki [88]. Once the Spacewalk server is installed and client system is registered [89], tutorials at author’s blog can be used execute first OpenSCAP audit through the Spacewalk interface [90]. The first part of the implementation has been included in Spacewalk 1.7 release which has been released in March 2012 [91]. The web interface has been implemented in second phase and it was released as part of Spacewalk 1.8 in October 2012 [92].

70 Chapter 7 Conclusion

Scope of this work is broad, it goes from basic concepts of compliance audit to the implementation details within Spacewalk project. The second chapter outlined current trends in compliance audit, that is mainly the adoption of SCAP standard. To describe SCAP standard author drew not only from the specification documents, but also from his experience from the OpenSCAP project where he worked on the migration from SCAP 1.1 version to 1.2. The third and fourth chapters described existing open source projects Spacewalk and OpenSCAP and their competitive projects. The work introduced the integration of Spacewalk and OpenSCAP projects and made it easier for IT administrators to automate execution of compliance audits in Linux environments. The compliance audit is accomplished in line with SCAP specification which becomes industry standard in enterprise environments. The work has introduced the interface for searching data from security audits and the tool for comparison of two XCCDF scans, the SCAP Diff. The diff tool helps tofind and visualize differences in system configuration and can be helpful when analyzing attack vector. The same set of features which was made available through Spacewalk web interface was also exposed on the Spacewalk frontend XML-RPC API. That allows administrators to fully automate their compliance audit by scripts and issue audit commands periodically from the cron. The scan result data can be exported from Spacewalk database to CSV reports either on web interface or in optimized manner on the Spacewalk command-line. The work has been adopted by open source community of Spacewalk project and it has been released in commercial products. On 2012/09/19, SUSE has released SUSE Manager 1.7 based on Spacewalk and made major marketing news about SCAP integration. On the following day, 2012/09/20, Red Hat, Inc. has released Red Hat Network Satellite 5.5.0 based on Spacewalk and published comprehensive documentation[93] about SCAP integration. During development, multiple articles have been published on author’s blog [90] and the blog received positive feedback from open source community on OpenSCAP and SCAP Security Guide mailing lists and in private communication. The work has been presented on FudCon 2012 in Paris [94] and on Developer Conference 2013 in Brno [95].

71 7. Conclusion 7.1 Further Work

Since the production releases, there was no bug in the integration code found by customers. However, users asked if the more comprehensive SCAP results could be aggregated to the Spacewalk. Author is currently working on extension which would allow Spacewalk to aggregate full SCAP results (in the form of XCCDF and OVAL) and generate OpenSCAP HTML report from the Spacewalk web interface. Author has written proposal for generic Spacewalk e-mail notification system based on the concept of RHN Actions. The system can be used to send notification to administrators whenever an action changes the state. The solution will be based on database triggers which insert new requests for notification and an asynchronous job which processes requests and sends the e-mails. The pluggable interface will allow to send different notification for different action types. Thus, it will be possible to notify administrators immediately after an audit fails. In early 2013, the author introduced XCCDF remediation processing into Open- SCAP [96] which allows online change of system settings during the audit. That concept could be allowed for Spacewalk client, nevertheless there is a concern if it does not possess a risk of an arbitrary code execution in cases of policy content forge. Further improvement can be made on the user interface part of integration. The dialog to schedule scan could be more interactive and use JavaScript to suggest previously used settings. Trend figures could be drawn from the scan results data.

72 Bibliography

[1] Charles Cresson Wood and Dave Lineman. Information Security Policies Made Easy Version 11. Information Shield, Inc., version 11 edition, 2009.

[2] Lorrie Faith Cranor and Simson Garfinkel. Security and Usability: Designing Secure Systems that People Can Use. O’Reilly Media, Inc., 2005.

[3] Solaris Trusted Extensions Reference Manual. Sun Microsystems, , 2007, [Online 2013-02-20].

[4] SELinux Frequently Asked Questions (FAQ). National Security Agency, Central Security Service, , [Online 2013-02-20].

[5] Information Security Automation Program. Frequently Asked Questions , Version 1.0 Beta, [Last Revised, 2007-05-22].

[6] Security Content Automation Protocol. Project Homepage, , [Last Updated, 2012-09-28].

[7] David Waltermire, Stephen Quinn, Karen Scarfone, and Adam Halbardier. The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2. National Institute of Standards and Technology, Gaithersburg, MD 20899-8930, United States of America, September 2011. NIST Special Publication 800-126r2.

[8] Trusted Network Connect (TNC) Work Group. SCAP Messages for IF-M. Specification Version 1.0, Revision 16, 2012.

[9] Federal Information Security Management Act (FISMA) Implementation Project. , [Online, 2013-03-17].

[10] Steve Wright. PCI DSS, A Practical Guide to Implementing and Maintaining Compliance. IT Governance Publishing, 2011.

73 7. Conclusion

[11] Security Content Automation Protocol Validated Products. National Vulnerability Database, , [Online, 2013-02-20].

[12] SCAP Security Guide. Project Homepage, , [Online, 2013-03-17].

[13] About Lunarline ScapSync.com. SCAP Search Engine, , [Online, 2013-03-17].

[14] About SecPod SCAP Repo. SCAP Search Engine, , [Online, 2013-03-17].

[15] David Waltermire, Charles Schmidt, Karen Scarfone, and Neal Ziring. Specification for the Extensible Configuration Checklist Description Format (XCCDF) Version 1.2. National Institute of Standards and Technology, Gaithersburg, MD 20899-8930, USA, September 2011. NIST Interagency Report 7275r4.

[16] Jonathan Baker, Matthew Hansbury, and Daniel Haynes. The OVAL® Language Specification. The MITRE Corporation, Bedford, MA 01730-1420, USA, January 2012. Version 5.10.1.

[17] David Waltermire, Karen Scarfone, and Maria Casipe. Specification for the Open Checklist Interactive Language (OCIL) Version 2.0. National Institute of Standards and Technology, Gaithersburg, MD 20899-8930, USA, April 2011. NIST Interagency Report 7692.

[18] John Wunder, Adam Halbardier, and David Waltermire. Specification for Asset Identification 1.1. National Institute of Standards and Technology, Gaithersburg, MD 20899-8930, USA, June 2011. NIST Interagency Report 7693.

[19] Adam Halbardier, David Waltermire, and Mark Johnson. Specification for the Asset Reporting Format 1.1. National Institute of Standards and Technology, Gaithersburg, MD 20899-8930, USA, June 2011. NIST Interagency Report 7694.

[20] David Mann. An Introduction to the Common Configuration Enumeration. The MITRE Corporation, Bedford, MA 01730-1420, USA, July 2008. CCE Version 5.

[21] David Waltermire, Paul Cichonski, and Karen Scarfone. Common Platform Enumeration: Applicability Language Specification Version 2.3. National Institute of Standards and Technology, Gaithersburg, MD 20899-8930, USA, August 2011. NIST Interagency Report 7698.

74 7. Conclusion

[22] David E. Mann and Steven M. Christey. Towards a Common Enumeration of Vulnerabilities. The MITRE Corporation, Bedford, MA 01730-1420, USA, January 1999.

[23] Peter Mell, Karen Scarfone, and Sasha Romanosky. The Common Vulnerability Scoring System (CVSS) and Its Applicability to Federal Agency Systems. National Institute of Standards and Technology, Gaithersburg, MD 20899-8930, USA, August 2007. NIST Interagency Report 7435.

[24] Karen Scarfone and Peter Mell. The Common Configuration Scoring System (CCSS): Metrics for Software Security Configuration Vulnerabilities. National Institute of Standards and Technology, Gaithersburg, MD 20899-8930, USA, December 2010. NIST Interagency Report 7502.

[25] Harold Booth and Adam Halbardier. Trust Model for Security Automation Data 1.0 (TMSAD). National Institute of Standards and Technology, Gaithersburg, MD 20899-8930, USA, September 2011. NIST Interagency Report 7802.

[26] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, and François Yergeau. Extensible markup language (XML) 1.0 (fifth edition). Technical report, W3C, November 2008.

[27] Steve H. Weingart. Using SCAP to Detect Vulnerabilities. Atsec information security corporation, 2008, , [Online 2013-04-12].

[28] Mark J. Cox. Red Hat and OVAL Compatibility. Red Hat Knowledge Base Article, , [Online, 2013-04-04].

[29] Stephen Quinn, David Waltermire, Christopher Johnson, Karen Scarfone, and John Banghart. The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.0. National Institute of Standards and Technology, Gaithersburg, MD 20899-8930, United States of America, November 2009. NIST Special Publication 800-126.

[30] David Waltermire, Stephen Quinn, and Karen Scarfone. The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.1. National Institute of Standards and Technology, Gaithersburg, MD 20899-8930, United States of America, February 2011. NIST Special Publication 800-126r1.

[31] The United States Government Configuration Baseline (USGCB). Project Homepage, , [Last Updated, 2013-02-25].

75 7. Conclusion

[32] National Checklist Program Repository. National Vulnerability Database, , [Online, 2013-03-07].

[33] Shawn Wells. Scap compliance checker 3.1 final release. Mailing List Archive, , February 2013.

[34] OpenSCAP. Project Homepage, , [Online, 2012-09-28].

[35] SCAP-Workbench. Project Homepage, , [Online, 2013-05-24].

[36] Peter Vrabec, Šimon Lukašík, and Martin Preisler. oscap–OpenSCAP Command Line Tool. Manual Page.

[37] Martin Preisler. Script Check Engine. OpenSCAP Project Homepage, , [Online, 2012-09-28].

[38] The MITRE Corporation, Bedford, MA 01730-1420, USA. Open Vulnerability Assessment Language – Element Dictionary, January 2012. Version 5.10.1.

[39] Linux Standard Base (LSB) core specification 4.1: part 1: generic specification. ISO/IEC 23360 Part 1:2010(E), Geneva, 2010.

[40] Peter Vrabec. Fedora 14 Feature Page: OpenSCAP. Fedora Project Wikipage, , [Online, 2013-04-09].

[41] Lennart Poettering and Rahul Sundaram. Fedora 15 Feature Page: systemd System and Session Manager. Fedora Project Wikipage, , [Online, 2013-04-20].

[42] Harald Hoyer and Kay Sievers. Fedora 17 Feature Page: Move all to /usr. Fedora Project Wikipage, , [Online, 2013-04-20].

[43] Shawn Wells. SSG: Domain Name Ideas. Mailing List Archive, , [Online, 2013-05-01].

[44] Martin Preisler. SCE Community Content. Project Wikipage, , [Online, 2012-10-05].

76 7. Conclusion

[45] OVAL Interpreter. MITRE Corporation, , [Online, 2013-04-09]. [46] jOVAL: SCAP Simplified. Project Homepage, , [Online, 2013-05-04]. [47] GNU Affero General Public License, version 3. Free Software Foundation, , November 2007. [48] Ed Ort and Bhakti Mehta. Java Architecture for XML Binding (JAXB). Sun Microsystems, , March 2003. [49] jOVAL: Features. Project Homepage, , [Online, 2013-05-04]. [50] Petr Lautrbach. Openscap remote scanning. Mailing List Archive, , [Online, 2013-04-15]. [51] Modulo Open Distributed SCAP Infrastructure Collector. Project Homepage, , [Online 2013-05-04]. [52] Spacewalk. Project Wikipage, , [Online, 2012-09-28]. [53] Jesus M. Rodriguez. Introducing Project Spacewalk. Announcement, , [Online, 2012-12-05]. [54] History of Red Hat Linux. Fedora Project Wikipage, , [Online, 2012-12-05]. [55] Red Hat Network. Wikipedia, , [Online, 2012-12-05]. [56] Spacewalk Users Mailing List. Mailing List Archive, , [Online, 2013-03-07]. [57] SUSE Manager. Novell Product Announcement, , [Online, 2013-02-05]. [58] Red Hat Network Architectural Overview. WWW Page, , [Online, 2012-12-27].

77 7. Conclusion

[59] Katello. Project Wikipage, , [Online, 2013-05-03]. [60] OpenStack User Stories. Project Homepage, , [Online, 2013-05-03]. [61] Spacewalk Architecture. Project Wikipage, , [Online, 2012-12-27]. [62] Spacewalk – Perl Stack. Project Wikipage, , [Online, 2012-12-27]. [63] Dave Winer. XML-RPC Specification. , January 1999. [64] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee. Hypertext Transfer Protocol – HTTP/1.1. RFC 2616 (Draft Standard), June 1999. Updated by RFCs 2817, 5785. [65] Spacewalk – Python Backend Architecture. Project Wikipage, , [Online, 2012-12-27]. [66] Spacewalk – Taskomatic. Project Wikipage, , [Online, 2012-12-27]. [67] Jan Pazdziora. Spacewalk on PostgreSQL. Presentation, , [Online, 2012-12-28]. [68] Miroslav Suchý. Spacewalk 1.4 Released. Announcement, , [Online, 2013-02-24]. [69] PL/SQL Database Feature. Oracle Documentation Guide Post, , [Online, 2013-04-26]. [70] PL/pgSQL - SQL Procedural Language. PostgreSQL Documentation, , [Online, 2013-04-26]. [71] Gurjeet Singh and col. Oracle to Postgres Migration. The PostgreSQL Conference, , May 2011.

78 7. Conclusion

[72] Miloslav Trmač. Support and use hashes stronger than SHA-1. Fedora Project Wikipage, , [Online, 2013-03-24]. [73] SHA256 Support for Spacewalk. Project Wikipage, , [Online, 2013-03-28]. [74] Michael Mráka. Spacewalk 0.8 Released. Announcement, , [Online, 2013-03-28]. [75] Jean-Philippe Martin-Flatin. Push vs. Pull in Web-Based Network Management. EPFL-ICA, 1015 Lausanne, Switzerland, , October 1998. [76] Jan Pazdziora. SSH Push Feature Proposal. Mailing List Archive, , [Online, 2013-04-15]. [77] Šimon Lukašík. OpenSCAP library gets a high level API. Mailing List Archive, , [Online 2013-01-13]. [78] Security Content Automation Protocol (SCAP) Validation Program. National Institute of Standards and Technology, , [Online 2013-04-28]. [79] Šimon Lukašík. Generating XCCDF from OVAL. Mailing List Archive, , [Online 2013-05-05]. [80] James Clark. XSL Transformations (XSLT) Version 1.0. Technical report, W3C, November 1991. [81] Marek Winkler, Michal Oškera, and Zdenko Staníček. Conceptual modelling using the HIT method. Practical tutorial. Masaryk university Faculty of Informatics, Summer 2011. [82] Oracle® Database SQL Reference, Constraint. Product Documentation, , [Online, 2013-04-26]. [83] S. Josefsson. The Base16, Base32, and Base64 Data Encodings. RFC 4648 (Proposed Standard), October 2006.

79 7. Conclusion

[84] Apache Tomcat. Project Homepage, , [Online 2013-05-07].

[85] Apache Struts. Project Homepage, , [Online 2013-05-07].

[86] Hibernate. Project Homepage, , [Online 2013-05-07].

[87] Apache Lucene. Project Homepage, , [Online 2013-05-07]. [88] Spacewalk Installation Instructions. Project Wikipage, , [Online, 2013-05-23]. [89] Registering Clients. Project Wikipage, , [Online, 2013-05-20]. [90] Šimon Lukašík. Blog about Compliance Audit. , [Online, 2013-04-20]. [91] Jan Pazdziora. Spacewalk 1.7 Released. Announcement, , [Online, 2013-05-20].

[92] Jan Pazdziora. Spacewalk 1.8 Released. Announcement, , [Online, 2013-05-20]. [93] Šimon Lukašík and Athene Elswyth Chan. Red Hat Network Satellite 5.5, User Guide, Chapter 6. OpenSCAP. Documentation, , [Online, 2012-09-25]. [94] Šimon Lukašík, Milan Zázrivec, and Martin Preisler. Security Audit with Spacewalk & OpenSCAP. Fedora Users and Developers Conference, 2012, Paris. [95] Martin Preisler and Šimon Lukašík. System Compliance Checks. Developer Conference, 2013, Masaryk University, Brno, , [Online, 2013-04-20]. [96] Šimon Lukašík. OpenSCAP Remediation. Blog about Compliance Audit, [Online 2013-03-22].

80 Appendix A Example of XCCDF Document

The following is an exemplary XCCDF document which demonstrates how can be the , , and elements bound together. This appendix should be read in conjunction with Section 2.4.4 which describes the semantics of these elements.

incomplete 0.1 Profile title is compulsory telnet-server dhcpd tftpd The telnet-server Package Shall Not Be Installed Removing the telnet-server package decreases the risk of the telnet service’s accidental (or intentional) activation. yum -y remove

81 A. Example of XCCDF Document