This first thing is more of a suggestion than a fix -- don't put your interface in NAT mode. Go to the interface and put it into route mode. Then go to the Trust -> Untrust policy page, select your any/any/any policy, and click Advanced, and put the rule into Source Nat mode. When you click apply, and save, then the icon for the rule should turn blue. (Why do this? Well it makes it clear on the policy page that NAT is happening. It also gives you the flexibility to do non-NATing through the firewall should you desire.)
Second. Your 'untrust' address is 192.168.200.x/24 -- that looks like a reserved IP. Can you ping the firewall's untrust gateway of 192.168.200.1? Are you sure the /24 is the correct mask size? Can you set a system on the "untrust" network with those parameters and get connectivity to the internet? Can you figure out what the next-hop IP is after the default gateway is, and get to that?
Third. You don't seem to have DNS set as a DHCP option, so your DHCP clients don't get a DNS server. Is that intentional?
Fourth. You don't need policy 2 unless IPs from the "untrust" side will be initiating connections to the Trust side. With policy 1, the traffic that flows back to the trust side is implied permitted as associated.
Fifth. You shouldn't need the Trust -> Trust rule unless you have multiple security zones marked as Trust (which you don't).
Sixth. You seem to be doing all your management via the untrust interface. This might be what you want, but it looks backwards to me, permitting the untrust network access to your management.
Best Answer
Nope, you get to set up a port mirror on the switch the SSG is connected to and from there you can sniff, ntop, tcpdump, wireshark, or nfsen as you'd like.