Archive

Archive for the ‘Rants’ Category

Tracking User Logon Activity Using Logon Events

August 21st, 2008 Comments off

I get the question fairly often, how to use the logon events in the audit log to track how long a user was using their computer and when they logged off.


As I have written about previously, this method of user activity tracking is unreliable.  It works in trivial cases (e.g. single machine where the user doesn’t have physical access to the power switch or power cord), and it works most of the time in simple cases where there is good network connectivy and the user is not trying to evade detection.  If the user has physical access to the machine– for example, can pull out the network or power cables or push the reset button– and if the user is actively trying to evade time tracking, then the only reliable solution is to surreptitiously put a video camera (subject to local laws) in a place that can monitor the user’s presence in front of the keyboard (yes I am aware of research done to track sound of keyboard clicks, etc.).


There is no way to instrument the OS to account for someone who just backs away from the keyboard and walks away.  The screen saver, if configured, will come on after a configurable delay since the last keypress or mouse movement.  Yes, if you know the SS delay then you could just work that into your calculations.  However the workstation does not lock until the screen saver is dismissed (some of you might have noticed that when you bump the mouse to dismiss the screensaver, sometimes you see your desktop for a fraction of a second- that’s because your machine isn’t locked while the screen saver is being displayed).  And the events don’t tell you whether the workstation was locked or auto-locked so you don’t really know whether to add in the screen saver delay factor.  Plus, prior to Windows Vista, there is no workstation lock event at all, only an unlock event, which is constructed in a way which makes it difficult to correlate with the original logon event.


So the bottom line is, I don’t advocate or recommend this method for tracking the time a user spends at the keyboard.  If I were hypothetically called as an expert witness, I would testify that such a method is unreliable and trivially circumvented.  You have been warned, I’ve beaten that dead horse enough I guess.


Given that you are disregarding all my contrary advice, how are you going to accomplish this?


First, we need a general algorithm.



Use time (for a given logon session) = Logoff time – logon time


Now, what about the cases where the user powers off the machine, or it bluescreens, or a token leak prevents the logoff event from being generated, etc.?  We can use the BEGIN_LOGOFF event to handle token leak cases.  We can use the shutdown event in cases where the user does not log off.  And in case of crashes, the only event we can use is the startup event.  Note that each of these introduces increasing levels of uncertainty.



Logoff time = (logoff time | begin_logoff time | shutdown time | startup time)


This is good, but what about the time the workstation was locked?



Workstation lock time = unlock time – lock time
Total workstation lock time (for a given logon session) = SUM(workstation lock time)


How about remote desktop & terminal server sessions, and fast user switching?  You can connect and disconnect from logon sessions, during which time the user technically isn’t using the computer.



Session idle time = session connect time – session disconnect time
Total session idle time (for a given logon session) = SUM(session idle time)


How about times when the machine was idle?  We can estimate that by looking at the time the screen saver was in place and adding the screen saver timeout.



Console idle time = (screen saver dismiss time – screen saver invoke time + screen saver delay)
Total console idle time = SUM(console idle time)


Putting all of this together and modifying our original formula, we get:




Use time (for a given logon session) =
   Logoff time – logon time
      – SUM(workstation lock time)
      – SUM(session idle time)
      – SUM(console idle time)


When we expand it, it is not quite so pretty: 




Use time (for a given logon session) =
   ( (logoff time | begin_logoff time | shutdown time | startup time) – logon time )
      – SUM(unlock time – lock time)
      – SUM(session connect time – session disconnect time)
      – SUM(screen saver dismiss time – screen saver invoke time + screen saver delay)


You have to be very careful that you only look at events that are properly contained chronologically between two other appropriate events, to avoid accidentally pairing the wrong logon and logoff events, or pairing a lock workstation event from one logon session with a different logon session.  The best correlation field is the Logon ID field, the next best are timestamp and user name.  At various times you need to examine all of these fields.


Now, which event IDs correspond to all of these real-world events?


They are all found in the Security event log.  The pre-Vista events (ID=5xx) all have event source=Security.  The Vista/WS08 events (ID=4xxx) all have event source=Microsoft-Windows-Security-Auditing.



