WWW/Internet Audit Considerations

After your distributed Internet, intranet, and WWW security policies are firmly established, distributed security architectures are updated to accommodate this new environment. When planning for audit, and security control mechanisms are designed and implemented, you should plan how you will implement the audit environment — not only which audit facilities to use to collect and centralize the audit function, but how much and what type of information to capture, how to filter and review the audit data and logs, and what actions to take on the violations or anomalies identified. Additional consideration should be given to secure storage and access to the audit data. Other considerations include:

•  Timely resolution of violations

•  Disk space storage availability

•  Increased staffing and administration

•  In-house developed programming

•  Ability to alarm and monitor in real time

WWW SECURITY FLAWS

As with all new and emerging technology, many initial releases come with some deficiency. But this has been of critical importance when that deficiency can impact the access or corruption of a whole corporation or enterprise’s display to the world. This can be the case with Web implementations utilizing the most current releases which have been found to contain some impacting code deficiencies, though up to this point most of these deficiencies have been identified before any major damage has been done. This underlines the need to maintain a strong link or connection with industry organizations that announce code shortcomings that impact a sites Web implementation. A couple of the leading organizations are CERT, the Computer Emergency Response Team, and CIAC, Computer Incident Advisory Capability.

Just a few of these types of code or design issues that could impact a sites Web security include initial issues with the Sun JAVA language and Netscape’s JavaScript (which is an extension library of their HyperText Markup Language, HTML).

The Sun Java language was actually designed with some aspects of security in mind, though upon its initial release there were several functions that were found to be a security risk. One of the most impacting bugs in an early release was the ability to execute arbitrary machine instructions by loading a malicious Java applet. By utilizing Netscape’s caching mechanism a malicious machine instruction can be downloaded into a user’s machine and Java can be tricked into executing it. This doesn’t present a risk to the enterprise server, but the user community within one’s enterprise is of course at risk.

Other Sun Java language bugs include the ability to make network connections with arbitrary hosts (though this has since been patched with the following release) and Java’s ability to launch denial of service attacks though the use of corrupt applets.

These types of security holes are more prevalent than the security profession would like to believe, as the JavaScript environment also was found to contain capabilities that allowed malicious functions to take place. The following three are among the most current and prevalent risks:

•  JavaScripts ability to trick the user into uploading a file on his local hard disk to an arbitrary machine on the Internet

•  The ability to hand out the user’s directory listing from the internal hard disk

•  The ability to monitor all pages the user visits during a session

The following are among the possible protection mechanisms:

•  Maintain monitoring through CERT or CIAC, or other industry organizations that highlight such security risks.

•  Utilize a strong software distribution and control capability, so that early releases aren’t immediately distributed, and that new patched code known to fix a previous bug is released when deemed safe.

•  In sensitive environments it may become necessary to disable the browser’s capability to even utilize or execute JAVA or JavaScript — a selectable function now available in many browsers.