DICOM C-GET vs C-MOVE

The point is not only about security, but about implementation.

In C-MOVE, the SCP list the supported transfer syntaxes for each image matching the previous query. Then the SCU agree with any.

On the other side, in the C-GET, the SCU list its supporting transfer syntaxes before any query is made, and the SCP has to pick any and compromise to send whatever the SCU ask for in that format.

So, the C-GET implementation for PACS is harder and more complex since it has to be able to encode anything to anything. While in the C-MOVE is the client who has to be able to decode and show anything which is much easier...

You can use either, but the preferred is C-Move.

There are two reasons for this.

1. With C-Move you can also request sending images from one AET to some other AET. This is not possible if you only have C-Get. With C-Move, C-Get becomes redundant.
2. IT security issues. With C-Get, the client opens a random inbound port to receive images. C-Move involves two associations with the second association being a C-Store from server to client. C-Store happens over well defined server port and is more trusted by the IT support.

As @NathanWheeler said in comments:

In security terms, a C-GET is as secure as retrieving your email... anyone can do it from anywhere if they have your username and password. A C-MOVE requires that the server recognizes YOUR COMPUTER as an authorized machine to receive information, so without explicit access, even if you have all the information to QUERY the server, you still can't retrieve anything. You CAN implement "promiscuous" mode, where if the DestinationAE isn't recognized, it sends the requested information back to the caller, but it's highly discouraged.