What makes a good security test case?

It traces to one specific requirement, gives reproducible steps, and states an exact expected outcome that can clearly pass or fail.

• Good: the requirement is that the Windows Firewall blocks all inbound and outbound connections. The test case verifies that it does so by default. The steps are to open the advanced firewall settings, public profile, and check the defaults. The expected outcome is that both are set to "Block all". Anyone can repeat it and get the same verdict.
• Bad: "Verify system hardening", expected outcome "settings as recommended by standard XYZ". It inherits the vagueness of a bad requirement ("shall be hardened according to XYZ"). The tester has to interpret a whole standard, and two testers will disagree.
• Ugly: "Verify that encryption works", expected "encryption works as expected". It names no algorithm, key length or interface and has no traceable requirement, so it cannot fail.

Most bad test cases start as bad requirements. A test can only be as precise as the requirement it traces to.