512 / 4608  STARTUP
513 / 4609  SHUTDOWN
528 / 4624  LOGON
538 / 4634  LOGOFF
551 / 4647  BEGIN_LOGOFF
N/A / 4778  SESSION_RECONNECTED
N/A / 4779  SESSION_DISCONNECTED
N/A / 4800  WORKSTATION_LOCKED
* / 4801    WORKSTATION_UNLOCKED
N/A / 4802  SCREENSAVER_INVOKED
N/A / 4803  SCREENSAVER_DISMISSED

* prior to Windows Vista, there was no event for locking the workstation.  Unlocking the workstation generated a pair of events, a logon event and a logoff event (528/538) with logon type 7.  These events had the same user name as the “original” logon session and were completely enclosed chronologically by the logon/logoff events for the “real” logon session, but did not contain the Logon ID of the original logon session or other unambiguous correlator.  This makes correlation of these events difficult.


All of these events are generated in the Logon/Logoff audit policy category, although on Windows Vista and Windows Server 2008 they are scattered among the various subcategories in this audit policy category.  The audit event spreadsheet that Ned wrote has all the policy subcategory mappings as well as the event descriptions.


Sorry that this is more of a do-it-yourself than a solution-in-a-box, but this is pretty difficult to script and so far I haven’t worked on a project that required this.


Eric

Categories: HowTo, Rants, Tips Tags:

Tracking User Logon Activity Using Logon Events

August 21st, 2008 No comments

I get the question fairly often, how to use the logon events in the audit log to track how long a user was using their computer and when they logged off.


As I have written about previously, this method of user activity tracking is unreliable.  It works in trivial cases (e.g. single machine where the user doesn’t have physical access to the power switch or power cord), and it works most of the time in simple cases where there is good network connectivy and the user is not trying to evade detection.  If the user has physical access to the machine– for example, can pull out the network or power cables or push the reset button– and if the user is actively trying to evade time tracking, then the only reliable solution is to surreptitiously put a video camera (subject to local laws) in a place that can monitor the user’s presence in front of the keyboard (yes I am aware of research done to track sound of keyboard clicks, etc.).


There is no way to instrument the OS to account for someone who just backs away from the keyboard and walks away.  The screen saver, if configured, will come on after a configurable delay since the last keypress or mouse movement.  Yes, if you know the SS delay then you could just work that into your calculations.  However the workstation does not lock until the screen saver is dismissed (some of you might have noticed that when you bump the mouse to dismiss the screensaver, sometimes you see your desktop for a fraction of a second- that’s because your machine isn’t locked while the screen saver is being displayed).  And the events don’t tell you whether the workstation was locked or auto-locked so you don’t really know whether to add in the screen saver delay factor.  Plus, prior to Windows Vista, there is no workstation lock event at all, only an unlock event, which is constructed in a way which makes it difficult to correlate with the original logon event.


So the bottom line is, I don’t advocate or recommend this method for tracking the time a user spends at the keyboard.  If I were hypothetically called as an expert witness, I would testify that such a method is unreliable and trivially circumvented.  You have been warned, I’ve beaten that dead horse enough I guess.


Given that you are disregarding all my contrary advice, how are you going to accomplish this?


First, we need a general algorithm.



Use time (for a given logon session) = Logoff time – logon time


Now, what about the cases where the user powers off the machine, or it bluescreens, or a token leak prevents the logoff event from being generated, etc.?  We can use the BEGIN_LOGOFF event to handle token leak cases.  We can use the shutdown event in cases where the user does not log off.  And in case of crashes, the only event we can use is the startup event.  Note that each of these introduces increasing levels of uncertainty.



Logoff time = (logoff time | begin_logoff time | shutdown time | startup time)


This is good, but what about the time the workstation was locked?



Workstation lock time = unlock time – lock time
Total workstation lock time (for a given logon session) = SUM(workstation lock time)


How about remote desktop & terminal server sessions, and fast user switching?  You can connect and disconnect from logon sessions, during which time the user technically isn’t using the computer.



