Firstly, if you're going to try to run ssh on a non-standard port to defeat your local IT policies (wrong-headed as I feel they are), it's normal to use 443 rather than 80. This is because http is often proxied by organisations; this proxying is often done transparently, so it can be difficult to tell if it's happening. HTTPS, by contrast, being end-to-end encrypted, is usually impossible to proxy, so most organisations either don't bother, or have a proxy configured as a simple pass-through. This makes TCP/443 a safer choice for a non-standard ssh than TCP/80. Joschi's suggestion of sslh, i notice, is designed to co-exist with https rather than http.
That said, ssh doesn't to the best of my knowledge support any kind of virtual host name support, so using ssh.work.com isn't going to work if that resolves to an IP address which is already running a real apache listener on TCP/443. If, however, you have a public IP address that you can spare for just this purpose on your work machine, you can configure sshd to run on port 443 with
sshd_config, and then just point a remote ssh client at your ip address with the
-p 443 flag.
If you can't spare an ip address for that, then sslh is your man.