Rather than using -1 to signify that you don't know or don't care, how about just using Null for that? Pretty much what it was made for. Then you could switch to a Bit rather than an Int.
Also, I'm sure TomTom will disagree, but I think using a CASE statement is the way to go for this stuff.
Your mileage may vary, but it seems that the query engine handles it a lot better than wrapping things in IsNull or having multiple OR statements, which can get rather messy as you start adding other conditions.
No matter which way you go, the execution plan is going to suffer a little bit depending on what you're passing in, but it shouldn't be TOO horrible.
The extra benefit of going with CASE statements is that you can add a bit of complexity without much extra code (versus going with a bunch of OR statements). Also, the first condition to match your criteria can prevent the extra evaluations, which isn't always the case when dealing with OR's...
So, for 8 optional parameters with -1 as the value use to ignore the search, what you end up with is something along the lines of:
WHERE
@Search1 = CASE WHEN @Search1 = -1 THEN @Search1 ELSE @Column1 END
AND @Search2 = CASE WHEN @Search2 = -1 THEN @Search1 ELSE @Column2 END
AND @Search3 = CASE WHEN @Search3 = -1 THEN @Search1 ELSE @Column3 END
AND @Search4 = CASE WHEN @Search4 = -1 THEN @Search1 ELSE @Column4 END
AND @Search5 = CASE WHEN @Search5 = -1 THEN @Search1 ELSE @Column5 END
AND @Search6 = CASE WHEN @Search6 = -1 THEN @Search1 ELSE @Column6 END
AND @Search7 = CASE WHEN @Search7 = -1 THEN @Search1 ELSE @Column7 END
AND @Search8 = CASE WHEN @Search8 = -1 THEN @Search1 ELSE @Column8 END
NOTE: As KM pointed out, the NULL method falls short if the columns you're working will can potentially have NULL values, since NULL=NULL won't evaluate properly. So, for fun, I changed my answer back to what the original poster requested, which is to use their own identifier for skipping the search.