Session idle time = session connect time – session disconnect time
Total session idle time (for a given logon session) = SUM(session idle time)


How about times when the machine was idle?  We can estimate that by looking at the time the screen saver was in place and adding the screen saver timeout.



Console idle time = (screen saver dismiss time – screen saver invoke time + screen saver delay)
Total console idle time = SUM(console idle time)


Putting all of this together and modifying our original formula, we get:




Use time (for a given logon session) =
   Logoff time – logon time
      – SUM(workstation lock time)
      – SUM(session idle time)
      – SUM(console idle time)


When we expand it, it is not quite so pretty: 




Use time (for a given logon session) =
   ( (logoff time | begin_logoff time | shutdown time | startup time) – logon time )
      – SUM(unlock time – lock time)
      – SUM(session connect time – session disconnect time)
      – SUM(screen saver dismiss time – screen saver invoke time + screen saver delay)


You have to be very careful that you only look at events that are properly contained chronologically between two other appropriate events, to avoid accidentally pairing the wrong logon and logoff events, or pairing a lock workstation event from one logon session with a different logon session.  The best correlation field is the Logon ID field, the next best are timestamp and user name.  At various times you need to examine all of these fields.


Now, which event IDs correspond to all of these real-world events?


They are all found in the Security event log.  The pre-Vista events (ID=5xx) all have event source=Security.  The Vista/WS08 events (ID=4xxx) all have event source=Microsoft-Windows-Security-Auditing.



512 / 4608  STARTUP
513 / 4609  SHUTDOWN
528 / 4624  LOGON
538 / 4634  LOGOFF
551 / 4647  BEGIN_LOGOFF
N/A / 4778  SESSION_RECONNECTED
N/A / 4779  SESSION_DISCONNECTED
N/A / 4800  WORKSTATION_LOCKED
* / 4801    WORKSTATION_UNLOCKED
N/A / 4802  SCREENSAVER_INVOKED
N/A / 4803  SCREENSAVER_DISMISSED

* prior to Windows Vista, there was no event for locking the workstation.  Unlocking the workstation generated a pair of events, a logon event and a logoff event (528/538) with logon type 7.  These events had the same user name as the “original” logon session and were completely enclosed chronologically by the logon/logoff events for the “real” logon session, but did not contain the Logon ID of the original logon session or other unambiguous correlator.  This makes correlation of these events difficult.


All of these events are generated in the Logon/Logoff audit policy category, although on Windows Vista and Windows Server 2008 they are scattered among the various subcategories in this audit policy category.  The audit event spreadsheet that Ned wrote has all the policy subcategory mappings as well as the event descriptions.


Sorry that this is more of a do-it-yourself than a solution-in-a-box, but this is pretty difficult to script and so far I haven’t worked on a project that required this.


Eric

Categories: HowTo, Rants, Tips Tags:

Tracking User Logon Activity Using Logon Events

August 21st, 2008 No comments

I get the question fairly often, how to use the logon events in the audit log to track how long a user was using their computer and when they logged off.


As I have written about previously, this method of user activity tracking is unreliable.  It works in trivial cases (e.g. single machine where the user doesn’t have physical access to the power switch or power cord), and it works most of the time in simple cases where there is good network connectivy and the user is not trying to evade detection.  If the user has physical access to the machine– for example, can pull out the network or power cables or push the reset button– and if the user is actively trying to evade time tracking, then the only reliable solution is to surreptitiously put a video camera (subject to local laws) in a place that can monitor the user’s presence in front of the keyboard (yes I am aware of research done to track sound of keyboard clicks, etc.).


There is no way to instrument the OS to account for someone who just backs away from the keyboard and walks away.  The screen saver, if configured, will come on after a configurable delay since the last keypress or mouse movement.  Yes, if you know the SS delay then you could just work that into your calculations.  However the workstation does not lock until the screen saver is dismissed (some of you might have noticed that when you bump the mouse to dismiss the screensaver, sometimes you see your desktop for a fraction of a second- that’s because your machine isn’t locked while the screen saver is being displayed).  And the events don’t tell you whether the workstation was locked or auto-locked so you don’t really know whether to add in the screen saver delay factor.  Plus, prior to Windows Vista, there is no workstation lock event at all, only an unlock event, which is constructed in a way which makes it difficult to correlate with the original logon event.


