You have three problems:
The actual events may be brief, but they may also suffer "contact bounce" in which what a human would consider one event actually consistent of many unique electrical make/break events, which should not all be counted.
You need to logically "AND" the button and the continuity test to detect points, but due to bounce they may not actually be simultaneous, so you'll need to look for correspondence within a small window of time.
You need to get the data into a computer via USB.
I think the simplest (and most tunable) environment in which to implement the decisioning of the first two tasks would be software running on an embedded microcontroller. And the simplest way to get events into a computer over USB is virtual serial port.
Therefore, the solution I would recommend is a small amount of custom software, experimentally developed for a cheap embedded board which has a USB-serial communication channel back to the computer.
The most well known such candidate would be an Arduino or equivalent. However, there are additional options - if you want to program in C# everywhere there is the Netduino. If you'd like to dig more into the underlying implementation details, ST offers some $10 class "discovery" eval boards. In reality almost every chip maker has something in the way of a cheap demonstration or evaluation board for at least one of their USB-capable chips on the market.
If this will be your first project of this sort, you'll probably find a greater variety of immediately applicable support resources for the Arduino than for anything else.
Now that I think of it, there is one alternative software organization on the same hardware which might make more sense for you. Instead of doing decisioning, you could have the embedded board run in a tight loop, reading an 8-bit digital port (up to two pairs of fencers) and outputting that value over serial. An interrupt (or on an Arduino UNO the baud rate of the serial port itself if run in bare bones mode rather than using the buffered API) can be used as a timing source to regularize the measurements. For example, at 115200 baud you would get on the order to 10,000 samples per second - likely insuring that any event will be sampled at least once. You could then write software on the desktop which would parse this stream of data, looking for button and continuity event groups which coincide. Personally, I'd prefer to do that on the embedded board and make the system self contained, but doing it on the desktop might make it easier for you to experiment with the grouping algorithm, visually plot the signal bounce (to an imperfect degree) let you put in sliders for tuning the tolerances, etc. Really it's a matter of your preference.