Network


Latest external collaboration on country level. Dive into details by clicking on the dots.

Hotspot


Dive into the research topics where Brian Wotring is active.

Publication


Featured researches published by Brian Wotring.


Archive | 2005

Chapter 4 - Planning

Brian Wotring; Bruce Potter

This chapter provides practical information for planning every step of deployment process for a host integrity monitoring system (HIMS), including the initial setup and build environments, agent deployment, establishing management console, and administration. One of the initial steps in planning a host integrity monitoring deployment is to understand the role that it will play in the security architecture. Host intrusion prevention is best applied towards the active and dynamic defense of a host from non-specific threats. When a host is deployed, it should be locked down and steps are taken to prevent it from being abused or compromised. Host integrity monitoring allows gaining visibility into the specifics of what has occurred in a host environment. Three principles that need to be considered throughout a planning process are—make everything simple, keep functionality to a minimum, and document the requirements. The chapter also presents the major issues need to be considered when establishing requirements document for the host integrity monitoring deployment.


Archive | 2005

Chapter 1 - Host Integrity

Brian Wotring; Bruce Potter

This chapter provides an introduction to the host integrity monitoring (HIM) systems. HIM system is the recurring assessment of a host s environment based on a known good state or policy. A host can be a home users PC, a corporate e-mail or Web server, a production build system, or a computer in an Internet cafe. A host can also be a router or a switch. A HIM system comprises software agents and at least one management console. The details of how these two components interact may vary, but in general, the agents gather information about the host environment, and the console performs analysis and reporting on that data. The chapter presents some key characteristics of HIM, including the scanning process, management, and common feedback vectors. Some common arguments against deploying a HIM system are also presented. As with any security system, identifying and examining any weaknesses is worthwhile, because then one can focus on finding ways to address those weaknesses.


Archive | 2005

Chapter 9 - Advanced Strategies

Brian Wotring; Bruce Potter

This chapter discusses strategies for the successful deployment of Osiris and Samhain. Both of these systems are very effective at monitoring the integrity of host environments, and each has their own strong points. The chapter uses some of those strong points to explore Set User ID (SUID) and Set Group ID (SGID) audits, and to look for rogue executables, perform checks on a deployment, and handle the cumbersome effects of prebinding and prelinking of executables. Both Osiris and Samhain lack built-in features to deviate from their normal scheduled scans. However, scans can be run manually on a few select hosts. For Osiris, it is as easy as logging into the console, pushing the hosts configuration, and telling it to scan. If one is using Samhain, conducting a random scan is as simple as logging into the remote host and running a check session. If Samhain is already running as a daemon or daemon mode is specified in configuration file, one should force Samhain to run effectively.


Archive | 2005

Chapter 2 - Understanding the Terrain

Brian Wotring; Bruce Potter

This chapter covers many facets of a typical host environment, including common UNIX, Linux, and Windows operating systems. Although these environments vary, it is helpful to understand the general landscape of a host, and that host integrity involves monitoring more than just files. Users and groups provide the backbone of access control, whether for the relatively simplistic UNIX model or with the more byzantine access control mechanisms found on Windows. Although the kernel serves to abstract and facilitate safe use of hardware, it is exposed through the ability to dynamically load code and other application program interfaces (APIs) that make it vulnerable to abuse. Libraries and frameworks are important and critical aspects to the runtime security of a host. Processes run with varied privileges and interact with other processes consuming various amounts of system resources. The network stack provides a gateway to the network, allowing incoming and outgoing data that must be controlled. Finally, areas of the host environment that are not often included in integrity monitoring, such as nonvolatile memory, are future challenges in maintaining host integrity.


Archive | 2005

Chapter 7 - Samhain

Brian Wotring; Bruce Potter

Samhain provides a very efficient way to monitor the integrity of UNIX and UNIX-like host environments. It can be installed as a stand-alone system such that each host has a self-sufficient installation that requires its own administration. In cases where there are only a few hosts, this approach is generally employed. Alternatively, for monitoring a large number of hosts, Samhain can be deployed to be centrally managed using the log server Yule and a Web-based console named Beltane. Samhain can monitor file attributes as well as user login and logout events, file system mount options, Set User ID (SUID) and Set Group ID (SGID) executables, sensitive files in user home directories, and various attributes surrounding the integrity of the kernel. Samhain can monitor these elements of a host environment and report on changes to a number of logging outlets including files, syslog, external applications, the console, and relational databases. When configured correctly, Samhain can be an effective host integrity monitoring system (HIMS). However, its configuration can be problematic due to the design of the client/server architecture it implements and the security features that are available as an administrator. Throughout the planning and deployment of Samhain, several efforts are made to administer and maintain the system, and understand how receptive it will be to common administrative changes.


