v2s project reportcs.uccs.edu/.../master/jrreese/doc/v2s_project_report.pdf · 2012-10-09 ·...

V2S Project Report

for

Version Verification System (V2S)

Prepared by Jeramie Reese

Wednesday, January 11, 2006

Project Report for V2S Page ii

Rev: 676

Table of Contents

1 Introduction..............................................................................................................................4 1.1 System Description...................................................................................................................... 4

2 Requirements............................................................................................................................4 2.1 High Level ................................................................................................................................... 4 2.2 Auditing Precision ....................................................................................................................... 5 2.3 Audit Analysis ............................................................................................................................. 5 2.4 Audit Safety................................................................................................................................. 5

3 System Architecture.................................................................................................................6 4 Checksum Algorithms .............................................................................................................6

4.1 Adler32 ........................................................................................................................................ 6 4.2 CRC32 ......................................................................................................................................... 7 4.3 MD5............................................................................................................................................. 7 4.4 SHA-1.......................................................................................................................................... 7 4.5 Rational For V2S Implementation............................................................................................... 8

5 Roadblocks Removed...............................................................................................................8 6 Metrics ......................................................................................................................................9

6.1 Source Code................................................................................................................................. 9 6.2 Overall Project........................................................................................................................... 10

7 Software Lifecycle Traversal ................................................................................................10 7.1 Problem Identification ............................................................................................................... 10 7.2 Requirements Capture ............................................................................................................... 11 7.3 Preliminary Design.................................................................................................................... 12 7.4 Detailed Design ......................................................................................................................... 12 7.5 Development.............................................................................................................................. 13 7.6 Integration Testing..................................................................................................................... 15 7.7 System Testing .......................................................................................................................... 15 7.8 Deployment ............................................................................................................................... 15 7.9 Maintenance .............................................................................................................................. 16

8 Zip Optimizer © .....................................................................................................................16 8.1 Introduction ............................................................................................................................... 16 8.2 Description ................................................................................................................................ 16 8.3 Adding Overhead for Performance Improvement ..................................................................... 17

9 Testing Results .......................................................................................................................17 9.1 Test 1.1: SCM Data Collection (Large Files)............................................................................ 17 9.2 Test 1.2: J2SDK System Files ................................................................................................... 18 9.3 Test 1.3: Apache HTTP Server (httpd-2.0.55-win32-src.zip) ................................................... 20 9.4 Test 1.4: UNIX SCM Audit....................................................................................................... 21 9.5 Test 1.5: Large Data Set ............................................................................................................ 23 9.6 Testing Conclusions .................................................................................................................. 23

10 Future Work...........................................................................................................................24 10.1 Application Security.................................................................................................................. 24 10.2 Remote Audits ........................................................................................................................... 24 10.3 Comparison Values ................................................................................................................... 24 10.4 Additional File Attributes.......................................................................................................... 24

11 Conclusion ..............................................................................................................................25 12 Appendix.................................................................................................................................25

12.1 V2S Project Proposal................................................................................................................. 25 12.2 V2S Project Proposal Presentation ............................................................................................ 29 12.3 V2S Software Requirements Specification ............................................................................... 29 12.4 V2S Software Design Document (High-level) .......................................................................... 34 12.5 V2S Test Plan ............................................................................................................................ 45 12.6 V2S User’s Manual ................................................................................................................... 48

Project Report for V2S Page iii

Rev: 676

12.7 V2S Final Presentation .............................................................................................................. 58 12.8 V2S Source................................................................................................................................ 58 12.9 V2S JavaDoc ............................................................................................................................. 58

13 Related Works........................................................................................................................58 14 References...............................................................................................................................59

Revision History

Name Date Reason For Changes Rev

Jeramie Reese 11/15/05 Created 1

Jeramie Reese 12/13/05 Resolved Action Items from 12/09 review 384

Jeramie Reese 01/01/06 Resolved Action Items from late December review.

467

Jeramie Reese 01/02/06 Added Zip Optimizer sections. 610

Jeramie Reese 01/07/06 Added Testing Conclusion, Project Conclusion, additional resource citations.

651

Jeramie Reese 01/08/06 Enhanced sections 4.1 and 4.2 with additional checksum calculation information; removed testing conclusion section from 8.0 and moved to section 9.0.

669

Jeramie Reese 01/11/06 Minor correction to the CRC32 description 674

Project Report for V2S

Rev: 676

1 Introduction

The Version Verification System (V2S) is a software application that allows users to verify the integrity of files residing on a file system. V2S does this by providing the ability to take a snapshot of code, such as a Software Configuration Management (SCM) controlled build, and compares the various file attributes to files located on a local file system.

1.1 System Description

Organizations that deal with very large, component based systems often have difficulty in verifying software deliverables. This is because each component has a version number associated with it. A component is a separate, installable piece of software that provides a specific piece of functionality. When all components are combined together, then a release version is represented. In large software systems, where a release version consists of hundreds of components, it is very difficult to track the deployment of each individual component. Furthermore, a customer should have the ability to check the integrity of the deployed software system. Potential threats to the integrity of the system include accidental file deletion, malicious file deletion, virus, incorrect installations, and/or hackers. “In order to detect prior intrusions, an IDS should perform data integrity checks. This requires that a secure copy of a system metric be compared with a snapshot and metric of the current system under scrutiny.” [Foo] Although the V2S application is not technical as IDS, it does provide many of the same functions. The V2S application will provide users with a utility to verify the contents of a deployed system with the file delivered to the SCM system.

2 Requirements

2.1 High Level

• The same V2S application must run on both Windows 2000 and Solaris 8.

• The V2S application must extract file attributes from a file system (W2K and SOL).

• The V2S application must have the ability to be run from the command line.

The high level requirements were documented to ensure a complete solution. Customers do not want to buy and/or run multiple programs that provide the same functionality. The intent of the V2S system was to create a product that got the job done the right way and did not reinvent the wheel per OS. Obviously, these requirements have the consumer’s interest in mind, rather than the vendor’s. Additionally, to meet the mark of getting the job done right, multiple file attributes are used to verify the integrity of the system. Lastly, most consumers are wary of changing the way that they do business, so they are less likely to take to a program that changes their routine. Providing the command line functionality allows


Rev: 676

consumers to integrate the V2S activities right into their own SCM structure. This results in a visible change to the customer, but a major contribution to quality is added.

2.2 Auditing Precision

• The V2S application must collect information and file attribute information, including file name, file size, and checksum.

• The V2S application should store all software artifact data in a single consolidated data file. • The V2S consolidated data file must contain information such as date produced, the system name

from which the information was extracted, and the version of SCM delivery. • The V2S application must provide the ability to specify the comparison criteria for file

verification.

When auditing a file, there are several factors to take into account, depending on how sure one wishes to be about the integrity of a file’s contents. Merely checking whether or not the file exists is not nearly enough. “A simple method for detecting a changed file is comparing it against a previously made copy. This has the advantage of giving system administrators the ability to tell exactly what change was made to the file. However, this method is resource and time intensive, potentially doubling the space used by the file system and necessitating further support front system administration staff.” [Kim] In software development, files may change daily; making it very difficult to know exactly which file is currently installed. Sometimes deeper checks are required and fields like “Last Modified Date” and file size may come in handy. Even deeper checks can include a calculation of the checksum of a file and monitoring the read and write flags. One’s confidence level can rise with each successful check performed by the V2S application. Additionally, the amount of time required to do an audit will rise with each file attribute that is checked. The V2S application allows a user that ability to select the audit attributes.

2.3 Audit Analysis

• The V2S application must generate reports detailing the discrepancies between the file attribute files.

• The V2S application must be able the filter the contents (i.e. include and exclude) of a file system.

In levels of importance, audit analysis is just about as important as the actual audit. One can collect all kinds of information, but if unable to process it, and pick apart the most important details, then data collection really does not buy anything. The V2S system will generate reports based on discrepancies between the SCM audit attributes and the local host system file attributes. Anything that is not a match will appear in the report windows with a red cell background.

2.4 Audit Safety

• The Audit must be able to be stopped during operation. • The V2S cannot modify, nor leave residue of any kind, on the deployed software system

Verbose audit applications require quite a bit of CPU usage to complete their tasks. When auditing systems that are live/mission critical, this becomes quite a security concern. The audit application must be able to be shutdown in the event of an emergency. Some systems are so critical that downtime can be catastrophic. The V2S application allows for easy and immediate shutdown in the event of any such emergency.


Rev: 676

3 System Architecture

The V2S application provides software architecture for auditing a file system by checking the integrity of the files found within the file structure. The application supports a variety of file attribute calculators, such as CRC32 checksum, Adler32 checksum, MD5 checksum, SHA-1 checksum, etc. V2S audits are completed in two stages. The first stage is an SCM file attribute collection. The V2S application processes a file directory, collecting all possible file attributes, and storing them in a consolidated database file. Once complete, the database file is transferred to a host system, where the V2S application will run again, collect file attribute data, and compare it against the SCM baseline. Any discrepancies will be highlighted in the V2S discrepancy reports. The infrastructure of the V2S application allows for filtering attribute sets so that the user can run an audit that has acceptable performance and reaches a desired confidence level. In addition to filtering, the V2S infrastructure also allows for the easy addition of new, user defined, file attribute calculators. Storage for all data collection is done using a JDatastore database, which allows for swift data extraction using SQL queries. The database is JDBC compliant, so the extracted data can be accessible by other pertinent applications. Additional uses for the collected data may be used for software metrics, or to keep a history of file modifications to a particular system. The discrepancy reports generated by the V2S application allow for quick analysis of audit data. Cells are painted red if a file attribute does not match the SCM audit. Being able to quickly identify discrepancies is just as important as the audit itself. For a detailed discussion of the V2S design, consult the V2S Software Design Document. (Appendix 10.4)

4 Checksum Algorithms

4.1 Adler32

The Adler32 checksum, developed by Mark Adler, is a derivation of the Fletcher checksum algorithm. The Adler32 checksum algorithm computes a 32-bit checksum by concatenating two 16-bit checksums.

Polynomial CRC Specifications