So the bottom line is, I don’t advocate or recommend this method for tracking the time a user spends at the keyboard.  If I were hypothetically called as an expert witness, I would testify that such a method is unreliable and trivially circumvented.  You have been warned, I’ve beaten that dead horse enough I guess.


Given that you are disregarding all my contrary advice, how are you going to accomplish this?


First, we need a general algorithm.



Use time (for a given logon session) = Logoff time – logon time


Now, what about the cases where the user powers off the machine, or it bluescreens, or a token leak prevents the logoff event from being generated, etc.?  We can use the BEGIN_LOGOFF event to handle token leak cases.  We can use the shutdown event in cases where the user does not log off.  And in case of crashes, the only event we can use is the startup event.  Note that each of these introduces increasing levels of uncertainty.



Logoff time = (logoff time | begin_logoff time | shutdown time | startup time)


This is good, but what about the time the workstation was locked?



Workstation lock time = unlock time – lock time
Total workstation lock time (for a given logon session) = SUM(workstation lock time)


How about remote desktop & terminal server sessions, and fast user switching?  You can connect and disconnect from logon sessions, during which time the user technically isn’t using the computer.



Session idle time = session connect time – session disconnect time
Total session idle time (for a given logon session) = SUM(session idle time)


How about times when the machine was idle?  We can estimate that by looking at the time the screen saver was in place and adding the screen saver timeout.



Console idle time = (screen saver dismiss time – screen saver invoke time + screen saver delay)
Total console idle time = SUM(console idle time)


Putting all of this together and modifying our original formula, we get:




Use time (for a given logon session) =
   Logoff time – logon time
      – SUM(workstation lock time)
      – SUM(session idle time)
      – SUM(console idle time)


When we expand it, it is not quite so pretty: 




Use time (for a given logon session) =
   ( (logoff time | begin_logoff time | shutdown time | startup time) – logon time )
      – SUM(unlock time – lock time)
      – SUM(session connect time – session disconnect time)
      – SUM(screen saver dismiss time – screen saver invoke time + screen saver delay)


You have to be very careful that you only look at events that are properly contained chronologically between two other appropriate events, to avoid accidentally pairing the wrong logon and logoff events, or pairing a lock workstation event from one logon session with a different logon session.  The best correlation field is the Logon ID field, the next best are timestamp and user name.  At various times you need to examine all of these fields.


Now, which event IDs correspond to all of these real-world events?


They are all found in the Security event log.  The pre-Vista events (ID=5xx) all have event source=Security.  The Vista/WS08 events (ID=4xxx) all have event source=Microsoft-Windows-Security-Auditing.



512 / 4608  STARTUP
513 / 4609  SHUTDOWN
528 / 4624  LOGON
538 / 4634  LOGOFF
551 / 4647  BEGIN_LOGOFF
N/A / 4778  SESSION_RECONNECTED
N/A / 4779  SESSION_DISCONNECTED
N/A / 4800  WORKSTATION_LOCKED
* / 4801    WORKSTATION_UNLOCKED
N/A / 4802  SCREENSAVER_INVOKED
N/A / 4803  SCREENSAVER_DISMISSED

* prior to Windows Vista, there was no event for locking the workstation.  Unlocking the workstation generated a pair of events, a logon event and a logoff event (528/538) with logon type 7.  These events had the same user name as the “original” logon session and were completely enclosed chronologically by the logon/logoff events for the “real” logon session, but did not contain the Logon ID of the original logon session or other unambiguous correlator.  This makes correlation of these events difficult.


All of these events are generated in the Logon/Logoff audit policy category, although on Windows Vista and Windows Server 2008 they are scattered among the various subcategories in this audit policy category.  The audit event spreadsheet that Ned wrote has all the policy subcategory mappings as well as the event descriptions.


