What does a security pro need to know about Code Access Security (CAS)?
Honestly I would say not a whole lot; until you need to know about it.
Why have these security features been removed from .NET 4.0?
Because the security was complicating, leading to questions like this. It was also an incomplete solution since it was only .NET applications that had this functionality. Take for example, that a .NET Executable run over a network share would run in medium trust. Medium trust would prevent access to a lot of functionality, but it was done in the name of security. It however, did have its flaws.
Native EXEs did not behave this way. If someone was going to write a malicious executable, they probably wouldn't opt to do it .NET. A native executable does not behave differently when run over a network share. However, it did stop a very "cheap-and-simple" means of network applications being useful.
Administering it was downright confusing. Between Code Groups, zones, Strong Names, Application Identity, and permission sets, a lot needed to be known for something that didn't provide enough security.
The concept was born before UAC and AppLocker, where people that were Administrators always had administrative permissions. UAC goes much deeper than a .NET application, it's at the operating system level.
How do we secure .NET 4.0 apps?
Your real goal isn't "to secure .NET apps" but "to secure all apps". AppLocker or SRP are more effective because they apply to any application. .NET, Java, Native, etc.
Additionally, by restricting the user's permission, not the application. Creating a policy application-by-application takes great effort, and even more difficult when you need to start creating exceptions for certain users.
That isn't to say that .NET 4.0 doesn't have a security model at all. .NET 4.0's replacement is Security Transparency, and "hosted" applications like Silverlight, ClickOnce, etc still have CAS-like permission sets applied to them.
Security Transparency relies more on a grant set provided by a sandbox. Take for example, Silverlight. Silverlight will give a different grant-set depending on whether the application is running in-browser (Medium Trust), or out-of-browser, which can have Full Trust. Running out-of-browser takes a users approval to do so, and even then it is restricted by things at the operating system level.
It's up to the developer to know what permission sets he has depending on which sandbox his application is running on. In effect, .NET 4 applications get the same "sandbox" as native applications. Silverlight, ClickOnce, etc get their own sandbox that have greater restrictions.