A = 1 + D1 + D2 + ... + Dn (mod 65521) B = (1 + D1) + (1 + D1 + D2) + ... + (1 + D1 + D2 + ... + Dn) (mod 65521) = n×D1 + (n-1)×D2 + (n-2)×D3 + ... + Dn + n (mod 65521)

Adler-32(D) = B × 65536 + A A: Sum of all bytes in the string B: Sum of the individual values of A from each step.


Rev: 676

4.2 CRC32

The CRC checksum is a hash function that creates its checksum against a larger set of bytes within a file. The checksum is used to detect errors after transmission or storage. A CRC is calculated prior to transmission, and verified upon delivery. The CRC algorithm treats each message string as a binary number. That large binary number is divided by another fixed binary number, and the remainder of this division becomes the checksum. Polynomial CRC Specifications x

32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1

4.3 MD5

The MD5 (Message-Digest algorithm 5) algorithm was created in 1991 to address flaws in the preceding MD4 algorithm. It has several uses in the cryptography arena, but is also very useful for verifying file integrity. In 1996, a design flaw was identified that caused the algorithm to lose popularity, mainly in the cryptography area, but still remains a useful algorithm for file integrity checking. Excepts for the Wikipedia listing on MD5 discuss the inner workings of the MD5 algorithm:

“MD5 processes a variable length message into a fixed-length output of 128 bits. The input message is broken up into chunks of 512-bit blocks; the message is padded so that its length is divisible by 512. The main MD5 algorithm operates on a 128-bit state, divided into four 32-bit words, denoted A, B, C and D. These are initialized to certain fixed constants. The main algorithm then operates on each 512-bit message block in turn, each block modifying the state. The processing of a message block consists of four similar stages, termed rounds; each round is composed of 16 similar operations based on a non-linear function F, modular addition, and left rotation.” -Wikipedia

4.4 SHA-1

The SHA-1 was published in 1995, also to replace a predecessor, SHA-0. SHA-1 was said to address a flaw in SHA-0 that reduces its cryptographic security. Both SHA variants are based on the same concepts as the MD5 hash. Vulnerabilities in the SHA-1 algorithm have been exploited, and will eventually be phased out and replaced by a stronger SHA variant. The Secure Hash Standard provides the following excerpt about the SHA-1:

“SHA-1 may be used to hash a message, M, having a length of l bits, where 0 ≤ l < 264 .

The algorithm uses 1) a message schedule of eighty 32-bit words, 2) five working variables of 32 bits each, and 3) a hash value of five 32-bit words. The final result of SHA-1 is a 160-bit message digest.” - Secure Hash Standard


Rev: 676

4.5 Rational For V2S Implementation

The Adler and CRC checksum algorithms are fairly similar, and are not very robust checksum calculators. They are good checksum calculators for identifying accidental modification, or careless attacks against the system. Neither algorithm would be able to hold up against experienced programmers that are trying to maliciously modify the system. The two were selected based on the derived requirement that the audit most be able to run and be analyzed in under a half hour. More complex checksum algorithms are entirely welcome by the V2S architecture, but were not implemented in the first phase to ensure phase 1 acceptance. I chose to implement both the Adler32 and the CRC32 because they still meet the performance requirement imposed on phase 1, while still providing an increased security mechanism against malicious modifications of system files. If one is able to modify a find in such a way that the CRC32 checksum is still the same, there is a good chance that the Adler checksum will not be. Phase 2 of the V2S application will see the implementation of the MD5 and SHA-1 checksum algorithms in order to catch malicious code modifications. “These functions are generally designed to be collision resistant, which means that finding two strings that have the same hash result should be infeasible. In addition to basic collision resistance, functions like MD5 and SHA1 also have some properties like randomness.” [Sivathanu]

5 Roadblocks Removed

• Jbuilder DataStore Installation o Jbuilder 6 was used to develop the V2S application. Upon installation, the

DataStore would fail to install, stating that the VM was in use, or needed to be reinstalled. I re-installed the Java VM, and still did not have any luck. Extensive “Google” research revealed that there was a bug in the DataStore installer, and that calling the DataStore installer (with the version of Java provided by Jbuilder) fixed the problem.

• “Invalid method signature” o Initial development started with Java 1.5. I felt that developing with the latest

version of Java may give me a flexibility/versatility advantage during V2S application development. It turns out that the 1.5 version of Java that I was using still had quite a few bugs in it, including one that complained about one of my method signatures being invalid. Extensive “Google” research revealed that others had already reported this problem, and it was going to be fixed in future releases.

• Missing Requirement o The functionality to allow users to exclude files, based on extension, was added

very late into the project. As I was looking over the previous document submissions, I noticed the requirements section, and was doing a quick requirement matrix in my head when I discovered that I had missed a requirement.

• Integer Conversions


Rev: 676

o While developing the discrepancy reports, I noticed that cells that did not match did not always appear red in the table. Several hours of debugging led me to the reason. Integer conversions of some checksums were failing because the integer value was too high.

• Rebooting PC o Much of the development of the V2S application was done on my home PC. That

was until it started to randomly reboot on me. My initial thought was that the PC was dieing and that I better get all of my files off of there. After some investigating, I found out that the audits were causing the processor to heat up too much, which would cause a reboot.

• Time Management o In the early stages of development, I never really secured milestones or deliveries.

Some due dates were able to sneak-up on me, and put me in quite a bind to deliver.

• Documentation, Documentation, Documentation o One of the most frustrating tasks of this project was completing all the associated

documentation. I am very impulsive when it comes to code development, so I wanted to just write in. Although frustrating at the time, the documentation was a huge contributing factor to my successful completion. I was able to identify major roadblocks early on and avoided them when possible.

• Multiple Customers o My project idea came from a real-world problem that I face on the job. I had

conflicting requirements for each the project and the product that my work wanted. About half way into development, my work asked to have the product placed under their CM control, and thus started the dual development of the V2S application- the work version and the project version.

6 Metrics

6.1 Source Code

The following metrics illustrate the source lines of code (SLOC) of the V2S Application. As with all SLOC counts, the actual counts are not always reminiscent of the amount of work that went into that particular component, or class.

Figure 1- Overall source code statistics for the V2S application


Rev: 676

Figure 2 - Diagram showing the SLOC breakdown, per file, for the V2S application. (Microguru Corporation)

6.2 Overall Project

Task Hours

Research 52

Total Development 126

Testing 36

Documentation 59

Total 273

Figure 3 - Estimated hours per V2S project area. (Microguru Corporation)

7 Software Lifecycle Traversal

7.1 Problem Identification

I am currently a lead member of an integration team that is trying to deploy a very large software system. The software system has incorporated the Defense Information Infrastructure Common Operating Environment (DII COE) developed by Defense Information Systems Agency (DISA).


Rev: 676

The DII COE framework breaks software down into individual installable components, called segments. The DII COE guidelines for software packaging detail the following:

• The kinds of segments;

• The segment directory structure, which depends on the segment kind;

• Segment descriptor files, which convey the kind and other attributes of each segment, including information on the segment's dependence on other segments.

Each DII COE segment must be installed (and de-installed) using the DISA provided COE Installer. Every segment is installed as an individual unit with its own dependencies and requirements. The software system that we are developing/deploying consists of just fewer than 200 segments, per functional system. A functional system may be a Windows 2000 (W2K) system or Solaris 8 (SOL) server. There are 8+ different types of W2K systems that we build and 12+ different types of SOL servers that we also build. Each type of system requires a different set of segments to be installed. The building of all these systems represents one operational build that we deploy out to the field. An end configuration represents approximately 70 W2K systems and 30 SOL systems. To add an additional element of difficulty, a system can be built in any one of three sites. Each site installation has its own unique build list of segments that make up a build. Given approximately 200 segments to choose from, 20+ configurations to manage, and three eligible site deployments, one can see that the problem is indeed glaring. This is not the type of problem that was born over night. This version and verification management problem is something that evolves over time, thus becoming more and more daunting. By the time the problem is no longer manageable, the project is already well into the contract with limited monetary resources to attempt a remedy. There is certainly not enough money to afford products, such as TripWire, that charge nearly $6,000 per client, and even more for the accompanying management server. As usual, the customer demanded a cheap and very effective way of fixing the problem.

7.2 Requirements Capture

As the version and verification problem evolved, several attempts were made to remedy the issue. I demoed several of the past solutions and wrote down the pros and cons of each. From this list, I was able to construct a vague set of requirements. Some of these requirements included items such as:

• A single product to audit all systems; platform independent

• Make audit analysis easy to interpret

• Comparison data should come directly from SCM

• Reduce complexity; point, click, audit.


Rev: 676

Given this generic set of requirements, I began to ask various groups for input. Everyone had a different take on the product. Some of the feedback I received went as follows:

• Build, Package, Install (BPI) – Something that is fast and easy to use

• Integration – Quick verification and troubleshooting tool

• System Administrators – Something that can be run daily and will notify them of issues

• Configuration Management – Something that will give them a 100% confidence level that we delivered everything that we are supposed to deliver

I was able to gather the remaining requirements based off of this feedback. Many of the requirements remained generic, because any attempt at making them more specific ended up in losing full buy-in from all the stakeholders. Instead, I left the base set of requirements generic with the intention of creating several derived requirements. I felt this was fitting since I too was a stakeholder in the success of the V2S project.

7.3 Preliminary Design

Preliminary design yielded was born out of use cases delivered by everyone. The delivery of use cases was not formally documented, but given in verbal form. Stakeholders were asked how they envisioned using the audit application, and what they expected it to output. Some audit application expectations were subject to a reality-check, but overall, the application had to function as follows:

• Capture various file attributes from an SCM build

• Compare results against files found on local system

• Produce reports detailing the discrepancies between the two

7.4 Detailed Design

The initial detailed design was script based. It would generate a txt file of all SCM file attribute data. That file was taken out to the field, parsed, and processed against the contents on the local system. The following text-based reports were generated:

• Files found, but not expected – Extra files

• Files expected, but not found – Missing files

• Files found, but expected – Differences in files The detailed design phase exposed several constraints of which initially I was unaware. I initially felt that I had complete stakeholder buy-in, and they were just waiting for the solution. At the detailed design review, the stakeholders were much more vocal and forthcoming with information. Some of the issues that arose from the review are as follows:

