Is Entity Framework with LINQ compliant with this STIG?

Question

I am working on a project for DoD by using Microsoft's MVC and all other related technologies. For the security purpose, I have to follow the Security Technical Implementation Guide (STIG).

In version 3, Release 9, section 3.10.1, it indicates

Allow access to the database through views no directly to underlying tables in the database.

and

(APP3540.4: CAT II) The Designer will ensure the application does not directly access the tables in a database.

Can I use Entity Framework with LINQ?

Answer 1

Well, that's one way to prevent SQL injection, I suppose, but man, leave it to the U.S. Government to apply asinine rules to what should be simple things.

The restriction basically requires the website to be readonly. Presumably, this applies only to public-facing properties, so you could still allow direct access to the database on an internal application (otherwise, I have no idea how you would actually ever persist anything). Regardless, Entity Framework can handle this easily. As far as using views go, you don't really need to do much special. If you use Code First with an existing database and name your views such that they follow EF conventions (pluralized versions of the entity names), then you wouldn't have to really do anything special.

To make EF function with an existing database you just have to modify the constructor of your DbContext subclass to 1) reference the connection string explicitly and 2) disable the initializer:

public class ApplicationContext : DbContext
{
    public ApplicationContext()
        : base("ConnectionStringName")
    {
        Database.SetInitializer<ApplicationContext>(null);
    }

    // DbSets here
} 

If your view names don't line up with EF conventions, then you can explicitly state what your entity should reference:

[Table("awesomefooview")]
public class Foo
{
    ...
}

Technically, you'll still have Entity Framework API methods that allow write, but since the backing is a view, these will raise exceptions if run. If you can do something like run a stored procedure to make changes, which sort of indirectly allows write access, but technically the application itself isn't touching the database, then you can also make Entity Framework use these. See Code First Insert/Update/Delete Stored Procedures for more information (unfortunately, only EF6 and up, though).