Sorry that this is more of a do-it-yourself than a solution-in-a-box, but this is pretty difficult to script and so far I haven’t worked on a project that required this.


Eric

Categories: HowTo, Rants, Tips Tags:

Tracking User Logon Activity Using Logon Events

August 20th, 2008 No comments

I get the question fairly often, how to use the logon events in the audit log to track how long a user was using their computer and when they logged off.


As I have written about previously, this method of user activity tracking is unreliable.  It works in trivial cases (e.g. single machine where the user doesn’t have physical access to the power switch or power cord), and it works most of the time in simple cases where there is good network connectivy and the user is not trying to evade detection.  If the user has physical access to the machine– for example, can pull out the network or power cables or push the reset button– and if the user is actively trying to evade time tracking, then the only reliable solution is to surreptitiously put a video camera (subject to local laws) in a place that can monitor the user’s presence in front of the keyboard (yes I am aware of research done to track sound of keyboard clicks, etc.).


There is no way to instrument the OS to account for someone who just backs away from the keyboard and walks away.  The screen saver, if configured, will come on after a configurable delay since the last keypress or mouse movement.  Yes, if you know the SS delay then you could just work that into your calculations.  However the workstation does not lock until the screen saver is dismissed (some of you might have noticed that when you bump the mouse to dismiss the screensaver, sometimes you see your desktop for a fraction of a second- that’s because your machine isn’t locked while the screen saver is being displayed).  And the events don’t tell you whether the workstation was locked or auto-locked so you don’t really know whether to add in the screen saver delay factor.  Plus, prior to Windows Vista, there is no workstation lock event at all, only an unlock event, which is constructed in a way which makes it difficult to correlate with the original logon event.


So the bottom line is, I don’t advocate or recommend this method for tracking the time a user spends at the keyboard.  If I were hypothetically called as an expert witness, I would testify that such a method is unreliable and trivially circumvented.  You have been warned, I’ve beaten that dead horse enough I guess.


Given that you are disregarding all my contrary advice, how are you going to accomplish this?


First, we need a general algorithm.



Use time (for a given logon session) = Logoff time – logon time


Now, what about the cases where the user powers off the machine, or it bluescreens, or a token leak prevents the logoff event from being generated, etc.?  We can use the BEGIN_LOGOFF event to handle token leak cases.  We can use the shutdown event in cases where the user does not log off.  And in case of crashes, the only event we can use is the startup event.  Note that each of these introduces increasing levels of uncertainty.



Logoff time = (logoff time | begin_logoff time | shutdown time | startup time)


This is good, but what about the time the workstation was locked?



Workstation lock time = unlock time – lock time
Total workstation lock time (for a given logon session) = SUM(workstation lock time)


How about remote desktop & terminal server sessions, and fast user switching?  You can connect and disconnect from logon sessions, during which time the user technically isn’t using the computer.



Session idle time = session connect time – session disconnect time
Total session idle time (for a given logon session) = SUM(session idle time)


How about times when the machine was idle?  We can estimate that by looking at the time the screen saver was in place and adding the screen saver timeout.



Console idle time = (screen saver dismiss time – screen saver invoke time + screen saver delay)
Total console idle time = SUM(console idle time)


Putting all of this together and modifying our original formula, we get:




Use time (for a given logon session) =
   Logoff time – logon time
      – SUM(workstation lock time)
      – SUM(session idle time)
      – SUM(console idle time)


When we expand it, it is not quite so pretty: 




Use time (for a given logon session) =
   ( (logoff time | begin_logoff time | shutdown time | startup time) – logon time )
      – SUM(unlock time – lock time)
      – SUM(session connect time – session disconnect time)
      – SUM(screen saver dismiss time – screen saver invoke time + screen saver delay)


You have to be very careful that you only look at events that are properly contained chronologically between two other appropriate events, to avoid accidentally pairing the wrong logon and logoff events, or pairing a lock workstation event from one logon session with a different logon session.  The best correlation field is the Logon ID field, the next best are timestamp and user name.  At various times you need to examine all of these fields.