Archive | 2005

Chapter 8 - Log Monitoring and Response

Brian Wotring; Bruce Potter

Reading and analyzing logs on a regular basis is the most effective way to use host integrity monitoring system (HIMS) output. Without analyzing the log data, one will not have a high-level correlation of events and will eventually be ignorant of critical events occurring on the hosts. Swatch is a very simple yet effective way to make sense of all of the log data generated by Osiris and Samhain. If Swatch is not used, one must at least make use of some kind of log-monitoring system in order to effectively maintain visibility into the most important changes occurring in the host environments. No matter how well hosts and networks are secured, one will eventually encounter the need to respond to an attack or some type of security violation. Having an established set of procedures in place for dealing with incidents before their occurrence enables to effectively handle the incident and learn from it so that the incident can be used for the bettering of host integrity. Incident response is a cycle; it is not a static set of procedures. Each incident should improve the response capabilities and harden the defenses.


Archive | 2005

Chapter 6 - Osiris

Brian Wotring; Bruce Potter

Osiris is one of the most widely deployed open source host integrity monitoring systems available today. Osiris can monitor everything from UNIX environments like AIX and Mac OS X, to Windows desktops systems and servers. Osiris can monitor files, network ports, users, groups, and various elements of the kernel and administrator services. The Osiris source uses two major software projects: OpenSSL and Berkeley database (DB).The functionality of Osiris is highly dependent on Berkeley DB; therefore, the source for a trusted and tested version of Berkeley DB is included with Osiris. One of the biggest advantages of Osiris is that it is quite simple to use. Usability and simplicity are critical goals in the design of the Osiris system. The less complicated an Osiris deployment is, the more likely one will be successful in monitoring the integrity of the environments. This chapter covers all of the steps involved in deploying a simple and effective Osiris deployment.


Archive | 2005

Chapter 5 - Host Integrity Monitoring with Open Source Tools

Brian Wotring; Bruce Potter

Osiris and Samhain are the two most popular and widely deployed open source host integrity monitoring products. Each has an agent-based deployment model providing detailed reports about changes to various aspects of a hosts environment, including files, network ports, users, groups, kernel modules, kernel state, and user login events. Although they both share the same goals, Osiris and Samhain have different feature sets; therefore, some environments are going to favor one over the other. Osiris consists of three distinct components: a command-line client, a management console, and a scan agent. A scan agent is deployed onto every host that is to be monitored. A single management console stores all of the scan data, the scan agent configurations, and logs; manages scheduling; and handles notifications—it is the brains of the system. The command-line client communicates only with the management console, and only the management console communicates with scan agents. Samhain consists of three components: a console, a server, and a scan agent (often called the client).The agents are deployed onto every host that is to be monitored. A single server acts as a central location for logs, scan configurations, and scan data. The console is a Web-based control center written in hypertext preprocessor (PHP) that presents a unique identifier (UI) that can be used to update databases or edit scan configurations. An optional component is a relational database server.


Archive | 2005

Chapter 3 - Understanding Threats

Brian Wotring; Bruce Potter

Malicious software is classified and comes in many different forms. These classifications help relay information about the nature and behavior of the software in question, including viruses, worms, Trojans, and spyware. Software can also be unintentionally malicious. Although not common, there have been cases where someone developed a virus or a worm but did not intend it to be destructive. Sometimes proof-of-concept viruses and worms are written to bring attention to vulnerability. In other cases, someone may be developing software for educational purposes and accidentally release it. Internal threats have also evolved significantly in the recent years. Employees abuse insider privilege, store clerks help themselves to cash from the register, and CIA agents sell national secrets to other governments. People with internal access to computer systems abuse their access privileges. The chapter focuses on the impact some of the more popular software worms have had on their infected hosts. For each worm, the basic information about how it gains access to the host and what it does to the environment is also provided.


Archive | 2005

Host Integrity Monitoring Using Osiris and Samhain

Brian Wotring; Bruce Potter; Marcus Ranum; Rainer Wichmann

Collaboration


Dive into the Brian Wotring's collaboration.

Researchain Logo
Decentralizing Knowledge