Security Ripcord

Okay, so the title is a little bit of a misnomer.  I have not found any security websites using web bugs.  Where this stems from is my own pondering.  At my 8 to 5 organization I have been wondering how I should track the usage of the security based website I manage.  This makes good sense because I want to see if I am reaching my audience. 

As I am not the administrator of the resource I do not have the proper privileges to view the logs associated with the web server.  Actually, I do not want those privileges unless necessary for auditing or incident response purposes.  I also do not want to burden the system administrator any more than necessary.  So, rather than ask for the output of the log associated with my virtual host I have started thinking about methods that I can track hits using some type of PHP counter.

While I was investigating how to accomplish this I received a few emails so I took a look.  I had received a couple mundane messages and an email from a vendor.  Once I opened the vendor email I noticed the usual vendor email format which, unfortunately, is strewn with plaintext HTML links.  The very first link was a web bug.  It said so right on the image “title=”Web Bug…”.  So, I started thinking to myself,  “Hmmm, web bug.”  Would that work?  I could include it in every web page.  I could include it in all of the documents and presentations I provide on the site.  This will tell me how often stuff is getting viewed and whether they are coming from the intranet or the Internet.  Exactly the information I could get from the web log.  But for some reason the idea of including a web bug on the site and in the documents made my skin crawl.  So I decided to do a little asking around in the Security Catalyst Community.  I started a thread titled “Web Bugs on Internal Security Sites“.

My call was answered by several people including Rebecca Herold.  She provided me with some good insight but even better documentation.  First she pointed me to a paper by the National Advertising Initiative.

Also, the The National Advertising Initiative (NAI) created a set of standards that cover the use of web bugs (also called web beacons, web gifs, and several more a.k.a.’s) on Internet sites.  You may find their standards interesting and perhaps helpful to your consideration of using them within your network: http://www.networkadvertising.org/networks/Web_Beacons_rev_11-1-04.pdf

Next she posted a white paper that she wrote about web bugs back in April 2005 titled “Quit Buggin Me!”  I have read it already and I highly recommend it if you are interested in web bugs.  Although I usually link directly to a document I would rather force you to her site so you can be aware of her other papers and books.  The paper can be found at her “Articles Regarding Technology Aspects of Privacy” page.

By this time I was completely squared away by Ms. Herold.  Although not necessarily bad, web bugs are not necessarily good.  In fact, they have to be used properly or you may face issues with your users, your organization, or even your government.  In this case my government would be the State of Texas.  So, to continue my research I did a little Googling.  And, of course, I got a hit that directed me to the Texas Department of Information Resources.   It was very quickly apparent that the State of Texas has a policy on how to use persistent cookies and Web Bugs.  In fact, the guidance set by the Texas Department of Information Resources states:

In order for visitors to make informed decisions about the privacy practices of state agencies, the visitor should be able to access the home page and Privacy and Security Policy page without the site setting a cookie or using a web bug to track visitor [sic].

Delving in a little deeper I noticed that there is specific guidance for Institutions of Higher Education.  Particularly Texas Administrative Code Rule 206.73 Privacy and Security of State Web Sites.  

(a) Each institution of higher education shall publish a privacy and security policy for its Web site, and post a link to the policy from its home page, or Site Policies page. The privacy and security policy shall address the following:
  (1) Notice: This section must disclose the institution of higher education’s information practices before the site collects personal information from the public, including the use of, cookies, and/or Web bugs as well as information collected by other technologies and processes, and information collected via e-mail and Web-based forms.
  (2) Choice: This section must disclose whether and how personal information collected from the public may be used for purposes beyond those for which the information was provided.
  (3) Access: This section must address the procedure under which an individual may obtain information about himself or herself from the institution of higher education and/or have the institution of higher education correct information about the individual.
  (4) Security: This section must describe the procedures that ensure that information collected from individuals is accurate and secure from unauthorized use.

So, basically, after a little help from the Security Catalyst Community and a little research into the laws and regulations set forth by my government I have decided that it will be much better for me to glean the personal information of the visitors to my internal website from the web logs provided by the web server than to glean them from a web bug or some other type of overt tracking mechanism.

Go forth and do good things,
Cutaway

Powered by ScribeFire.

cookies, privacyguidance.com, DIR, SCC, Texas, Security Ripcord, Rebecca Herold, web bug

Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.