Now, which event IDs correspond to all of these real-world events?


They are all found in the Security event log.  The pre-Vista events (ID=5xx) all have event source=Security.  The Vista/WS08 events (ID=4xxx) all have event source=Microsoft-Windows-Security-Auditing.



512 / 4608  STARTUP
513 / 4609  SHUTDOWN
528 / 4624  LOGON
538 / 4634  LOGOFF
551 / 4647  BEGIN_LOGOFF
N/A / 4778  SESSION_RECONNECTED
N/A / 4779  SESSION_DISCONNECTED
N/A / 4800  WORKSTATION_LOCKED
* / 4801    WORKSTATION_UNLOCKED
N/A / 4802  SCREENSAVER_INVOKED
N/A / 4803  SCREENSAVER_DISMISSED

* prior to Windows Vista, there was no event for locking the workstation.  Unlocking the workstation generated a pair of events, a logon event and a logoff event (528/538) with logon type 7.  These events had the same user name as the “original” logon session and were completely enclosed chronologically by the logon/logoff events for the “real” logon session, but did not contain the Logon ID of the original logon session or other unambiguous correlator.  This makes correlation of these events difficult.


All of these events are generated in the Logon/Logoff audit policy category, although on Windows Vista and Windows Server 2008 they are scattered among the various subcategories in this audit policy category.  The audit event spreadsheet that Ned wrote has all the policy subcategory mappings as well as the event descriptions.


Sorry that this is more of a do-it-yourself than a solution-in-a-box, but this is pretty difficult to script and so far I haven’t worked on a project that required this.


Eric

Categories: HowTo, Rants, Tips Tags:

If you’re gonna herd bots, do it from New Zealand!

July 16th, 2008 Comments off

A judge in New Zealand declined to convict the admitted (guilty plea) botherder of a million-bot botnet, citing the negative consequences a conviction would have on the young man’s future prospects.  See the story here.


Well duh.  The whole theory of crime and punishment is that if you do something bad, you get punished, and punishment is something that is unpleasant, so you try to avoid it, hopefully by not doing the crime.  See?  One would hope that a judge would understand this concept.


I could understand if the judge said “this is just a stupid kid, he doesn’t deserve to do 20 years”, and gave the kid probation, community service and a big fine.  I don’t know if New Zealand has such options, or if the judge has latitude in sentencing.  There is probably more to the story than is being told.  But you don’t take over a million computers that don’t belong to you, personally making tens of thousands of dollars, and not realize that you’re doing something wrong.  Unless you’re a sociopath.  And in either case, you either need punishment (for doing something you know is wrong) or separation from society for the protection of society while you get treatment (if you are a sociopath).  So whatever the case, the judge got it wrong, and as a result is practically encouraging future behavior of the same sort.

Categories: Laws, Rants Tags:

If you’re gonna herd bots, do it from New Zealand!

July 16th, 2008 No comments

A judge in New Zealand declined to convict the admitted (guilty plea) botherder of a million-bot botnet, citing the negative consequences a conviction would have on the young man’s future prospects.  See the story here.


Well duh.  The whole theory of crime and punishment is that if you do something bad, you get punished, and punishment is something that is unpleasant, so you try to avoid it, hopefully by not doing the crime.  See?  One would hope that a judge would understand this concept.


I could understand if the judge said “this is just a stupid kid, he doesn’t deserve to do 20 years”, and gave the kid probation, community service and a big fine.  I don’t know if New Zealand has such options, or if the judge has latitude in sentencing.  There is probably more to the story than is being told.  But you don’t take over a million computers that don’t belong to you, personally making tens of thousands of dollars, and not realize that you’re doing something wrong.  Unless you’re a sociopath.  And in either case, you either need punishment (for doing something you know is wrong) or separation from society for the protection of society while you get treatment (if you are a sociopath).  So whatever the case, the judge got it wrong, and as a result is practically encouraging future behavior of the same sort.

Categories: Laws, Rants Tags:

If you’re gonna herd bots, do it from New Zealand!