• Could not alter the baseline, or introduce any new products. o This meant that no changes were allowed to the baseline version of java and the

already slimmed down version of Perl.


Rev: 676

• The audit system could leave no residue on the deployed system. o Force to view logs dynamically and prevented from generating log files.

• Text based log output was not acceptable. o Configuration management has to present the version and verification results to

the customer, and text based logs were not sufficient for that.

• Would take too long to do analysis on all systems. o Having multiple log files that had to be analyzed was unacceptable, and time-

consuming.

The design review was enlightening, and I started to pursue a more user-friendly solution. I pursued a GUI interface that allowed users to see what was going on. I sought out a new and convenient way to analyze the audit results by highlighting the discrepancies. I eliminated the enormous text file database, and replaced it with a JDatastore database, making it both JDBC compliant and easily queried with SQL commands. The second detailed design review went much smoother, with only minor suggestions to the GUI display. The final approved design is listed in the Appendix.

7.5 Development

Given to short development duration, the waterfall method of development was selected. I also made use of some prototyping, to ensure that all stakeholders were well informed of how the V2S application was coming along. Demos were given, nearly weekly, and I took in feedback from those sessions. Most feedback was limited to the GUI interface, and unanswered questions about process. These questions referred to who was going to run this audit, when was the audit going to be run, who is responsible for support, and who is responsible for maintaining it. After the first successful audit demonstration on a W2K client, my employer asked to have the V2S application put under their own SCM control. Although I liked the acceptance of the problem, it did pose another. I work on my project at night, and now the application was under SCM control at work. Much of the work had to be on a dual development basis. I would work on it during the work-day then come home and try to move my changes over, and then remember the changes I made at home to ensure they made it into the work version. It was very complicated and really slowed down the development process.

7.5.1 Technical Tradeoffs/Issues

Checksum Effectiveness - The choice to use the weaker checksum algorithms was customer driven. The customer desired a solution that could quickly identify a mistake made by the installation team, such as installing the wrong version of the segment. When presented with the arguments for using stronger checksum algorithms, they declined the request for more robust checksum algorithms. They felt that they were more concerned with accidental modification, rather than malicious. Although not initially accepting this as input, they did say that they may want it implemented in later phases.


Rev: 676

JDatastore - The decision to use a JDatastore came out of the need to pursue a well-rounded and flexible solution. I had no idea how to implement a data store, but I knew if I could develop it, then I could easily and quickly pull data from it. I have seen past products that took nearly as much time to do the analysis, as it did to complete the actual audit. Also, V2S is collecting a lot of information that may be useful to others, so creating a JDatastore, which is JDBC compliant, seemed like the logical choice.

Color Cell Renderer - Analysis of audit data is crucial, and is often the determining factor

in whether or not the customer thinks the product is useful. If one is unable to clearly show the differences in the files, then the customer will be unhappy. The V2S application uses a custom color cell renderer, which highlights the attributes that did not match up against the SCM data.

Platform Independence - Writing a platform independent solution took a little extra time in

researching and identifying generic solutions that would work with both UNIX and Windows. Some of the issues were the use of the backslash versus the forward slash. Windows uses the backslash, but both Windows and UNIX will work with the forward slash. Other pitfalls came when I was trying to use environment variables to set the default directory. The environment variable I was using only existed in Windows. To get around this, Java’s System.getProperty() provides some very useful values that are platform specific.

Splitting the V2S App. - When work required me to put the V2S application under their

SCM control, I had to make a call on whether or not to keep two versions of the V2S application in development. I had to eventually separate the two, since the work version required an SMR per modification, and I lacked the time to go through the entire SCM process each time I wanted to work on a section. The V2S application was developed primarily on my home PC, and I would bring home additions that I made at work, and would integrate them in.

Programming Language - I chose Java, partly as an exploration of deeper Java concepts, but

also because of project constraints. The Commercial Off The Self (COTS) products installed on systems that are going to be audited are baselines, and cannot change. Examples of such products are Perl and Java. Perl has been stripped down to the bare essentials to run, and Java is still running at 1.3.1, so either way, I was going to run into a COTS execution problem. I went with Java because I wanted to build a solid architecture for the V2S application. I wanted something that was easy to understand, and had the


Rev: 676

flexibility to be expanded. As a personal opinion, I feel that Java source code is also easier to understand, and maintainability was an important focus on this project.

Modification Sources - One interesting aspect was trying to figure out exactly what the V2S application was going to protect against. Although the most publicized code modifiers are hackers, the most often offenders are inside personnel. “In general, if user actions invalidate the implicit assumptions that the applications dealing with the data make, integrity violations can occur.” [Sivathanu] After nearly a month into the project, I realized that I was generating a tool to protect a Software Development organization against itself.

7.6 Integration Testing

Most of the integration testing I did on my own, testing file structures on my home PC, and on virtual hosts. Audit directories were generated using a Perl script that would generate directory structures automatically. To test the individual functionality, I would manually change the directory structure to force discrepancies to appear. When I felt confident that the V2S application was ready to run in the development environment, I chose a single development machine, and ran the SCM audit and local host audit on the same development system. Once testing all local testing passed, I collected actual SCM file attributes from a build. I would generally select one prior to the build that I was on. I did this to force file attributes to be different; thus yielding discrepancies that I could verify since I knew the expected results.

7.7 System Testing

System testing came incrementally. After I proved that I could audit folder structures on my own PC, then I started auditing development boxes. I would collect data from the box in the morning, and then after developers had left for the day, I would run a comparison to see what files changed. As a sanity check, I would show the developers the results and verify that the discrepancies were legitimate. The first field test came in early December when one of our lab W2K clients was not functioning correctly. I ran an SCM collection on a working system, and then compared the results to the file structure of the malfunctioning box. The V2S application revealed two issues. One issues was that a segment was missing altogether, and that another segment had the wrong version installed. This was the first major test of the V2S application, and it worked great.

7.8 Deployment

The V2S application is still in development. Phase 1 of the application will be delivered towards the end of December, and requirements for Phase 2 are still being elicited.


Rev: 676

7.9 Maintenance

Maintenance for the V2S application is being addressed in many ways. JavaDoc is being delivered as part of the V2S delivery. This will aid the maintenance effort by providing a roadmap of the V2S code. The actual architecture is going to be part of the V2S training that users will receive. This provides the users with some background knowledge about the inner workings of the V2S application. Also, source code is going to be handed over to the users, per each deployment.

8 Zip Optimizer ©

8.1 Introduction

The Zip Optimizer addition was added to the V2S application to enhance audit performance. A common misconception about enhancing this sort of application tends to focus on the discovery of files within a file system. The V2S application utilizes a recursive call to discover all files under a particular directory. It is true that several algorithms do exist that are able to locate a particular file much faster than the recursive call, but the V2S application is not looking for anything in particular. It is actually looking for everything; therefore, improved search algorithms would not affect the performance of the V2S application. The bottleneck for the V2S application lies within the file attribute calculations that it performs. Since every file is touched for processing, the V2S application is file I/O bound, meaning that enhancing the discovery rate would have virtually no effect on the performance results. To address to file I/O bottleneck, I have implemented the Zip Optimizer.

8.2 Description

The Zip Optimizer aims at limiting the amount of file I/O by looking for audit shortcuts, meaning that it is looking for ways to skip individual file calculations. By bundling the file into an archive file, running a checksum against the archive file, multiple files can be verified with one calculation.

8.2.1 Revised SCM Audits

The V2S application will still recursively traverse a directory structure, but when it reaches a folder structure that is at folder depth 2, it zips the contents of the folder into a zip file. The SHA-1 checksum is calculated against the zip file, and the directory name and checksum value are stored in the JDatastore containing all the other file attribute information. The number of folders at folder depth 2, the number of files to add to each archive, and the size of the completed file archive will determine the amount of overhead experienced by the Zip Optimizer addition to the SCM audits.


Rev: 676

8.2.2 Revised Local Host Audits

The V2S application will still recursively traverse a directory structure, but when it reaches a folder structure that is at folder depth 2, it also zips the contents of the folder into a zip file. The SHA-1 checksum is generated from the newly created zip file and the checksum is compared to the checksum value for the corresponding zip file in the SCM audit database. If the checksums match, then each file under that folder will not need any additional calculations performed. If the zip file checksums do not match, then the V2S application will continue traversing the directory elements.

8.3 Adding Overhead for Performance Improvement

During the SCM audits, performance is degraded by having to create the zip archive files of folders at depth 2. Another hit to performance comes by way of having to calculate the SHA-1 checksum value for all of the newly created zip archives. If this zip archive file is very large, then the SHA-1 checksum calculation will take additional time. The reason for this overhead is to increase the possibility of doing limited file attribute calculations during the Local Host audit. During the Local Host audit, all files under folders at depth level 2 will be compared using a single archive file. At best case scenario, all files match and we can skip hundreds of individual file calculations with one checksum comparison. At worst case scenario, all files are different, and the V2S application takes a performance hit for each folder and depth 2, since the zip file will be created for nothing and each individual file will still need to be processed. The possibility that each audit file would be different than the SCM data collection is remote, and a more likely scenario is that only a few files will be different, meaning that the Zip Optimizer has a good chance of preventing a majority of the file calculations from having to happen.

9 Testing Results

9.1 Test 1.1: SCM Data Collection (Large Files)

The V2S application will collect data against a Perl generated test file directory. The files are populated with ASCII characters until they reach the desired size. For Test 1.1, that file size in 1MB per file.

9.1.1 Test System

Base Operating System

• Operating System: Microsoft Windows XP w/ SP2

• CPU: Intel Pentium 4, 2.60 GHz

• Memory: 512 MB

9.1.2 Test Description

In order to test the performance of the V2S application, I created a test directory of 1400 files. Each file has a size of 1MB. Directory traversal will take the V2S application down 14 different


Rev: 676

folders. The files contents are just appended ASCII characters until the file reaches the proper size.

• SCM Collection: Test_Folder_1MB o 1400 files, 14 Folders, each file is 1MB in size. o Total size of folder: 1.30 GB

The test exercises the V2Ss ability to process larger files, while monitoring performance.

9.1.3 Results

