convince the candidate that his is a greatcompany to work for. The competitorwould be blissfully unaware that it hadbecome the victim of social engineeringand may only realize it is too late — whenan account has been poached. It is alsovery hard to prove and certainly to legislate against.

Social engineering is all about exploit-ing social weaknesses, the ordinary weak-nesses of you or I, whether it be apassword on a monitor, sympathy forsomeone carrying hot coffee or braggingabout something in a pub.

Social engineering has been with us forever, in many guises. People havealways exploited others’ vulnerabilities fortheir own gain. In the Richard NixonWatergate scandal of the 1970s, FBIoperatives dressed up as telephone engineers to infiltrate the CIA.

ProtectionSo how do you protect yourself andyour company from social engineering?Technology cannot protect you fromsocial engineering because the firewall,Web server or database is not the target:as an employee, you offer a window into the business. If technology was the

target it might be easier to protectagainst.

The problem is that it’s not easy toreprogram a person. However manytraining sessions and security audits youundergo, you are still likely to act as ahuman being from time to time. Openingdoors, offering to carry someone’s heavybags or helping a new starter to work outthe key code system on the door. Thisneeds a clearly defined corporate policy,underwritten and endorsed by the boardof directors.

At its most comprehensive, it requires acommittee which includes humanresources, IT security, physical securityand facilities management (those respon-sible for buildings, reception etc.) andempowered representatives from relevantbusiness units. The director of humanresources or the director of securityshould head a committee of this sort. Itsremit should be to coordinate the relevantsecurity practices across the organizationand provide for corporate-wide awarenessprogrammes. Information for this cancome from a number of sources includingthe Computer Security Institute (CSI),SANS, large consulting groups e.g.PricewaterhouseCoopers.

Guidance for implementation shouldcome from local IT security experts withexperience in providing corporate securitypolicies, cyber-liability and similar pro-grammes. Not all players in this space arethe same in terms of appropriate and ade-quate resources. To misquote GeorgeOrwell’s Animal Farm, “All IT securityfirms are incorporated equally, but someare more equal than others.”

ConclusionSocial engineering is with us to stay.However, concentrating on protectingyourself and your business’s most valuableassets is a good place to start in order toprotect yourself. In the work place, do notgive more access than necessary.Minimizing the number of people whohave access to confidential files like pay-roll, can help reduce the risk but will noteliminate it.

Ultimately, social engineers can be bestthwarted by educating your employees. Inthis day and age, risk is everywhere.People do not have to become obsessiveor discourteous to protect themselves and their company’s assets. They simply need to be alive to the risks and remain vigilant.

feature

11

Things are changing, and I think that forseveral reasons Web servers would repaysome audit attention now.

Like many new technologies, Web-basedapplications have tended to be managed

fairly informally, a lively and active sitebeing seen as more important than the oddspelling mistake or factual inaccuracy.

Normally, little attention has beenpaid to security. Originally, when sites

simply published static pages, the argu-ment was that there was little scope forhacking, but as the http protocol hasbeen extended and scripting becomeubiquitous, so the opportunities haveincreased.

The most obvious reason why yourwebsite will have a higher profile is thecoming closer integration between corebusiness systems and Web applications.Even if your company is not currentlyconsidering customer-facing applications,it is likely soon to have to dabble at leastin E-procurement, at the insistence of itssuppliers.

Looking at an information-only website will give you, and also the devel-opers, some view about the security of thecurrent set-up, and some guidance aboutwhat needs to be done to strengthen itbefore it’s used more intensively and forareas of higher risk.

Why Audit a Web Server?Auditing Web servers: IIS 4.0 — Part 1Alison Webb

A Web server is a wonderful business communication channel — it relays informa-tion cheaply, conveniently and, in theory, to almost everyone. Traditionally, in myexperience at least, the Web is not an area auditors have taken particularly seriously:until recently, it has not been used to transact business, but simply to publicize theorganization. Most companies run their Web applications on a firewall interface orinterfaces outside the internal network, so the audit, more concerned with the corebusiness applications, could rely on the firewall to protect against hackers, and treatthe Web server as, at worst, a bastion host.

issue.qxd 7/26/01 1:21 PM Page 11

So, if you decide to audit your compa-ny’s websites, how should you start todraw up your audit plan?

Two things make your audit objec-tives different from those for, say, theaudit of a financial application. Firstly,in an information-only website, themain risk is not that of error in thefinancial transactions, or of fraud. It ispublic embarrassment should your sitebe defaced or disabled. Secondly, therisk of people attacking your applica-tion is high, particularly if you put timeand effort into producing an interesting

and informative website, or if yourbusiness is the sort that lends itself toWeb publicity, so visitors find it useful.The more popular your site, the morehackers it will attract. These differ-ences, although obvious, affect theplanning of your audit and where youspend your time.