July 16th, 2008 No comments

A judge in New Zealand declined to convict the admitted (guilty plea) botherder of a million-bot botnet, citing the negative consequences a conviction would have on the young man’s future prospects.  See the story here.


Well duh.  The whole theory of crime and punishment is that if you do something bad, you get punished, and punishment is something that is unpleasant, so you try to avoid it, hopefully by not doing the crime.  See?  One would hope that a judge would understand this concept.


I could understand if the judge said “this is just a stupid kid, he doesn’t deserve to do 20 years”, and gave the kid probation, community service and a big fine.  I don’t know if New Zealand has such options, or if the judge has latitude in sentencing.  There is probably more to the story than is being told.  But you don’t take over a million computers that don’t belong to you, personally making tens of thousands of dollars, and not realize that you’re doing something wrong.  Unless you’re a sociopath.  And in either case, you either need punishment (for doing something you know is wrong) or separation from society for the protection of society while you get treatment (if you are a sociopath).  So whatever the case, the judge got it wrong, and as a result is practically encouraging future behavior of the same sort.

Categories: Laws, Rants Tags:

German court bans retention of logged IP addresses

October 3rd, 2007 Comments off

A German court has ruled that a government web site may not retain IP addresses and other personally identifiable information (PII) in their logs for any longer than the user is actually using the site.


The judges pointed out that in many cases it was simple to map an IP address to an identity with the help of 3rd parties, and declared that logging IP addresses was a “violation of the right to informational self-determination.”


OK whatever.


Germany does not seem to be of one mind regarding logging.  On the one hand their draconian privacy laws (how’s that for an oxymoron?) are pretty much in opposition to any meaningful user activity logging.  On the other hand, their law enforcement folks at least seem to know the value of logs, even if they are a little draconian in the other direction.  Finally the article above notes that even the Bundestag, the lower house of the German Parliament, doesn’t comply with with the privacy laws that body created- the web site logs and retains PII.


Attention Germany: the privacy horse has left the barn.  Technology has far outpaced the capability of an individual to control where his or her information flows.  Expecting to both receive service from an online provider, and to remain “private” (whatever that means) from the provider, is unreasonable- and in fact denying the provider the right to log prevents the provider from systematically improving service to you.  Logging is a best practice for administrative activity, including maintenance-related activities, marketing & service planning, and security-related activities such as forensics.  Everything generates logs nowadays.  It would probably be better to write laws restricting what can be done with logs rather than to outlaw logging.  In this manner you could mitigate abuses such as those by the ambulance chasers but still provide organizations of all sorts, including the government itself, the information they need to do their jobs.


 

Categories: Laws, News, privacy, Rants Tags:

German court bans retention of logged IP addresses

October 3rd, 2007 No comments

A German court has ruled that a government web site may not retain IP addresses and other personally identifiable information (PII) in their logs for any longer than the user is actually using the site.


The judges pointed out that in many cases it was simple to map an IP address to an identity with the help of 3rd parties, and declared that logging IP addresses was a “violation of the right to informational self-determination.”


OK whatever.


Germany does not seem to be of one mind regarding logging.  On the one hand their draconian privacy laws (how’s that for an oxymoron?) are pretty much in opposition to any meaningful user activity logging.  On the other hand, their law enforcement folks at least seem to know the value of logs, even if they are a little draconian in the other direction.  Finally the article above notes that even the Bundestag, the lower house of the German Parliament, doesn’t comply with with the privacy laws that body created- the web site logs and retains PII.


Attention Germany: the privacy horse has left the barn.  Technology has far outpaced the capability of an individual to control where his or her information flows.  Expecting to both receive service from an online provider, and to remain “private” (whatever that means) from the provider, is unreasonable- and in fact denying the provider the right to log prevents the provider from systematically improving service to you.  Logging is a best practice for administrative activity, including maintenance-related activities, marketing & service planning, and security-related activities such as forensics.  Everything generates logs nowadays.  It would probably be better to write laws restricting what can be done with logs rather than to outlaw logging.  In this manner you could mitigate abuses such as those by the ambulance chasers but still provide organizations of all sorts, including the government itself, the information they need to do their jobs.


 

