Linux Advisory Watch – August 1, 2003

10
– by Benjamin D. Thomas

This week, advisories were released for mnogosearch, perl, sup, conq, gallery,

xtokkaetama, kernel, stunnel, openssh, and kdelibs. The distributors include

Conectiva, Debian, Mandrake, Red Hat, and Turbo Linux.

Last week I wrote about the importance of building a business case for security

projects. We are now in the third quarter, which means it is time to seriously

begin doing research and developing a 2004 budget. For some, a 2004 budget will

just be an extension of 2003. For most others, 2004 will mean a slight increase

in money. Companies are increasing becoming optimistic and are planning accordingly.

Is a business case for each security project enough to justify spending? Several

years ago, yes. However, in today’s volatile climate every penny spent must

be justified. The second piece of justification is a ROI analysis.

What is ROI and why is it important? Simply put, ROI is an acronym for return

on investment. It can be calculated by dividing a project’s net benefit to an

organization by the total cost. A ROI analysis is a document that is used to

show the benefits of a project in quantitative terms. It can be included as

a section in a business case, or presented separately as an independent document.

A ROI analysis may also include total cost of ownership calculations and a cost/benefit

analysis.

To create a successful ROI analysis, several types of information must be

included. In most cases, it is best to begin with an executive summary. In this,

project objectives, signification project factors, and a brief overview of the

project implementation plan should be included. Although it may be tempting

to add details, it is best to remain high-level. The executive summary is usually

the first section read, therefore should not be overwhelming. Next, a major

section of the document should be devoted to technology. In this, existing technology

should be described. What systems and processes are currently in use? What will

remain in use? What will be removed? Also, a moderately detailed description

of new technology that will be implemented as a result of the project should

be described.

The most significant piece of a ROI analysis is the business analysis. It

should include a description and listing of business drivers (that which has

a positive impact on the business). The business analysis section should include

tables that show initial project investment and recurring costs. Because the

project is security related, it is particularly important to show costs if no

investment.

The ROI analysis should conclude with a short summary that outlines the monetary

benefits of adopting the particular project. It should also include a brief

project overview. Although I’ve given you several ideas of what should be included

in an ROI analysis, it is by no means set in stone. It is important to remember

that the document must be molded to fit your organization.

What is ROI and why is it important? Simply put, ROI is an acronym for return

on investment. It can be calculated by dividing a project’s net benefit to an

organization by the total cost. A ROI analysis is a document that is used to

show the benefits of a project in quantitative terms. It can be included as

a section in a business case, or presented separately as an independent document.

A ROI analysis may also include total cost of ownership calculations and a cost/benefit

analysis.

To create a successful ROI analysis, several types of information must be

included. In most cases, it is best to begin with an executive summary. In this,

project objectives, signification project factors, and a brief overview of the

project implementation plan should be included. Although it may be tempting

to add details, it is best to remain high-level. The executive summary is usually

the first section read, therefore should not be overwhelming. Next, a major

section of the document should be devoted to technology. In this, existing technology

should be described. What systems and processes are currently in use? What will

remain in use? What will be removed? Also, a moderately detailed description

of new technology that will be implemented as a result of the project should

be described.

The most significant piece of a ROI analysis is the business analysis. It

should include a description and listing of business drivers (that which has

a positive impact on the business). The business analysis section should include

tables that show initial project investment and recurring costs. Because the

project is security related, it is particularly important to show costs if no

investment.

The ROI analysis should conclude with a short summary that outlines the monetary

benefits of adopting the particular project. It should also include a brief

project overview. Although I’ve given you several ideas of what should be included

in an ROI analysis, it is by no means set in stone. It is important to remember

that the document must be molded to fit your organization.

Until next time,
Benjamin D. Thomas

 

LinuxSecurity Feature Extras:

Expert

vs. Expertise: Computer Forensics and the Alternative OS – No longer

a dark and mysterious process, computer forensics have been significantly

on the scene for more than five years now. Despite this, they have only recently

gained the notoriety they deserve.

REVIEW:

Linux Security Cookbook – There are rarely straightforward solutions

to real world issues, especially in the field of security. The Linux Security

Cookbook is an essential tool to help solve those real world problems. By

covering situations that apply to everyone from the seasoned Systems Administrator

to the security curious home user, the Linux Security Cookbook distinguishes

itself as an indispensible reference for security oriented individuals.

[ Linux

Advisory Watch ] – [ Linux

Security Week ] – [ PacketStorm

Archive ] – [ Linux Security

Documentation ]

Linux Advisory Watch is a comprehensive newsletter that outlines the security

vulnerabilities that have been announced throughout the week. It includes pointers

to updated packages and descriptions of each vulnerability. [ Subscribe

]

 
 
Distribution: Conectiva
7/28/2003 mnogosearch
mulitple

vulnerabilities

There are mulitple buffer overflow vulnerabilities in mnogosearch.

http://www.linuxsecurity.com/advisories/connectiva_advisory-3499.html

7/29/2003 perl
CGI.pm

XSS vulnerability

There is a cross site scripting vulnerability in the CGI.pm perl module.

http://www.linuxsecurity.com/advisories/connectiva_advisory-3500.html

Distribution: Debian
7/29/2003 sup
insecure

tmp file vulnerability

sup fails to take appropriate securityprecautions when creating temporary

files.

http://www.linuxsecurity.com/advisories/debian_advisory-3501.html

7/30/2003 xconq
buffer

overflow vulnerabilities

Steve Kemp discovered a buffer overflow in xconq, in processing theUSER

environment variable. In the process of fixing this bug, asimilar problem

was discovered with the DISPLAY environmentvariable.

http://www.linuxsecurity.com/advisories/debian_advisory-3503.html

7/31/2003 gallery
XSS

vulnerability

Larry Nguyen discovered a cross site scripting vulnerability in gallery,a

web-based photo album written in php.

http://www.linuxsecurity.com/advisories/debian_advisory-3504.html

7/31/2003 xtokkaetama
XSS

vulnerability

Steve Kemp discovered two buffer overflows in xtokkaetama, a puzzlegame,

when processing the -display command line option and theXTOKKAETAMADIR environment

variable.

http://www.linuxsecurity.com/advisories/debian_advisory-3505.html

Distribution: Mandrake
7/25/2003 kernel
kernel

packages fix multiple vulnerabilitie

Multiple vulnerabilities were discovered and fixed in the Linux kernel.

http://www.linuxsecurity.com/advisories/mandrake_advisory-3497.html

Distribution: Red

Hat

7/25/2003 stunnel
Signal

vulnerability

Updated stunnel packages are now available for Red Hat Linux 7.1, 7.2, 7.3,and

8.0. These updates correct a potential vulnerability in stunnel’ssignal

handling.

http://www.linuxsecurity.com/advisories/redhat_advisory-3498.html

7/29/2003 openssh
information

leak vulnerability

Under certainconditions, OpenSSH versions prior to 3.6.1p1 reject an invalidauthentication

attempt without first attempting authentication using PAM.

http://www.linuxsecurity.com/advisories/redhat_advisory-3502.html

Distribution: TurboLinux
7/31/2003 kdelibs
authentication

vulnerability

Konqueror may unknowingly distribute website authentication credentials

to third parties with links on the password protected website.

http://www.linuxsecurity.com/advisories/turbolinux_advisory-3506.html