It depends
For the most part, the nature of the software will govern the kind of automation that you can use. The development methodology is, in my experience, secondary - the main difference I've seen between working agile and working waterfall is that everyone tends to work with smaller slices of functionality in an agile environment where a waterfall environment tends to deliver anything from a module to a complete application in one big chunk.
That said, in your position I'd be looking at specification documents as soon as you have access to them. These will help you to decide what areas of the project are best suited for regression automation, where you might want to focus for any load or stress testing, and even whether you want to build a setup automation suite.
The biggest difference the methodology makes in my opinion is that there's a tendency to hand a supposedly complete piece of code over for testing in a waterfall environment, which can make testing - and consequently automation - challenging because fixes usually take longer to be implemented and you may need some interesting workarounds. There could also be less testability built into the software (this isn't a given, but I've found it's more likely to happen in a waterfall environment than in an agile environment).
Other than that, you're likely to have a more or less hard deadline to work against, which will mean that any delays you encounter will mean less time for other things.
As long as you work with the nature of the software you're testing, you should be fine.