Categories: Laws, News, privacy, Rants Tags:

German court bans retention of logged IP addresses

October 3rd, 2007 No comments

A German court has ruled that a government web site may not retain IP addresses and other personally identifiable information (PII) in their logs for any longer than the user is actually using the site.


The judges pointed out that in many cases it was simple to map an IP address to an identity with the help of 3rd parties, and declared that logging IP addresses was a “violation of the right to informational self-determination.”


OK whatever.


Germany does not seem to be of one mind regarding logging.  On the one hand their draconian privacy laws (how’s that for an oxymoron?) are pretty much in opposition to any meaningful user activity logging.  On the other hand, their law enforcement folks at least seem to know the value of logs, even if they are a little draconian in the other direction.  Finally the article above notes that even the Bundestag, the lower house of the German Parliament, doesn’t comply with with the privacy laws that body created- the web site logs and retains PII.


Attention Germany: the privacy horse has left the barn.  Technology has far outpaced the capability of an individual to control where his or her information flows.  Expecting to both receive service from an online provider, and to remain “private” (whatever that means) from the provider, is unreasonable- and in fact denying the provider the right to log prevents the provider from systematically improving service to you.  Logging is a best practice for administrative activity, including maintenance-related activities, marketing & service planning, and security-related activities such as forensics.  Everything generates logs nowadays.  It would probably be better to write laws restricting what can be done with logs rather than to outlaw logging.  In this manner you could mitigate abuses such as those by the ambulance chasers but still provide organizations of all sorts, including the government itself, the information they need to do their jobs.


 

Categories: Laws, News, privacy, Rants Tags:

Voting Machine Logs + e-Government Laws = No Secrets When Voting

August 23rd, 2007 Comments off

Researchers in the state of Ohio in the United States have discovered that by analyzing the logs produced (by law) from e-voting machines used in certain counties, they can determine the vote(s) each voter made.  Further, the logs, by law, must be produced on demand, as part of our open elections process.


I haven’t read the in-depth reports and analysis.  It appears to me that the manufacturers of the voting machine anticipated the risk of vote correlation with voters and tried to mitigate it by separating the vote log from the voter log.  However they mitigated this very poorly as (1) only one voter can apparently use the machine at a time and (2) every thing the machine does is logged and (3) every log entry is timestamped.  So simply separating the “Voter X logged on” records into one log, and the “Vote cast for candidate Y” records into another log seems to be a pretty naive solution.


I normally try to stay away from politics and commentary on my blog, because I don’t want to alienate anyone.  But this is not a political issue.  Here in the United States we have problems with elections.  It doesn’t matter which party you are in, there are things to be unhappy about.  The machines we have built to make elections easier seem to have made things much harder- from the “hanging chads” we had in the 2000 elections to the current pain we’re having with voting machine certification.


The audit trail problem with voting machines is daunting.  How do you simultaneously accomplish the goals of (1) allowing only authorized individuals to vote (2) exactly once per election, regardless of location (4) the votes cannot be tampered with after being cast (or at least tampering is evident), (5) the votes can be tallied quickly (in a matter of only a few hours, (6) all of these steps can be accomplished in such a way that even if he voter wishes it, the vote cannot be correlated with the voter, and (5) a recount can reproduce all the same results with these same election characteristics (maybe we can relax the time window) without the voters physically being present.


Punch card and optical scan systems opt for auditing the voter before handing them the ballot, and the ballots themselves are the audit trail of the votes (and are not numerically linked with the voter).  These systems would seem to be pretty foolproof but there are systemic problems with both: the hanging chads and butterfly ballot problems were with punch card systems, and optical scan systems in general have a fairly high error rate, and all of these problems are largely due to users who fail to follow instructions which are critical to accurate operation of the machines which tally the votes.


Coupled with the fact that many e-voting systems are getting poor reviews from security researchers, I would be much more comfortable as a voter slowing down on e-voting until we work out the kinks.

Categories: News, Rants Tags: