QUESTION (A)

An organization should define its requirements and goals for performing logging and
monitoring logs. The requirements should include all applicable laws, regulations, and
existing organizational policies, such as data retention policies. The goals should be
based on balancing the organization’s reduction of risk with the time and resources
needed to perform log management functions. The requirements and goals should then
be used as the basis for establishing an organization-wide log management capability
and prioritizing log management appropriately throughout the enterprise Organizations
should develop policies that clearly define mandatory requirements and suggested
recommendations for several aspects of log management, including the following:

(A) Log Generation

 Which types of hosts must or should perform logging
 Which host components must or should perform logging (e.g., OS, service,
application)
 Which types of events each component must or should log (e.g., security events,
network connections, authentication attempts)
 Which data characteristics must or should be logged for each type of event (e.g.,
username and source IP address for authentication attempts)
 How frequently each type of event must or should be logged (e.g., every
occurrence, once for all instances in x minutes, once for every x instances, every
instance after x instances)

(B) Log Transmission

 Which types of hosts must or should transfer logs to a log management
infrastructure
 Which types of entries and data characteristics must or should be transferred
from individual hosts to a log management infrastructure
 How log data must or should be transferred (e.g., which protocols are
permissible), including out-of-band methods where appropriate (e.g., for
standalone systems)
  How frequently log data should be transferred from individual hosts to a log
management infrastructure (e.g., real-time, every 5 minutes, every hour)
 How the confidentiality, integrity, and availability of each type of log data must or
should be protected while in transit, including whether a separate logging
network should be used

(C) Log Storage and Disposal

 How often logs should be rotated
 How the confidentiality, integrity, and availability of each type of log data must or
should be protected while in storage (at both the system level and the
infrastructure level
 How long each type of log data must or should be preserved (at both the system
level and the infrastructure level)
 How unneeded log data must or should be disposed of (at both the system level
and the infrastructure level)
 How much log storage space must or should be available (at both the system
level and the infrastructure level)
 How log preservation requests, such as a legal requirement to prevent the
alteration and destruction of particular log records, must be handled (e.g., how
the impacted logs must be marked, stored, and protected)

(D) Log Analysis

 How often each type of log data must or should be analyzed (at both the system
level and the infrastructure level)
 Who must or should be able to access the log data (at both the system level and
the infrastructure level), and how such accesses should be logged
 What must or should be done when suspicious activity or an anomaly is identified
 How the confidentiality, integrity, and availability of the results of log analysis
(e.g., alerts, reports) must or should be protected while in storage (at both the
system level and the infrastructure level) and in transit
  How inadvertent disclosures of sensitive information recorded in logs, such as
passwords or the contents of e-mails, should be handled.

An organization’s policies should also address who within an organization can establish
and manage log management infrastructures. Organizations should also ensure that
other policies, guidelines, and procedures that have some relationship to logging
incorporate and support these log management requirements and recommendations,
and also comply with functional and operational requirements. An example is ensuring
that software procurement and custom application development activities take log
management requirements into consideration.

Table 1.0 provides examples of the types of logging configuration settings to be

specified in policies. Organizations should not adopt these values as-is, but instead use
them as a starting point for determining what values are appropriate for their own needs
and comply with applicable regulations and laws. An organization should conduct a
detailed analysis of all initiatives which may affect its logging requirements, along with
other factors, when determining what logging configuration settings it should require.
Also, more stringent requirements for performing log preservation in support of
investigations should override the standard organization-established values for log
retention as applicable

The types of values defined in Table 1.0 should only be applied to the hosts and host
components previously specified by the organization as ones that must or should be
logging security-related events. Organizations should also consider creating separate
tables for hosts and host components that will use a log management infrastructure and
ones that will not. Also, separate requirements may be needed for hosts that use out-of-
band methods to provide log data to a log management infrastructure. For example, it is
probably not feasible to require log data to be transferred out-of-band to the centralized
servers hourly. Similar limitations exist with an organization’s mobile systems, such as
laptops, that may be in use outside the organization but are not necessarily able to
transfer log information.
 Table 1.0: Procedures

Legal issues related to logging should also be addressed in the organization’s policies.
Logging can capture (intentionally or incidentally) information with privacy or security
implications, such as passwords or the contents of e-mails. This could expose the
information to staff members that are analyzing data or administering the recording
systems (e.g., IDS sensors). Organizations should have policies regarding the handling
of inadvertent disclosures of sensitive information. Another problem with capturing data
such as e-mails and text documents is that long-term storage of such information may
violate an organization’s data retention policy. It is also important to have policies
regarding monitoring of networks. Organizations should consult legal counsel when
developing logging policies to ensure that complex issues such as data retention are
addressed properly.

The organization’s policies and procedures should also address the preservation of
original logs. Many organizations send copies of network traffic logs to centralized
devices, as well as use tools that analyze and interpret network traffic. In cases where
logs may be needed as evidence, organizations may wish to acquire copies of the
original log files, the centralized log files, and interpreted log data, in case there are any
questions regarding the fidelity of the copying and interpretation processes. Retaining
logs for evidence may involve the use of different forms of storage and different
processes, such as additional restrictions on access to the records. Log integrity may
also need to be preserved, such as storing logs on write-once media or generating
message digests for each log file.

Organizations should perform periodic reviews of their logging-related policies and

update them as needed. Possible causes for updates include the results of audits,
changes to legal and regulatory requirements, and feedback from infrastructure and
system-level administrators on logging requirements. Organizations should also
periodically review recommendations from infrastructure and system-level administrators
on policy changes related to the reconfiguration of security controls. For example,
suppose that host-based firewalls on many systems are logging large numbers of port
scans from external hosts, and these log entries comprise a large percentage of the total
logs of the firewalls. The organization might decide to alter its policies so that the
scanning activity is prohibited, which would lead to network firewall configuration
changes that would prevent the scans from reaching the individual systems and their
host-based firewalls. This would cause a significant reduction in the number of security
events logged by the host-based firewalls.
QUESTION (B)

Web Vulnerability Scanners

Scanners are handy tools that help you automate and ease the process of securing a
web server and web applications.   Web Vulnerability Scanner is also shipped with a port
scanner, which when enabled will port scan the web server hosting the web application
being scanned.  Similar to a network security scanner, Web Vulnerability Scanner will
launch a number of advanced security checks against the open ports and network
services running on your web server.

Web Vulnerability Scanner ensures website and web server security by checking

for SQL Injection, Cross site scripting, web server configuration problems and other
vulnerabilities.  It checks password strength on authentication pages and automatically
audits shopping carts, forms, dynamic Web 2.0 content and other web applications.  As
the scan is completed, the software produces detailed reports that pinpoint where
vulnerabilities exist. 

(A) IBM AppScan

IBM AppScan helps software developers protect against the threat of attacks and data
breaches. If the user use the Web applications to collect or exchange sensitive or
personal data, their job as a security professional is harder now than ever before.

AppScan is an example of a Fuzzer, which is a program that conducts a black box

software testing technique, consisting of finding implementation bugs using
malformed/semi-malformed data injection in an automated fashion.

Weakness
JavaScript crawling was not as effective as would be desired (this determined by the
URLs and vulnerabilities that it missed). During the testing Appscan had numerous
scans crash or hang, which caused delays. Appscan missed 45% of vulnerabilities, even
after the tool was trained to know all of the links.
Technical Supported
AppScan as a scanner required little support for the study.

Industry Review
Appscan is solid and seasoned scanning tool and while it did not top the study, it always
delivers consistent and reliable results. In in Point and Shoot scanning, it came in as the
clear second place solution.

(B) Acunetix Web Vulnerability Scanner

Acunetix Web Vulnerability Scanner (WVS) broadens the scope of vulnerability scanning
by introducing highly advanced heuristic and rigorous technologies designed to tackle
the complexities of today's web-based environments. WVS is an automated web
application security testing tool that audits the web applications by checking for
vulnerabilities like SQL Injections, Cross site scripting and other exploitable hacking
vulnerabilities. In general, Acunetix WVS scans any website or web application that is
accessible via a web browser and that respects HTTP/HTTPS protocol. Besides
automatically scanning for exploitable vulnerabilities, WVS offers a strong and unique
solution for analyzing off-the-shelf and custom web applications including those relying
on client scripts such as JavaScript, AJAX and Web 2.0 web applications. Acunetix WVS
is suitable for any small, medium sized and large organizations with intranets, extranets,
and websites aimed at exchanging and/or delivering information with/to customers,
vendors, employees and other stakeholders.

Weakness
Accunetix missed 53% of the vulnerabilities even after being trained to know all of the
pages. As mentioned previously, on their own test site, Accuntix missed 31% of the
vulnerabilities after training and 37% without training. This is a significant cause for
concern as they should be aware of the links vulnerabilities on their own site and be able
to crawl and attack them. These test sites are relatively small; in any site that cannot be
completely crawled manually, testers should be wary of relying exclusively on Accunetix
given the weakness of its crawler.
Technical Supported
The staff at Acunetix is very responsive and was helpful with keeping their test sites up
and resetting them as needed. When help was needed to understand how to best train
the scanner using manual crawling, they promptly provided clear documentation on how
to use the various included tools to accomplish the task.

Industry Review
Accunetix lagged the industry leaders in point and shoot mode, giving rise to concerns
about running it without significant training. If it is trained to find every link, it is a close
third to Appscan.
Comparison Chart between IBM AppScan & Acunetix Web Vulnerability Scanner
REFERENCE

A. Babbin, Jacob et al, Security Log Management: Identifying Patterns in the Chaos,
Syngress, 2006.

B. Bauer, Michael D., Chapter 10 (System Log Management and Monitoring) of Building
Secure Servers with LINUX, O’Reilly, 2002.

C. Giuseppini, Gabriele, Microsoft Log Parser Toolkit, Syngress, 2005.

D. Maier, Phillip Q., Audit and Trace Log Management: Consolidation and Analysis,
Auerbach, 2004.

E. Singer, Abe and Bird, Tina, Building a Logging Infrastructure, USENIX Association,
2004.

F. Andy Meneely, Ben Smith, and Laurie Williams. (2009). Using IBM’s Rational
AppScan. http://agile.csc.ncsu.edu/SEMaterials/tutorials/appscan/ (18 Oct 2010)