This first article looks briefly at what aWeb server does, and how it works. It alsolooks at some specific controls which areparticularly important. I’m usingMicrosoft IIS 4.0 running underWindows NT as my example, as this is a

common configuration, but the princi-ples apply to all installations.

How does a Web server work?In principle, it’s no different from any ofthe other network applications that we alluse. A functioning network is not unlikean interactive version of Exchange andMart, but instead of people who want tobuy or sell, the marketplace is made up ofprocesses running on network computers,some of which (clients) want things, andothers of which (servers) have them onoffer.

In theory, it is these processes — likemail or telnet — which are the serversand clients, but often, the computer onwhich they run is called the server or theclient as well.

A server computer runs a server processfor every service it offers, and each serverprocess listens out for requests fromclients. If I access the Internet, InternetExplorer is my client program, and theWeb server of the company I target is thecomplementary program that listens outfor, and responds to, my request.

When I communicate with the Webserver, what do I ask, and what sort ofinformation will the server send me? If Iknow exactly what I want, I ask for aparticular “page”: if not, I leave out anypage reference and I’ll get the one thatthe Web server has designated as thedefault.

At its simplest, the page is based on afile of text “marked up” with the familiarhtml tags which dictate how it is format-ted. It is this file that is sent to my clientbrowser, and the browser knows how tointerpret the tags to display the screen theserver intends me to see.

In Figure 1, I’ve asked for a page byname — simple.htm. Figure 2 shows thenetwork data packet that sent the data tothe client and you can see the html tags init. Notice how little of the informationactually appears as text on the screenitself: most of it is used for formatting.Simple.htm is a text file.

This is still how websites work in prin-ciple, but the simplicity is largely a thingof the past. Most pages now are virtual –they are constructed at the time the client

feature

12

Figure 2: The network data packet that sent simple.htm to the client

Figure 1: A simple web page, simple.htm, displayed on the browser.

issue.qxd 7/26/01 1:22 PM Page 12

requests information. To achieve this, thedefault page, or the page requested, con-tains programming commands whichconstruct the packet returned to theclient. The advantage is that up-to-dateinformation (like the time and date) canbe included in the “page” that the clientsees.

If the page requested was an active serv-er page I would see the time and date andthis would be backed up by the contentsof the packet. However, the file itselfwould just contain the scripting to calcu-late the time and then compose the pack-et, and this is re-computed every time thepage is requested.

The scripts can be more or less compli-cated, and can be bulked out with refer-ences to subsidiary script files (server-sideincludes).

So, the Web server has the followingfunctions:• It decodes the request from the client.• It finds the file of data to which the

request refers. This file may be a filethe client asks for by name, or adefault.

• It executes any scripts.• It compiles a return packet in the

form of a standard .htm page that theclient will be able to de-code.

• It sends the packet back to the client.

Summary of risksSo much for the theory — what are therisks? This raises some interesting issues,because the business objectives for a Webserver are very different from those for astandard financial application.

Web servers are intended to be used byas many people as possible, and the keyrisks arise from their high public expo-sure, and the importance of their contin-uous availability.

This means that security precautionsshould be directed firstly at eliminatingmistakes evident on the pages themselves.Any error will be seen (and derided) byfar too many potential customers. Thisapplies obviously to information which iswrong or out-of-date, but even to trivialslips like spelling mistakes.

The other consequence of a high-pro-file Web presence is that many people

(not just employees on the internal net-work) will take the opportunity to try tohack the site, and the better the site is, themore hackers it will attract. They willprobably aim at crashing the site, becausethis is much easier than corrupting it, sothe other focus for security is in maintain-ing continuous availability.

PrecautionsFirstly, there are one or two precautionscommon to all applications which help toreduce the risk of service disruption, or which reduce the impact if the worsthappens.

It’s important to make sure that in the atmosphere of informality that cansurround websites and their managementthey aren’t forgotten.

Turing to more specific controls, I’lldeal with the elimination of mistakes andhow to avoid attracting hackers.

1 Eliminating mistakes

1.1 Site maintenanceWeb server software usually comes with adefault site that the developer can use tocheck the server configuration before thelive site is loaded. A surprising number ofsites don’t disable these demonstrationand test screens, so that browsers may seeinformation that is totally irrelevant(except to Microsoft).

To check this, try contacting the website using the page referencedefault.asp. If the information seemsmore relevant to Microsoft, then whoevermaintains the site hasn’t done too good ajob customising it. Configure the site professionally — remove developmentmaterial.

1.2 Author standards There are various points here to do withhow the company authorizes the releaseof information into the public domain,and the procedures should be similar forthose for authorizing, say, advertisementsor press releases.

Since responsibility for site contentmay be delegated to departments, it isworth reviewing some of the content indetail. Data Protection and HumanRights legislation impose strict conditionson the use of data, and if pages quote sur-vey results, for example, they should beapproved by the Data Controller as partof the approval process before the infor-mation is published.

