I'm not quite sure what you mean with "redirect" rule.
There are two ways of publishing QVS, either with a Web Site Publishing Rule (requires tunneling as the protocol is HTTP or HTTPS), or you can create an Access Rule, which will simply do a port forwarding to a specific host and port.
As you're not using tunnelling, I assume you want to set up an Access Rule.
What you need to do first is to create a new User-Defined Protocol. This protocol (you can name it QVP for example) needs be configured with Inbound direction for TCP port 4747. Then you create an Access Rule using the defined protocol and adding the IP-no for the QVS server.
Attached is a word-document with some pictures that might be helpful.[View:http://community.qlik.com/cfs-file.ashx/__key/CommunityServer.Discussions.Components.Files/12/2548.ISA.doc:550:0]
Web Site Publishing rule requires that you configure your QVS to support tunneling. There are some info on the forums and there should also be a white-paper on how to install the ISAPI-dll if you're running IIS as your web server on the QVS-machine. After you verified that tunneling is enabled and working, you publish the server as any other web server using Web Site Publising Rule in ISA.
Which one is more secure depends on who you ask :) Some people think that forwarding TCP-ports opens the firewall for security threats. What they tend to forget is that it's not actually forwarding the port that is the threat, but the service behind it. If you publish a service with known issues, you can exploit it remotely if accessible. This is true, regardless of which protocol you're using to access the service.
If you tunnel over HTTP you will get some decrease in performance compared to native QVP-communication. The reason is that each package must be translated from QVP to HTTP and then back again. On the other hand ISA supports Web Proxy filtering on the HTTP-protocol, making it possible to scan the traffic, but this will put additional stress on the ISA, and you also need to make sure it's not filtering out packages that are required. I'm no expert on Web Proxy filtering, so if you want to utilize this you need to read up a bit on the pros and cons before deploying it.
I would say that forwarding TCP connections on port 4747 to the QVS is "secure" as I know no exploits for QVS as is today. Of course if you're aiming for a really secure environment QVS should be put on a segmented network in the DMZ, but configuring a DMZ properly is not something you do over a coffee-break ;)