• SCM Audit (w/o MD5, SHA-1, and Zip Optimizer Enabled) o Average completion time: 9 minutes, 32 seconds.

• SCM Audit (With MD5, SHA-1, and Zip Optimizer Enabled) o 1392.483, 1189.501, 1247.547 o Average completion time: 21 minutes, 17 seconds.

9.1.4 Analysis

The V2S application took significantly longer to process files that are consistently large. It seemed that the audit was moving along pretty nicely during the initial stages of the audit, then performance began to dwindle. I attribute this to the effects of OS paging. When the test was rerun with the MD5, SHA-1, and Zip Optimizer implemented, the processing time more than doubled. I attribute this to the large overhead of having to calculate complex checksum algorithms on large data files. Although the overhead of collecting this additional data is significant, I hope to compensate by providing faster host audits with more precise results.

9.2 Test 1.2: J2SDK System Files

The V2S application will compare the differences between the jre1.5.0_02 release and the jre1.5.0_04 release.

9.2.1 Test System



• CPU: AMD Athlon XP 2400+, 2.00 GHz

• Memory: 512 MB of RAM


In order to test the functionality of the V2S application, we are going to compare the differences between the following two J2SDK releases from SUN: Without MD5, SHA-1, and Zip Optimizer

• SCM Collection: jre1.5.0_02


Rev: 676

o 543 Files, 28 Folders o Total size of folder: 58.9 MB

• Local Host Collection: jre1.5.0_04 o 543 Files, 28 Folders o Total size of folder: 58.9 MB

With MD5, SHA-1, and Zip Optimizer

• SCM Collection: jre1.5.0_02 o 543 Files, 28 Folders o Total size of folder: 58.9 MB

• Local Host Collection: jre1.5.0_04 o 543 Files, 28 Folders o Total size of folder: 58.9 MB

Since the V2S application relies on the full path for file identification, the “jre1.5.0_04” directory was renamed to “jre1.5.0_02” for the purpose of the audit.

9.2.3 Results

Without MD5, SHA-1, and Zip Optimizer

• SCM Audit o Average completion time: 7.422 seconds.

• Local Host Audit o Average completion time: 7.578 seconds.

• File Size Discrepancies

Figure 4 - Details the differences in file between jre1.5.0_02 and jre1.5.0_04.

With MD5, SHA-1, and Zip Optimizer

• SCM Audit o 26.781, 24.312, 24.344, 24.407, 24.328 o Average completion time: 24.834 seconds.


Rev: 676

• Local Host Audit (with no discrepancies) o 12.25, 12.329, 12.234, 12.375, 12.281 o Average completion time: 12.294 seconds.

• Local Host Audit (with discrepancies) o 31.812, 27.297, 26.266, 27.782, 26.250 o Average completion time: 27.811 seconds.

9.2.4 Analysis

With the addition al MD5, SHA-1 and the Zip Optimizer, performance on an SCM audit was degraded by nearly 70%. The MD5 and SHA-1 calculations did have a big part in the degraded performance, but the test folder structure also played a role. Zip Optimizer only zips folder at a folder depth of two, and this particular file set only had two folders at that level. This meant that the zip files were very large, which takes longer to generate. After the large files were generated, then a SHA-1 checksum has to be calculated against the file, which takes even longer. The Local Host Audit using Zip Optimizer runs very quickly when no discrepancies are detected. If discrepancies are present, which every file was different in the last part of the test, then Zip Optimizer takes on additional overhead because it is trying to zip the local host’s files, and to see if it can get away with just checking the zip archive. In this particular test, every zip file check fails; individual files are finally audited.

9.3 Test 1.3: Apache HTTP Server (httpd-2.0.55-win32-src.zip)

The V2S application will compare audit two identical releases of Apache HTTP Server.

9.3.1 Test System






In order to test the performance of the V2S application, I will audit the Apache HTTP Server with and without the V2S zip file optimization. The SCM data collection will take a small hit to performance due to the Zip Optimization overhead that cannot be filtered out of the SCM data collection.

• SCM Collection: httpd-2.0.55-win32-src o 2793 Files, 225 Folders o 41.7 MB

• Local Host Collection: httpd-2.0.55-win32-src o 2793 Files, 225 Folders o 41.7 MB


Rev: 676

9.3.3 Results

Averages reported as the results of five runs

• SCM Audit (w/o MD5 and SHA-1 calculations) o 19.265, 16.531, 16.344, 16.375, 15.485 o Average completion time: 16.8 seconds

• SCM Audit (with MD5 and SHA-1 calculations) o 30.0, 29.688, 29.828, 29.688, 29.172 o Average completion time: 29.675 seconds

• Local Host Audit (w/o Zip Optimizer) o 23.609, 19.5, 20.406, 20.375, 20.375 o Average completion time: 20.853 seconds

• Local Host Audit (with Zip Optimizer) o 10.297, 10.357, 10.203, 10.187, 10.14 o Average completion time: 10.237 seconds

9.3.4 Analysis

Doing the additional MD5 and SHA-1 calculations did increase total processing time by approximately 43%. This is a significant increase, but it is only a one time overhead hit (by SCM), and will increase the user’s confidence level for file integrity. On a system with no discrepancies, the Zip Optimizer has a performance increase of approximately 51%. This means that the files could be verified off of the zip file, rather than having to process each individual file.

9.4 Test 1.4: UNIX SCM Audit

The V2S application will capture the contents of a UNIX file directory.

9.4.1 Test System




• Memory: 512 MB of RAM Microsoft Virtual PC

• Operating System: Red Hat 9




The V2S application is a platform independent application that must run on UNIX and Windows. This test will show that the V2S audit application can handle the UNIX environment by


Rev: 676

capturing file attributes during an SCM audit. The UNIX test will be run on RedHat, with the help of Microsoft’s Virtual PC.

9.4.3 Results

• SCM Audit (without MD5, SHA-1, and Zip Optimizer) o Average completion time: 29.434 seconds.

Figure 5 - The successful SCM audit capture for j2re1.4.2_10.

• SCM Audit (With MD5, SHA-1, and Zip Optimizer) o 97.651, 82.448, 82.317 o Average completion time: 1 minutes, 27 seconds.

• Local Host Audit (With MD5, SHA-1, Zip Optimizer and no discrepancies) o 48.176, 42.058, 42.583 o Average completion time: 44.272 seconds.

9.4.4 Analysis

The SCM Audit using MD5, SHA-1, and the Zip Optimizer degraded performance by approximately 66%. The file structure in this test utilizes the functionality of the Zip Optimizer, increasing performance between the SCM audit and the Local Host Audit by approximately


Rev: 676

51%. Performance is still relatively slow, compared to W2K audits, but I attribute the degraded performance to running on a Virtual Machine.

9.5 Test 1.5: Large Data Set

The V2S application will capture the contents of a “Program Files” directory structure.

9.5.1 Test System






The test will simulate an exaggerated target environment by doing an SCM audit on the “Program Files” directory on a Windows box. The files are reminiscent of files that could be found on a target system. The SCM audit was selected for the exaggerated case since it represents one of the worst-case scenarios by way of the calculation magnitude.

9.5.3 Results

• SCM Audit (With MD5, SHA-1, and Zip Optimizer) o Average completion time: 3108.297 seconds. o Took approximately five seconds per file.

9.5.4 Analysis

The time statistics from the V2S application were a little disappointing, revealing as average file processing time of five seconds. There are many factors at play here, such as the specification of the system doing the audit, the applications interactions with the OS paging file, and the magnitude of the audit. Luckily, the SCM audit one has to be run once (at build time), and represents one of the worst-case scenarios that the V2S application will have to process.

9.6 Testing Conclusions

The V2S application has acceptable performance at the varying levels of file attribute calculations. The addition of the MD5 and SHA-1 checksum algorithms did take a significant hit to V2S performance, but it provides more acceptable domain coverage since it can now identify malicious code modifications. The V2S application does take a significant hit to performance when dealing with file sizes that are very large. Initial performance seems fairly good, but the test system would bog down, due to the complexity and size of the calculations needed. The addition of the Zip Optimizer had varying results. Given generally small files, the zip optimizer has the potential of obtaining a performance increase of nearly 50%. The Zip Optimizer depends on several factors for it to be effective. Future development will see the Zip


Rev: 676

Optimizer do some overhead analysis on the file structure, and see if it’s feasible to use. The feasibility will depend on the number of file and folders, and the depth at which the zip files should be captured. Currently, the Zip Optimizer captures everything at depth 2. Without this sort of checking, the Zip Optimizer can actually add additional, unneeded overhead, and will hinder the V2S application, rather than help.

10 Future Work

The V2S application will be a work in progress for some time to come. Below is a list of future improvements that will be added to V2S.

10.1 Application Security

The V2S application is a powerful tool that can help developers, system administrators, configuration manager, quality control, etc. It could potentially become a detrimental tool. Since the audit application really abuses the CPU, there is a chance that someone could take down a set of operational systems by merely kicking off the audit program on all systems. Also, hackers may try to compromise the code to make it return false positives. The application should be password protected, and the JDatastore file should incorporate digital certificates as an authentication method. This way, the SCM consolidated file would be stamped with a seal of approval by authenticating the digital signature.

10.2 Remote Audits

When dealing with several systems at a time, it is very difficult to verify each one by hand. Future works on the V2S application need to concentrate on remote audits from a single point of origin. There are several security concerns to deal with when dealing with remote audits. For example, Intrusion Detection Systems (IDS) may mistake the audit application for an attack. Also, system administrators lock most systems down to prevent remote execution, so a lot of research will precede this next addition to the V2S application.

10.3 Comparison Values

The V2S application will reveal the files that do not match the audit criteria, but it will not tell you what the audit attribute should have been. Future development should concentrate on providing this information, and possibly tying it in with a restoration application. This way, a system could heal itself if accidental file deletion or modification took place.

10.4 Additional File Attributes

Phase 1 of the V2S application revealed six different attributes to use for auditing purposes. These six attributes do a good job of identifying accidental file deletion or modification, but they will not hold up against malicious file modifications. For this reason, the V2S application could be improved by adding stronger checksum algorithms, such as MD5, to its arsenal of audit attributes.


Rev: 676

11 Conclusion

Overall, the Version Verification System (V2S) touches on several problem domains in Computer Science. It attempts to find a balance between the following:

• High reliability file integrity checks versus performance – A file integrity verification system is able to report information, about files in a file system, with varying levels of confidence in its results. As the confidence level increase, so does the complexity of the calculations required to verify the file integrity. Allowing the user to select the file attributes to audit allows the user to obtain the desired level of confidence, knowing that attribute selections will have an effect on performance.

• Recursive search algorithm versus other more efficient search algorithms – The V2S system implements a recursive search algorithm, for file discovery, based on the fact that it leaves unneeded complexity out of the source code without taking a hit to performance. The search algorithm does not slow V2S, but is slowed by the file I/O required for file integrity calculations. Choosing the more readable search algorithm will aid in the maintenance of the application.

• Color-coded analysis report versus standard reports – Since performance was a driving factor in the audit application, then audit analysis must also be quick and easy. Users need to quickly identify what is wrong so the appropriate actions can be taken to fix the problem. The V2S system color-codes the audit analysis to quick highlight the discrepancy areas.

The V2S application provides an architecture that supports a implementation for the above issues. It is not advertised as a “Silver Bullet” for all version verification issues, but should be used as an addition tool available for individuals seeking to verify the contents of a file system. The implementation selected was based on extensive research, field studies, and customer input. The V2S implementation may not suit the needs of all individuals, but it does provide a sound, modular architecture that is welcoming to enhancements or modifications.

12 Appendix

12.1 V2S Project Proposal

(Document located at http://cs.uccs.edu/~jrreese/cs701/doc/V2S_Project_Proposal.doc)

CS701 Master’s Project Proposal Version Verification System (V2S)

By: Jeramie R Reese

Last Update: Wednesday, January 11, 2006


Rev: 676

1. Committee Members and Signatures:

Approved by Date

______________________________ _______________

Project Advisor: Dr. Tim Chamillard

______________________________ _______________ Member: Dr. Edward Chow

______________________________ _______________ Member: Dr. Jugal Kalita

12.1.1 Project Description

“Configuration Management is the process of identifying and defining the items in the system, controlling the change of these items throughout their lifecycle, recording and reporting the status of items and change requests, and verifying the completeness and correctness of items.”

-- IEEE-Std-729-1983

Configuration management (CM) is a necessary activity to any successful software project. As defined above, CM is a very broad activity that encompasses nearly every single phase of the software development lifecycle. It can be broken down into lower detail that would reveal the activities of change management, version and release management, and system building. CM is known as a quality activity that is responsible for the management of an evolving software system. The primary focus of CM activities generally lies in the software configuration management arena. Although this area does warrant intense configuration management focus, there are other parts of CM, such as change management, that are being over looked. If software development only consisted of controlling code until it is done being developed, testing, and then simply deploying the system, then controlling change management may not be such a big deal. Unfortunately, the deployment process consists of much more than just installing software. Actually, the deployment process is so involved that it has its own lifecycle. Software artifacts can be delivered, reworked, patched, upgraded, uninstalled, hand modified, etc. Each time one of these activities takes place, a level of risk is added to the integrity of the system build. How can we tell if all the code we expected to be delivered actually made it from the developer to SCM, from SCM to the installation team, and from the installation team to the integration team? The integrity of operational systems should also be verifiable. Based on the results of a simple audit, a system administrator should be able to verify the authenticity of the software baseline and see if the code has been compromised. Since we live in the time of hackers, viruses, worms,


Rev: 676

etc., this functionality should be readily available to all system administrators of mission critical systems. The Version Verification System (V2S) will take an inventory of CM controlled software and verify it against a fielded system running the same baseline.

12.1.2 Overview

12.1.2.1 Is there a need for Configuration Management Auditing?

Absolutely! In my current job, the customer often asks/requests the following:

• “You’ve done all this work to develop, install, and configure this software deployment, now prove to us that you installed the right thing.”

• “How do I know that the system isn’t corrupted (i.e. Missing or altered files)?” Both of these questions are important questions that the customer should be asking. A software organization should be able to analyze a system and know which baseline version is installed on the system. They should also be able to verify the integrity of the system by running a file audit against the SCM delivery.

12.1.2.2 Existing COTS Product(s)

One of the most popular COTS products on the market right now is Tripwire. Tripwire can address three critical auditing tasks, including change detection, system reconciliation, and audit reporting. According to reviews, it provides excellent results, but at a significant price.

Pricing starts at $6,995 per license for Tripwire Manager, and $595 per license for Tripwire for Servers, with volume discounts available.

-- http://www.isp-planet.com/services/ids/tripwire.html CM issues are generally not identified in the beginning of the project, when they would be easier to handle. Instead, CM issues thrive/compound on obstacles such as accelerated schedules, distributed deployment, diverse geographic deployment, and by supporting multiple baselines in an operational environment. When a project finds itself with these sorts of CM issues, it’s generally late in the contract, and usually there’s not a whole lot of money (nor sympathy) for handling these kinds of problems.

12.1.2.3 Issues

12.1.2.3.1 What should be audited?

One area of research will be to identify which components, on a deployed software system, that we should audit. My current research is leading me to believe that software, written to do audits, often make the same mistakes as metrics programs do. People think that it’s a good idea to gather every bit of information possible, and then decide later on how to use it. This process is rarely successful in metrics programs and will be avoided in this project. Audit artifacts will be mapped to specific (SMART) goals.


Rev: 676

12.1.2.3.2 Performance

Load balancing techniques may have to be explored in order to audit a mission critical system. Many of the systems that my company deploys are not readily available for maintenance type tasks. Also, in the event of an emergency, the audit process must be able to be halted, in order to return the system to its fully operational state.

12.1.2.3.3 Distributed Computing

Something to consider is the ability for a system administrator to launch an audit process, for a set of systems, from a central location. This is going to be investigated, but may be outside the scope of this project.

12.1.2.4 Target Audiences

The target audience may include system builders, software integration, system administrators, help-desk associates, and software security teams.

2. Goals

a. Develop a tool to capture software baselines from SCM, and compare/verify the files with a deployed system.

b. Complete to project using the software lifecycle model c. Provide a economical “way-out” for companies experiencing CM problems d. Present the tool to my company and getting it approved for use e. Platform independence (W2K vs SOL8)

12.1.3 Methodologies

• Object-oriented methodology

• JBuilder

• Perl

• Microsoft Virtual PC

• Operating System a. Microsoft Windows 2000 b. Solaris 8

12.1.4 Project Plan

12.1.4.1 Scope

a. Develop a tool to import a file attributes from an SCM system b. Compare the data-store to a system and return back audit statistics

12.1.4.2 Deliverables

Project Proposal (this document) Software Requirement Specification (SRS) Software Design Specification (SDS) Software Application – A software audit tool to verify software baselines User manual and documentation


Rev: 676

Final Project Report and Presentation Materials

12.1.4.3 Proposed Schedule

* dates displayed are due dates Project Proposal 13 Oct 2005 Requirement Specification 03 Nov 2005 Design Specification 03 Nov 2005 Test Plan 03 Nov 2005 Software Development

a. First Phase 15 Nov 2005 Collect ClearCase SCM artifact inventory.

b. Second Phase 28 Nov 2005 Analyze, using SCM artifact inventory, and report system discrepancies.

Software Testing 05 Dec 2005 Final Software application 08 Dec 2005 Final Project Report 14 Dec 2005 Presentation Materials 14 Dec 2005

12.1.5 Research

The research area for this project will consist of the following:

• Researching OS subtleties to create a platform independent tool

• Analyzing the performance tradeoffs between programming languages (i.e. performance)

• Researching the pros and cons of existing products (such as Tripwire)

• Research how companies have addressed this problem in the past.

• Research distributed computing options

12.1.6 References

[1] http://www.tripwire.com/ [2] http://www.isp-planet.com/services/ids/tripwire.html [3] http://www.activestate.com/Perl.plex?hdr=1 [4] http://java.sun.com/

12.2 V2S Project Proposal Presentation

Date: October 13th, 2005: 02:00pm

Location: UCCS: Engr 187

Attendees: Dr. Chamillard, Dr. Chow

Presentation: http://www.cs.uccs.edu/~jrreese/cs701/doc/V2S_Project_Proposal.ppt

12.3 V2S Software Requirements Specification

(Original document located at http://cs.uccs.edu/~jrreese/cs701/doc/V2S_SRS.doc)


Rev: 676

12.3.1 Introduction

12.3.1.1 Purpose

This Software Requirements Specification (SRS) provides a complete description of all the functions and constraints of the Version Verification System (V2S). The intended audience for this document will be the software engineer developing the V2S, and members of the developer’s graduate committee that have useful domain knowledge.

12.3.1.2 Product Scope

The purpose of the V2S application is to provide an automated configuration management (CM) function that will verify the contents of a deployed system, with an inventory taken from a Software Configuration Management (SCM) system. The V2S application will consist of two subsystems, one that will assemble an SCM artifact inventory, and another that will compare a deployed system against this artifact inventory and report any discrepancies.

12.3.1.3 Definitions, Acronyms, and Abbreviations

BPI – Build, Package, Installation CM – Configuration Management CPU – Central Processing Unit QA – Quality Assurance SCM – Software Configuration Management SRS – Software Requirements Specification V2S – Version Verification System

12.3.2 Overall Description

12.3.2.1 Product Perspective

The V2S application is a self-contained product that will aid CM’s ability to do system verification on deployed systems. The V2S subsystems are detailed below:


Rev: 676

Subsystem #1:

Subsystem #2:

Figure 6 – Developers, Architects, Security, etc. will check-in all software engineering artifacts into a Software Configuration Management (SCM) system. When all artifacts are ready for a release, then the V2S application will mine all the files, and collect file attribute information. After collection, the V2S application will store all

audit information into a single consolidated file (i.e. artifact inventory).

Figure 7 – After systems are deployed, the SCM generated attribute file will be placed on the deployed system. The V2S application will run on the deployed system, collecting data on the local system files, and compare it to the SCM information. Depending on the results of the local system collection, and the comparison of the SCM

database, discrepancy reports will be generated.


Rev: 676

Product Functions Subsystem #1 is designed to collect information about software artifacts that are configuration controlled. The resulting inventory database will be the baseline file configuration that each deployed system should adhere to. Data that is configuration managed, but not necessarily checked into the SCM system, will also be processed. An example of this would be a list of OS patches that should be applied to each deployed system. This information is generally found on spreadsheet format. Subsystem #2 is run against a deployed system. It will take the software artifact inventory in as an input. It analyzes the current system, and starts comparing the files on the deployed system to the artifact inventory, looking for discrepancies. All discrepancies should be reported back to the user for analysis. Comparison criteria will range from file existence, file size, checksum, and SCM specific versioning schemes.

12.3.2.2 User Classes and Characteristics

SCM User Group – SCM would be most interested in the creation of the software artifact inventory database. After bonding a delivery, SCM will run the V2S application to generate the inventory that should be fielded to all the systems. BPI User Group – Given that the BPI team installs all releases, across multiple sites while supporting several different versions, BPI will use the V2S to ensure that all the correct files, for the particular version, got onto the system. Integration User Group – Integration is responsible for all the software components working together correctly. The integration team can use the V2S as an aid to troubleshooting site issues. The V2S can detect if a system administrator accidentally, or purposely, deleted/altered files that they should not have. Configuration Management User Group – CM is responsible for handing the system to the customer after they have ensured that delivery is complete. CM can use the V2S system to increase the confidence level that the intended delivery actually made it on all the deployed systems. System Administrators User Group – The System administrators can use the V2S to troubleshoot system anomalies. Security User Group – The Security team can run the V2S to verify system integrity by ensuring that the system is running all the same files today, as it was when the system was initially delivered.

12.3.2.3 Operating Environment

The application will have to support Microsoft Windows 2000 and SUN Solaris 8. The application must be platform independent, and have both installation and de-installation procedures. The SCM data will be retrieved from Rational Clearcase.

12.3.2.4 Design and Implementation Constraints

JAVA and/or Perl on the deployed systems are a baseline version, preventing the installation of any new version of either. The typical environment will consist of 60 client boxes (W2K), and 15 servers (Solaris 8). If distributed computing is implemented, then the entire audit should be able to complete in less than an hour. Once started, the audit has to have the ability to be canceled, allowing the customer immediate access to the systems. The customer organization will be responsible for maintenance following the delivery of the V2S.


Rev: 676

12.3.2.5 User Documentation

A user manual is required upon delivery of the V2S application. A copy of the Software Design Document will also be requested.

12.3.2.6 Assumptions and Dependencies

I will be using Microsoft Virtual PC to simulate a test environment. Most testing will be done in this test-bed environment, but I will be using Red Hat 9.0 to simulate the Solaris 8 environment, but acceptance testing will be done with Solaris 8.

12.3.3 System Features

12.3.3.1 Consolidated SCM Artifact Inventory

3.1.1 Description and Priority

V2S system must be able to be directed towards the SCM system and gather artifact information about a particular release. This feature has a priority of High, since it is the foundation of the entire V2S tool. Its job is to create a consolidated list of all release artifacts so we can verify that the same thing is running on the deployed systems.

3.1.2 Stimulus/Response Sequences

After the developers have delivered all the code for a particular release, then SCM will bond the release. After the release is bonded, then SCM should launch the V2S application to create the artifact inventory.

3.1.3 Functional Requirements

REQ-1: The same V2S application must run on both Windows 2000 and Solaris 8.

REQ-2: V2S application must extract file attributes from a file system (W2K and SOL)

REQ-3: V2S application must collect information file attribute information, including file name, file size, and checksum.

REQ-4: The V2S application should store all software artifact data in a single consolidated data file.

REQ-5: The V2S application must have the ability to be run from the command line.

REQ-6: The V2S consolidated data file must contain information such as date produced, system name that information was extracted from, version of SCM delivery.

12.3.3.2 Version Verification

3.2.1 Description and Priority

The V2S Application will verify the software version of a deployed software system by comparing the contents on the system with the data collected from SCM artifacts. Based on the results, a deficiency report will be generated, indicating all SCM artifacts that are not the same.

3.2.2 Stimulus/Response Sequences

When the system has been deployed, a verification user (i.e. BPI, Integration, system administrator, etc.) will run the V2S application, which will compare the V2S artifact file with the contents on the local system.

3.2.3 Functional Requirements


Rev: 676

REQ-1: The same V2S application must run on both Windows 2000 and Solaris 8.

REQ-2: The V2S application must be able to compare the differences between consolidated file attribute files.

REQ-3: V2S application must be able to extract information from a file system (W2K and SOL)

REQ-4: V2S application must generate reports detailing the discrepancies between the file attribute files

REQ-5: V2S application must be able the filter the contents (i.e. include and exclude) of a file system

REQ-6: V2S application must provide ability to specify the comparison criteria for file verification

REQ-7: Audit must be able to be stopped during operation

12.3.4 Other Nonfunctional Requirements

12.3.4.1 Performance Requirements

The V2S application will initially be run on standalone systems, during a designated outage. Future functionality should concentrate on the ability to tune the performance, so audit can be run on operational systems.

12.3.4.2 Safety Requirements

The audit must be able to be stopped in the event of an emergency. Since the audit is very Central Processing Unit (CPU) intensive, the user must have the ability to halt the audit, and return the system back to operational status.

12.3.4.3 Security Requirements

Access to the application should be limited to users. This will be a function of the system administrator. Future development may focus on built-in application authentication, but not during this initial release.

12.3.4.4 Software Quality Attributes

The software code will be documented, per method/function using Javadoc. Comments shall include a brief description of the functionality provided.

12.3.4.5 Business Rules

SCM User Group and the Configuration Management User Group will make use of Subsystem #1 to generate the artifact inventory to be used by Subsystem #2. Other user groups can generate the same file by using Subsystem #1, but the results are not valid for official verification. All User Groups can use Subsystem #2, as long as they have an artifact inventory file. Again, the verification of the system cannot be officially verified unless the artifact inventory was generated by a CM group.

12.4 V2S Software Design Document (High-level)

(Original document located at http://cs.uccs.edu/~jrreese/cs701/doc/V2S_Software_Design_Document.doc)


Rev: 676

12.4.1 Introduction

The document is intended to convey a high level view of the V2S design. The goal is to provide a clearer understanding of the problem being solved be breaking the V2S application into appropriate components. This document is also intended to aid in the verification and validation of the completed V2S application.

12.4.1.1 System Description

Organizations that deal with very large, component based systems, often have difficulty in verifying software deliverables. This is because each component has a version number associated with it. A component is a separate, installable piece of software that provides a specific piece of functionality. When all components are combined together, then a release version is represented. In large software systems, where a release version consists of hundreds of components, it is very difficult to track the deployment of each individual component. Furthermore, a customer should have the ability to check the integrity of the deployed software system. Potential treats to the integrity of the system are accidental file deletion, malicious file deletion, virus, incorrect installations, and/or hackers. The V2S application will provide users with a utility to verify the contents of a deployed system with the file delivered to the Software Configuration Management (SCM) system.

12.4.1.2 Design Evolution

The design of the system was selected based on the data flow diagram that the manual process of version verification yields. Automating this process will allow for more in-depth file integrity checks that will increase the confidence level of Configuration Management (CM).

12.4.1.2.1 Design Issues

The V2S application is going to be run on a client / server architecture, so the solution will have to be platform independent. The files on a deployed system must be compared to the files that are delivered to SCM using Rational ClearCase. Since this is a system audit, audit reports must be generated as a proof of successful deployment.

12.4.1.2.2 Design Solution Rationale

The design was selected for its intuitive nature. Many of the users of the V2S application will not be intimately familiar with the software lifecycle activities and processes of my company, so a simple solution was desired. Many of the potential users have successfully audited deployed software systems using the manual process, so modeling the V2S application closely after the processes will cut-down dramatically on the learning curve.

12.4.1.3 Design Approach

12.4.1.3.1 Methods

To complete the V2S application, I plan on using an object-oriented design in a top-down approach. I chose object-oriented design since I was actually modeling real-world activities, and I chose the top-down approach because I achieve a higher confidence level, in the deployed software system, by increasing the granularity of my design.


Rev: 676

12.4.1.3.2 Standards

I do not plan on implementing any specific standards, but will adhere to programming best practices. I will be implementing JavaDoc to increase quality by way of understandability/code readability. I also intend to deliver all software artifacts with the deployed V2S application.

12.4.2 System Architecture

12.4.2.1 System Design

The V2S application has two functional parts. The first part is used by SCM to collect attribute information about a particular release. Pointing the system to an existing file structure that contains all the files for a particular release does this. The V2S application will recursively collect the file information and store it in a database. When complete the V2S application will produce a single consolidate file that represents all the file attributes for a given delivery. The second part of the V2S application is run on a fielded system. The SCM consolidated file is passed into the V2S application, and represents the baseline configuration, or what should be on the fielded system. The V2S application run on the local system, and creates it’s own consolidated file attribute file. After this is complete, the application will compare the results of each database entry, and provide reports on any discrepancies that it finds.

12.4.2.2 External Interfaces

The second part of the V2S application will have to process the consolidated file attribute files, so the structure will need to be well documented. Modular components will be used to make this interaction as easy as possible.

12.4.3 Component Design

12.4.3.1 File Attribute Miner

The file attribute miner is designed to recursively search the contents of a file structure and collect attribute information for all files. It will take a file structure parameter and begin its recursive search. If the element found is a directory, then that directory will be recursively searched. If the element found is a file, then the file attributes are extracted. The file name, file size, last modified date, file read flag, and file write flag are all extracted. Afterwards, the file checksums, CRC32 and Adler32, are calculated on the file. Once all the attributes are collected, then the results are stored in the single consolidated attribute file in the V2S_DATA_STORE table. The file name, including the full file path, is used as the primary key.


Rev: 676

12.4.3.1.1 Component Diagram

Figure 8 -The process flow for V2S (Phase 1) application during an SCM Local Host Audit. Phase 2 of the V2S application added the additional functionality of the MD5 and SHA-1 checksum algorithms.


Rev: 676

12.4.3.1.2 Component User Interface

Figure 9 – Screenshot depicting the V2S application processing a source directory.

12.4.3.1.3 Component Objects

Files are stored in a single consolidated Java Datastore (JDS) file. The SCM audit will store all file attributes into the JDS “V2S_DATA_STORE” table. All eligible audit attributes will be collected during an SCM audit. For a detailed description of the component objects, please reference the V2S Java Documentation (JavaDoc).

12.4.3.2 File Attribute Filter

The file attribute filter will limit the amount of the auditable fields that the V2S system will compare. This option may be exercised if there is a limited amount of time to complete the


Rev: 676

audits, or if only specific audit information is actually required. When the SCM database attributes are compared to the fielded systems database, then the union compare of the two will go much quicker.


Figure 10 - The file attribute filter is designed to give users the ability to select the audit criteria to run during a V2S local host audit. Time constraints may exist, and the user may want to eliminate of the audit criteria to hasten the total audit time. Keep in mind, decreasing the audit criteria will indeed speed up the audit process, but the confidence level in the files will decrease.


Rev: 676


The “Audit Criteria” section of the local host audit GUI is the front-end to the file attribute filter. Based on selection, the V2S system can exclude certain audit criteria if it is deemed unnecessary or if time constraints exist.

Figure 11 – V2S GUI interface that allows attribute-filtering functionality under the “Audit Criteria” section.


Selections that are left unchecked in the “Audit Criteria” section will not appear in the JDS “HOST_DATA_STORE” table. Entries will be replace with an “N/A” string or a “-1” integer value. For a detailed description of the component objects, please reference the V2S Java Documentation (JavaDoc).

12.4.3.3 Search Inclusion/Exclusion Filter

There are files on fielded computer systems that we do expect to change after deployment. For examples, log files are delivered to SCM as empty files, but these log files will begin to populate after deployment. To prevent clutter in the discrepancy reports, a filter mechanism will exist so that file, like logs files, will be ignore during the audit.


Rev: 676


Figure 12 - The filter will prevent files, of a particular extension, to be ignored from the V2S Host System audit. This feature was installed to eliminate some congestion in the discrepancy reports. For example, when SCM delivers a log file, the file is going to be empty. After the software is deployed on a system, the log file will begin to be populated. The exclusion filter allows users to eliminate these type of files from the audit, since they are going to fail the file attribute checks.


Rev: 676


Figure 13 – V2S GUI interface showing the file-filtering capability under the “Exclusion Filter” section.


When selected, the “Exclusion Filter” will allow certain files to be skipped during the audit. This functionality was intended to avoid erroneous results in the audit due to files that are expected to change, such as log files. For a detailed description of the component objects, please reference the V2S Java Documentation (JavaDoc).

12.4.3.4 Database Comparison Engine

SCM will create a consolidated attribute file using the SCM file structure. The V2S application will create another consolidated attribute file based on the file located on the deployed software system. The union of these two databases will yield the differences between the two systems.


Rev: 676


Figure 14 – Depicts the comparison between the SCM generated database table and the attribute results found on the local system audit.


No user interface (UI) is visible.


The SCM Database is represented as the “V2S_DATA_STORE” table and the Fielded System Database is represented by the “HOST_DATA_STORE table in the Java Datastore file. For a detailed description of the component objects, please reference the V2S Java Documentation (JavaDoc).

12.4.3.5 Report Generator

The report generator will display the discrepancies between the fielded system’s files and the SCM files. The report will display all known information about the file in question.


Rev: 676


Figure 15 - Depicts the reports as a product of the two database relationships.


Figure 16 – Report showing the differences between the SCM data file collection and the local system audit.


Reports are generated after each local system audit. Results are filterable by clicking the checkboxes to the left of the JTable. Attribute discrepancies will display with a red background cell color. Reports can also be printed by using the print button. For a detailed description of the component objects, please reference the V2S Java Documentation (JavaDoc).


Rev: 676

12.4.4 Additional Details

Build and tested using Java 1.4.2_10-b03.

12.5 V2S Test Plan

(Original document located at http://cs.uccs.edu/~jrreese/cs701/doc/V2S_Test_Plan.doc )

12.5.1 Introduction

The document is intended to convey a high level view of the V2S design. The goal is to provide a clearer understanding of the problem being solved by breaking the V2S application into appropriate components. This document is also intended to aid in the verification and validation of the completed V2S application.


Organizations that deal with very large component based systems often have difficulty in verifying software deliverables. This is because each component has a version number associated with it. A component is a separate, installable piece of software that provides a specific piece of functionality. When all components are combined together, then a release version is represented. In large software systems, where a release version consists of hundreds of components, it is very difficult to track the deployment of each individual component. Furthermore, a customer should have the ability to check the integrity of the deployed software system. Potential threats to the integrity of the system include accidental file deletion, malicious file deletion, virus, incorrect installations, and/or hackers. The V2S application will provide users with a utility to verify the contents of a deployed system with the file delivered to the Software Configuration Management (SCM) system.

12.5.2 Scope and Objectives

12.5.2.1 Scope of Phase I Testing

• Single consolidated database file

• JDBC compliant DB

• Directory traversal to process all files

• Dynamic analysis of file discrepancies

• File exclusion capability when auditing local systems

• Ability to audit the following file attributes: File size, last modified date, read flag, write flag, crc32 and adler32

• Platform independent audit solution


Rev: 676

12.5.2.2 Testing Process

Figure 17 - Diagram depicting the V2S Testing Process

12.5.2.3 Testing Scope

12.5.2.3.1 Integration Testing

Most of the integration testing I conducted on my own by testing file structures on my home PC and on virtual hosts. Audit directories were generated using a Perl script that would generate directory structures automatically. To test the individual functionality, I would manually change the directory structure to force discrepancies to appear. When I felt confident that the V2S application was ready to run in the development environment, I chose a single development machine and ran the SCM audit and local host audit on the same development system. Once testing all local testing passed, I collected actual SCM file attributes from a build. I would generally select one build previous to the actual build. I did this to force file attributes to be different; thus yielding discrepancies that I could verify since I knew the expected results.

12.5.2.3.2 Acceptance Testing

Demonstrating a complete V2S application audit on a development string completes acceptance testing. The test is complete upon verification of the following:

• V2S application launches without altering baseline configuration

• V2S application left no residue on the systems

• V2S application did not modify any of the system files

• Audit results are available at the end

12.5.2.4 Acceptance Testing Entrance/Exit Criterion

12.5.2.4.1 Entrance Criterion

Entrance criterion for acceptance testing is the successful completion of integration testing with all minor issues documented and no known major issues.

12.5.2.4.2 Exit Criterion


Rev: 676

The exit criterion for acceptance testing is the successful audit of a development string by a system administrator using the V2S User’s Manual.

12.5.3 Test Phases and Cycles

12.5.3.1 System Testing Cycles

Each release is subject to developers’ unit testing. This is generally done at functionality milestones. Once several functionality milestones have been verified by the unit testing, regression testing is completed to ensure the integrity of previously developed code. End-to-end system testing takes place, also in an incremental fashion. The V2S application must audit and identify known discrepancies in a test directory structure. After successful completion, the V2S application audits a random system file directory structure. The V2S application then moves onto the development environment and ensures the proper deployment procedures are in place, and then actual development string audits take place.

12.5.3.2 Software Delivery

The V2S application is deployed in phases such that once the application completes all objectives contained within the scope of the phase, the application is bonded by SCM. It is then submitted to the projects SCM library and made available for engineers during deployment.

12.5.4 System Test Schedule (Phase 1)

• Unit Testing o Start Date: September 2005 o End Date: November 24, 2005

• System Testing o Start Date: November 28, 2005 o End Date: December 1, 2005

• Acceptance Testing o Start Date: December 14, 2005 o End Date: TBD

• Official Field Run: Late December 2005/Early January 2006 Note: Although the “Official Field Run” is not scheduled until late December/early January, the

V2S application was used in later November to troubleshoot a fielded system that was acting out-of-sorts. The audit led to a quick and successful alleviation of an issue with a missing segment and another segment that had the wrong version installed.

12.5.5 Resources

12.5.5.1 Human

Human resources to complete testing can be limited to one tester. The developer is readily available if any questions happen to arise.

12.5.5.2 Hardware

Due to the nature of my work, I cannot discuss the hardware requirements of our deployed systems, but the same configuration (W2K and SOL) must be used.


Rev: 676

12.5.5.3 Software

The V2S application is a self-contained application that can be temporarily placed on the system for execution, and easily removed when it is done.

12.5.6 Error Management/Configuration Management

The V2S application was placed under my employer’s SCM control after the first successful audit demonstration on a development string. During development, builds are brought down as needed, but builds that are going to be fielded must be built by SCM. Error management is now controlled by our Software Modification Request (SMR) system. Since being placed under SCM control, no changes can be made unless I have an SMR against the specific issues. Any issues located in the V2S application must be written-up as SMRs and they will be prioritized and assigned by the software control review board.

12.5.7 Issues/Risks/Assumptions

12.5.7.1 Issues/Risks

• Since each and every file on the deployed system is going to be touched, there is a risk that the files could get modified and corrupt the baseline.

• There is a chance that the V2S application will not run correctly on the deployed systems.

• Something may be missed; audit criteria may be too weak to catch malicious code modifiers.

• Files locked by other processes cannot be audited, causing the V2S application to yield inaccurate results.

12.5.7.2 Assumptions

• System administrators are going to regulate access and coordinate site training on the V2S application.

12.5.8 Signoff

Signoff comes when a representative from each stakeholder category verifies that the V2S application can successfully audit our development strings, and they are all willing to accept the risks associated with fielding the V2S application.

12.6 V2S User’s Manual

(Original document located at http://cs.uccs.edu/~jrreese/cs701/doc/V2S_Users_Manual.doc)

12.6.1 Introduction

The Version Verification System (V2S) is a software application that allows users to verify the integrity of files residing on a file system. V2S does this by providing the ability to take a snapshot of code, such as a Software Configuration Management (SCM) controlled build, and compares the various file attributes to files located on a local file system.


Rev: 676


Organizations that deal with very large component based systems often have difficulty in verifying software deliverables. This is because each component has a version number associated with it. A component is a separate, installable piece of software that provides a specific piece of functionality. When all components are combined together, then a release version is represented. In large software systems, where a release version consists of hundreds of components, it is very difficult to track the deployment of each individual component. Furthermore, a customer should have the ability to check the integrity of the deployed software system. Potential threats to the integrity of the system include accidental file deletion, malicious file deletion, virus, incorrect installations, and/or hackers. The V2S application will provide users with a utility to verify the contents of a deployed system with the file delivered to the Software Configuration Management (SCM) system.

12.6.2 Completing An SCM Data Collection

12.6.2.1 Launching the V2S Application

Store the V2S application on the local hard drive

• D:\V2S\V2S_1.jar

Create the V2S data directories

• D:\V2S\data

• D:\V2S\zip

Launch the application

• D:

• cd \V2S

• java –jar V2S_1.jar


Rev: 676

Expected Result

Figure 18 – Screenshot of the V2S application after startup.

12.6.2.2 Configuring and Executing the Audit

Audit Configuration Source Directory: Represents the directory from which you wish to capture

file attributes Created By: Used to identify who created the V2S audit DB Password: Used to authenticate users prior to running a baseline audit

Execute the Audit The Audit will begin when the “Create” button is pressed.


Rev: 676

Audit Attributes Database Path: Represents the full path and file name of the newly created

V2S Database Source Directory: Represents the file directory from which the V2S

application is collecting data Source System: Identifies the hostname of the system from which the audit

was done Created By: Displays the value listed in the “Created By” field, but also

appends on the actual username of the individual running the V2S audit

Creation Date: Displays a timestamp of when the DB was created Audit Option

Include MD5 & SHA-1 The option to include MD5 and SHA-1 checksums are left up to the user. Although the V2S application will provide a greater confidence level in file integrity, the drawback is that it does take more time to complete since all the additional checksums need to be computed.


Rev: 676

Successful Audit

Figure 19 – Screenshot of a successful V2S audit.

12.6.3 Completing A Local Host Audit

12.6.3.1 Launching the V2S Application

Store the V2S application on the local hard drive

• D:\V2S\V2S_2.jar

Locate the V2S database

• D:\V2S\data\V2S_DB.jds

Launch the application

• D:


Rev: 676

• cd \V2S

• java –jar V2S_2.jar

Expected Result

Figure 20 – Screenshot showing the V2S application after launching the local host audit.


Rev: 676

12.6.3.2 Configuring The V2S Audit

12.6.3.2.1 Load The SCM Database

Figure 21 – Screenshot showing the V2S application prior to loading the SCM database.

• The text field under “SCM Database” must contain the path to the SCM created V2S database. Either type in the full path to the DB, or use the button to the left to browse to the proper location.

• When the text field has the appropriate path, then select the “Load” button.

• After the database has been loaded, the following DB attributes will be displayed: DB Name: Represents the name of the SCM created V2S database From Host: Displays the name of the host that the DB was created on Created By: Displays the value listed in the “Created By” field, but also

appends on the actual username of the individual running the V2S audit

Date Created: Displays a timestamp of when the DB was created # of Records: Displays the number of file entries in the database


Rev: 676

Expected Result

Figure 22 – Screenshot showing the V2S application after it has loaded the SCM database. To view the contents of the DB, select the “View DB” button.

12.6.3.2.2 Configuring Local Host Audit

Directory To Audit: Represents the directory that will be compared against the SCM created V2S database

Audit Criteria: Represents file attribute options that can by used by the V2S application for the audit

Exclusion Filter: Provides the ability to filter files out of the audit by file extensions (i.e. *.log)

Zip Optimizer ®: The Zip Optimizer is a performance enhancement for audits. It should be used on large directory structures to speed up the auditing process.

12.6.3.2.3 Running the V2S Audit

Running To run the audit, select the “Audit” button. When the “Audit Progress” bar reaches 100%, then the V2S audit is complete.


Rev: 676

Sample Result

Figure 23 – Screenshot illustrating a V2S audit that is in progress.

12.6.3.2.4 Viewing Audit Discrepancies

Viewing To view the audit discrepancies, select the “Reports” button.


Rev: 676

Expected Result

Figure 24 – Sample report showing the results of a V2S audit.

Filtering Report Data To view a subset of the results, select the desired checkboxes under “File Attributes”.

Sample Result

Figure 25 – Screenshot showing the filtering of the V2S result set.

12.6.4 Troubleshooting

(Section to be completed after the first deployment of V2S)


Rev: 676

12.7 V2S Final Presentation

Date: December 9th, 2005: 01:00pm

Location: UCCS: Engr 187

Attendees: Dr. Chamillard, Dr. Chow, and Dr. Kalita

Presentation: http://www.cs.uccs.edu/~jrreese/cs701/doc/V2S_Presentation.ppt

12.8 V2S Source

(Version Verification System (V2S) source code located at http://cs.uccs.edu/~jrreese/cs701/src/)

12.9 V2S JavaDoc

(Version Verification System (V2S) JavaDoc located at http://cs.uccs.edu/~jrreese/cs701/JavaDoc/)

13 Related Works

The concepts discussed in the paper “An Architecture for Lifecycle Management in Very Large File Systems” closely parallel the problems that our Build Package and Install (BPI) and Integration team face during deployment. The paper discusses architecture to aid in “migrating data between different tiers of multi-tiered storage systems,” whereas a system installation is nothing more than migrating data. Data comes from a single source, SCM, and must be distributed out to all fielded systems. The paper talks of a policy based system to help manage the lifecycle management (LCM) in a mass scale distributed file system. This system had to be put into place so that tedious file scanning was not needed. Overall, they were experiencing the same problem that the V2S system is addressing. They have a distributed set of data, which they need a high confidence level that it was actually distributed, but they don’t have the luxury of time, so it needs to be quick. The paper “A Cooperative Approach to Support Software Deployment Using the Software Dock” really captures the essence of how the Version Verification System (V2S) came to be. The authors note that initial installations support was common in the past, but customers are now requesting support for all the deployment activities, such as “install, adapt, reconfigure, update, activate, deactivate, remove and retire”, of which nearly none are supported. Not only are they not supported, but also architectures are still evolving. “[I]n environments of many networked heterogeneous platforms with different policies and software, the task of monitoring changes becomes quite daunting.” [Kim] Companies, such as Symantec, have products available, but rely heavily on manual configuration and dictation. Companies, such as the Department of Defense (DoD) are manually providing this type of support on contracts that have a staggering amount of system builds. Products that are available today weren’t available when most contracts started, so the licensing fees were not accounted for, making the availability of these products obsolete. Even with the approach of the Software Dock, audit programs will still need to exist. Deployment software, such as the Software Dock, are agent based which means that the agent processes have to be running. As agent process is nothing more than a piece of software, which is susceptible to going down and/or failing. When successfully run, solutions such as


Rev: 676

these work great, but in mission critical systems, one cannot just hope that everything went as planned. Some sort of audit software will always be required to check the integrity of the installation. Products, such as TripWire, do provide this auditing service, but at a hefty price. TripWire’s commercial version auditing software can be as much as $6,000 per license, where a license must exist on each client. My research has revealed that the TripWire product is very robust, but not feasible for companies looking to address this issues with very limited funds. The mere price of the software tends to indicate that the creators know that have a product that’s in high demand, solidifying the notion that auditing software deployments is a significant problem facing software development today. Another product, called the Development Verification System (DVS) provides system audits using a variety of file attributes, but doesn’t include any checksum algorithms for file integrity checking. This leaves a lot to be desired when dealing with mission critical systems. Although products, such as TripWire, started popping up in the late 80’s, the problem domain still exists. “The science to perceive, track, and understand intrusions is still at its infancy. Many different technologies and topologies are under investigation to see which model provides adequate data for intrusion detection.” [Foo] To most users, a file system contains as many unknowns, leaving a sense of helplessness to try and protect something that is not entirely known. Overall, most commercial off the shelf (COTS) products that provide file auditing capabilities come with a fairly high price tag. Although the products may be well worth the cost, programs don’t often have the budget to support such purchases by the time they realize they have a version management problem. Problem identification usually comes when a project in well into the software development phases, and budget is starting to get tight because you’re blowing schedule by not knowing what’s being deployed.

14 References

Defense Information Systems Agency. http://www.disa.mil/. December 13, 2005. Foo, S.Y., Arradondo, M., "Mobile agents for computer intrusion detection", System Theory, 2004. Proceedings of the Thirty-Sixth Southeastern Symposium on 2004, Page(s): 517 – 521. Hall, R.S., et al. “A cooperative approach to support software deployment using the Software Dock.” Software Engineering, 1999. Proceedings of the 1999 International Conference on 16-22 May 1999 Page(s):174 – 183. Kim, Gene H, Spafford. Eugene H, “The design and implementation of tripwire: a file system integrity checker”, Proceedings of the 2nd ACM Conference on Computer and communications security, p.18-29, November 1994, Fairfax, Virginia, United States Microguru Corporation, “SLOC Metrics: A tool for the measurement of Physical Source Lines of Code based on CMU/SEI-92-TR-019”, 2004.


Rev: 676

R.L. Rivest. The MD5 Message-Digest Algorithm. RFC1321, MIT Laboratory for Computer Science and RSA Data Security, Inc., April 1992. Secure Hash Standard, Federal Information Processing Standards Publication 180-2, August 1, 2002. http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf. January 1, 2006. Sivathanu, Gopalan, Wright, Charles P. and Zadok, Erez, "Workshop On Storage Security And Survivability archive", Proceedings of the 2005 ACM workshop on Storage security and survivability, 2005, Pages: 26-36. Stone, J., et al. “Performance of checksums and CRCs over real data.” Networking, IEEE/ACM Transactions on Volume 6, Issue 5, Oct. 1998 Page(s):529 – 543. Verma, Akshat, et al. “An Architecture for Lifecycle Management in Very Large File Systems.” Mass Storage Systems and Technologies, 2005. Proceedings. 22nd IEEE / 13th NASA Goddard Conference, 11-14 April 2005, Page(s):160–168. Wikipedia. http://en.wikipedia.org/wiki/MD5. January 1, 2006

v2s project reportcs.uccs.edu/.../master/jrreese/doc/v2s_project_report.pdf · 2012-10-09 ·...

Documents