Absolutely, slow compared to what? But, to identify long running queries, you can do one of two things. First, and usually best, set up a server-side trace to capture RPC:Complete and SQLBatch:Complete events. This should be captured to a file and then you can load it into a database, clean it, and run queries against it to identify the longest running procs. Another option, if the procs are currently in cache, is to use sys.dm_exec_query_stats DMO. This DMO has aggregate information about the queries in cache, so you can see the longest running, most frequently called, etc. You can also combine it with other DMOs to see the SQL being called and the execution plan used.
Slow compared to what? If you don't know what the normal execution time for a query is, you'll have trouble determining if it's running "slowly" To obtain query run times, you can set up a Profiler Trace to monitor query duration. You can then go through the results and look at queries that appear to be slow (by whatever measure you wish to apply). If you gather these execution times periodically and save the results, you will then have a performance baseline for your queries and can better establish what "slow" means in relation to normal execution times.
How deeply do you need to investigate? You can open Management-> Monitor from the SSMS GUI... Or right-click on the instance and drill down through Reports->Standard Reports->... There are a plethora of graphical reports there to get you started. You can run sp_who also. You can also use Windows Performance Monitor to grab some metrics. Until you have an idea of what you're trying to solve it is hard to predict the best tool for the job.