More generally, if you’re keen on gram-mar and spelling, very few sites managetext that is error-free. They may havesome writing standards, but there is rarelyanyone whose job it is to proof-read publication material. How much mis-takes matter depends on organization’sview, but at best they look slightly incom-petent. Personally, I find errors irritatingand am thinking of lobbying for anApostrophe Czar.

Make sure the content complies withlegislation, particularly the DP Act. Payattention to grammar and spelling

2 Preventing hackingHere, I think the biggest risk for mostWeb servers is programming error, on thepart of two different sets of programmers.

2.1 Application programmers The first are the Microsoft programmerswho wrote the application. This is unusu-al — mostly, auditors rely on the testingdone when an application is developed toensure that it works according to specifi-cation.

There are two differences here, though.Firstly, your Web server will be continual-ly and aggressively tested throughout itslife by the army of hackers on theInternet. Secondly, there is no need forsomeone to probe delicately for anobscure loophole that allows him or herto defraud the company while coveringhis or her tracks. Hackers are anonymous

13

feature

• Backup key files and have atested contingency plan.

• Document changes to the con-figuration so they can easily bereapplied.

• Install virus-checking software.Check incoming files and scandisks regularly.

issue.qxd 7/26/01 1:22 PM Page 13

anyway. They are interested in lookingaround your server, or using it as a plat-form to attack other people, or, if they aremalicious, interrupting your Web serviceor tampering with data files. We need toworry about bugs that will allow them tobreak out of the well-controlled http dia-logue with the server and get to grips withthe server computer itself.

One key control is simply a process thatensures that the site is using an up-to-dateversion of IIS, with all the latest bug fixes.

How can you check this? One useful website is uptime.netcraft.com, whichanalyses any website for you. In particu-lar, it tells you which version of the Webserver software the site is running. TheMicrosoft website also has informationabout known exposures, as doeswww.sans.org.

What happens if you don’t keep up todate? As an example, IIS 4.0, ifunpatched, has a bug which allows hack-ers to list files on the server computer.The bug can be exploited to show a direc-tory listing that has nothing to do withthe Web files. Unless the server is well-protected (using NTFS file permissions),

the hacker can delete files. Rememberthat new directories and files on an NTmachine are created with Everyone(including the Internet browser process)with Full Control.

Keep the software current, and installall the security fixes.

2.2 Web authorsThe other programmers are those whowrite the code that constructs the Webpages. Because the techniques are rela-tively new, the well-established rules ofgood programming may largely beabsent. For instance, one site I reviewedallowed people to update frequentlychanging pages remotely. To do so, theupdater called up a particular pagewhich prompted him for an id and password. The code behind thepage included a simple check along the lines of “if id = alison and password= secret, then display the update page”.

Unfortunately, anyone able to displaythe coding (and this was anyone with abit of persistence) could find out thedetails of the id and password. This sort

of sloppy coding is rare now in standardapplications, and there seems no reason why websites should be anexception.

Maintain programming standards forWeb developers.

ConclusionThis article has looked at the basic con-trols to think about when reviewing aWeb server. It hasn’t, however, consid-ered how the Web application and theserver operating system interact, andwhat opportunities this can give thehacker, if badly managed. The secondof these articles delves further into thetechnicalities of Web servers. It coversthe security features that come withMicrosoft IIS, and suggests how theycan be used with the operating systemsecurity, to reduce the chances of dis-ruption.

About the authorAlison Webb BA FCA MBCS CISA hasbeen an independent computer audit con-sultant since 1990. Her telephone number is+44 01223 461316.

14

feature

An undated document obtained byNetwork Security discloses that theDefense Science Board Task Force onDefensive Information Operations hasrecommended that US wiretapping law(currently governed by Title III and

Foreign Intelligence Surveillance Actstatutes) be amended to permit long-termNSA investigations of Internet users,including US citizens.

The board favours a “trespasser” excep-tion to Title III that would allow NSA to

deny any expectation of privacy to any-one thought to be engaged in computerhacking. The report also calls for bypass-ing the FISA, which limits NSA’s target-ing of US persons to foreign espionageincidents, in cases involving hackerattacks. The report states that in suchcases, NSA should be permitted to “uti-lize overseas intelligence collectionresources to gather information on theattack, thus avoiding the need to invokeFISA at all.”

“the NSA wants to use itsSIGINT apparatus against

US persons”

With an obvious reference to NSA signals intelligence systems like Echelon,the report states, “Intelligence collectionefforts outside of the United States face fewer restrictions on gathering

Pentagon Orders NSA toMonitor US Citizens

DoD panel recommends Echelon be turned on UScitizens, increased domestic role for NSA

Wayne Madsen

Although NSA Director Lt. Gen. Michael Hayden told ABC News in an interviewon 10 July that his agency does not target the communications of American citizens,a Pentagon Task Force has recommended that the SIGINT agency do exactly that.

issue.qxd 7/26/01 1:22 PM Page 14