Introduction - Protecting Vulnerable Populations … · Web viewThe Razor View Engine used by the...

System Security FeaturesBackground Check System

IT Technical Design GuideVersion 01

4/22/2015

Protecting Patients through Background Checks

Table of Contents

1 Introduction......................................................................................................................................... 4

2 Web Application Security................................................................................................................... 4

2.1 Authentication.............................................................................................................................. 4

2.2 Authorization................................................................................................................................ 6

2.3 Web-Specific Security Measures.................................................................................................7

3 Database Security............................................................................................................................... 9

3.1 Microsoft SQL Server................................................................................................................... 9

3.2 Data Encryption..........................................................................................................................10

3.3 Windows Communication Foundation (WCF) Web Service Security.........................................12

4 Criminal Justice Information Systems (CJIS) Data........................................................................12

4.1 Encrypted Tables....................................................................................................................... 12

4.2 CJIS-less Deployment................................................................................................................13

5 Auditing.............................................................................................................................................. 13

5.1 Created/Modified By................................................................................................................... 13

5.2 Logging...................................................................................................................................... 14

5.3 Data Log..................................................................................................................................... 14

5.4 Internet Information Services (IIS) Logging................................................................................14

5.5 SQL Server Logs and Auditing Database Design......................................................................15

6 Security Testing................................................................................................................................ 15

Appendix A – Authentication and Authorization Database Design Details........................................16

A.1 Users.......................................................................................................................................... 18

A.2 UserStatus................................................................................................................................. 20

A.3 UserType.................................................................................................................................... 21

A.4 Department................................................................................................................................ 21

A.5 UserDepartment.........................................................................................................................21

A.6 Provider...................................................................................................................................... 21

System Security Features of 28Version 01 | 4/22/2015 | IT Technical Design Guide | Audience: State IT Staff


A.7 UserProvider.............................................................................................................................. 22

A.8 Permission................................................................................................................................. 22

A.8 PermissionUserType.................................................................................................................. 23

A.9 Role............................................................................................................................................ 24

A.10 RolePermission..........................................................................................................................24

A.11 UserRole.................................................................................................................................... 24

A.12 PriorPassword............................................................................................................................ 25

A.13 Lookup....................................................................................................................................... 25

A.14 Configuration.............................................................................................................................. 26

Appendix B – Auditing Database Design Details..................................................................................27



1 IntroductionThe purpose of this document is to provide a high-level overview of the security features related to the Background Check System (BCS). Security features are divided into the following categories: Web Application Security, Database Security, Web Service Security, Sensitive Information, and Auditing.

The following is a list of Microsoft (MS) technologies related to or referenced by this document, with a link to the MS developer website for more information.

Microsoft AntiXSS Libraryhttp://msdn.microsoft.com/en-us/security/aa973814

Microsoft Enterprise Library Logging Application Blockhttps://msdn.microsoft.com/en-us/library/ff664569(v=pandp.50).aspx

2 Web Application SecurityThis section of the document details security related issues pertaining to the primary BCS web application.

2.1 AuthenticationUsers must be authenticated, the process of verifying a user’s identity, before they are authorized to use the BCS. The BCS supports the following methods of user authentication: Form-Based, Windows, Windows Identity Foundation, and Custom Single Sign-On.

2.1.1 Forms AuthenticationWhen forms-based authentication is utilized, users are managed directly in the BCS database. Users must login by entering a username and password on the BCS Login page. Administrators can create and manage user accounts. When forms authentication is utilized, the following password management features apply.

Password Storage - User passwords are stored in the database as SHA-512 encrypted hashes. The raw passwords are salted before being one-way hashed. This approach makes passwords unrecoverable and less prone to dictionary attacks.


https://msdn.microsoft.com/en-us/library/ff664569(v=pandp.50).aspx

http://msdn.microsoft.com/en-us/security/aa973814


Password Strength - The BCS supports a set of configurable rules controlling password strength:

o Minimum Length

o Maximum Length

o Mixed-Case Required

o Number Required

o Symbol Required

Password Expiration - The BCS supports configurable rules controlling how often users must change their passwords and when they can re-use a prior password.

Password Generation - When new user accounts are created, the associated passwords are generated based on the configured password rules. These passwords are sent directly to the new user. BCS administrators do not have access to another user’s password. Any generated password expires after one use and must be changed upon next login.

Password Recovery - When a user forgets his or her password, the user can reset it themselves if the account has not been locked. In order to reset a password, the user must correctly answer his or her security question.

Security Questions - Security questions are configurable. Users must select and answer a security question when first accessing the BCS. The responses to the security question are stored in the database as SHA-512 hashes, similar to passwords.

2.1.2 Windows AuthenticationUsers access the BCS via their Windows domain/machine account. If the user belongs to any domain roles that map to configured BCS roles, the user will be successfully authenticated. There is no explicit user login page in this case. Instead, the BCS must be provided (or be able to obtain) the following information when a user’s claims are passed through to the BCS:

Username

Role(s)

Associated provider(s)



2.1.3 Windows Identity Foundation (WIF)WIF is not directly supported in the BCS. However, since WIF is already used as the basis of single sign-on implementations for several states, it can be implemented without significant development effort if your state’s infrastructure supports or utilizes WIF.

2.1.4 Custom Single Sign-On (SSO)In this approach, users authenticate indirectly with the BCS via an external authentication store. To date, the BCS has supported the following custom, SSO approaches:

Client-provided Dynamic Link Library (DLL) wrapping underlying federated authentication methodology.

WIF + web service (for profile information and the end users license agreement]).

WIF + database membership provider (for roles and providers).

2.2 AuthorizationThe BCS utilizes a multifaceted approach to user authorization, the process of controlling what actions a user can perform in the BCS. The BCS uses the following criteria to determine what data users are authorized to view and what actions users can perform.

2.2.1 Authorization Criteria

DepartmentUsers belong to a single department and can only access data and functionality available to their department. Most BCS deployments are for a single department and the user’s department is easily inferred.

User TypeUsers are classified as a high-level type of user: State, Division, Provider, Service, or Applicant. The User Type controls what providers, divisions, roles, and permissions a user account can access. Furthermore, User Type controls high-level access to certain types of data, such as files and notes.

ProvidersUsers are associated with one or more providers (i.e., long term care employers) and can only access data specific to their providers.



DivisionsUsers can be associated with one or more divisions and can only access data related to their divisions. Most states will not utilize divisions, but it is another level of categorization available in the BCS to segregate provider users into groups with varying permissions.

RolesUsers are assigned one or more roles. Each user role is associated with a set of system permissions.

PermissionsUsers are granted permissions (via their roles) that control what data they can view, add, edit, and/or delete. Permission checks are checked and asserted throughout the application.

2.2.2 Permissions Authorize AttributesController actions are annotated with a custom PermissionAuthorize attribute. This attribute performs an authorization check for the specified permission(s) and will result in and log an exception if the current user’s session has expired or if the user lacks the necessary permission.

2.2.3 Authentication and Authorization Database Design DetailsThe details of the BCS database design that support the authentication and authorization processes can be found in Appendix A.

2.3 Web-Specific Security Measures

2.3.1 Unique ID ObfuscationThe BCS is designed to avoid passing unique identifiers (database primary keys) as query string parameters in a URL that a user can easily manipulate. Instead, many tables contain globally unique identifier (GUID) values that are used instead of the primary key. This prevents users from modifying a sequential number to see the other data. Furthermore, the BCS scrambles all GUIDs nightly in order to prevent users from bookmarking such pages or remembering particular ID values.

2.3.2 HTTP Action FiltersThe BCS annotates every controller action with an appropriate [HttpGet] or [HttpPost] action filter.



2.3.3 Response CachingThe BCS disables all response caching to avoid client browser or proxy server caching of potentially sensitive information or user sessions.

2.3.4 Transport SecurityFor user acceptance testing (UAT) and production deployments, the BCS website should be configured to require HTTPS/SSL.

2.3.5 Anti-Forgery TokensTo help prevent Cross-Site Request Forgery (CSRF) attacks, the BCS utilizes the ASP.NET Model-View-Controller (MVC) AntiForgeryToken. See the article accessed at the following URL for more information: http://www.asp.net/web-api/overview/security/preventing-cross-site-request-forgery-(csrf)-attacks

2.3.6 Request ValidationThe Microsoft ASP.NET MVC Framework automatically validates requests to protect against Cross-Site Scripting (XSS) attacks. If a request appears suspicious, an error results and the request is aborted.

2.3.7 HTML EncodingThe Razor View Engine used by the BCS for ASP.NET MVC development automatically HTML encodes text output, which helps mitigate XSS attacks.

2.3.8 Web.config EncryptionAdministrators are capable of encrypting sections of the web.config to protect sensitive information, such as database connection strings. However, we recommend using Windows Authentication to access SQL Server and keep web.config settings to a minimum.

2.3.9 SanitizationTo protect against XSS and SQL-Injection attacks, the BCS leverages the Microsoft Anti-Cross Site Scripting Library v4.2 accessed at: http://msdn.microsoft.com/en-us/security/aa973814.

With very few exceptions, all text input is sanitized before being saved to and retrieved from the database. This sanitization is performed in addition to the built-in request validation provided by the Microsoft ASP.NET MVC Framework to prevent XSS attacks.


http://msdn.microsoft.com/en-us/security/aa973814

http://www.asp.net/web-api/overview/security/preventing-cross-site-request-forgery-(csrf)-attacks


2.3.10 ValidationTo prevent bad (if not necessarily malicious) data from persisting in the database, the BCS performs several types of data validation. The MVC models are validated for persistence before being transformed into Data Transfer Objects (DTOs). The DTOs are validated before being passed to the Data Access Layer (DAL). These validation techniques apply to MVC Models as well as DTOs.

Attribute-based data annotations – Class fields are marked as required, having a maximum length, value ranges, and regular expression. Most validation attributes extend to the client browser and will be validated before they are submitted when a user performs actions in the user interface.

Explicit validation methods – Custom code to inspect and validate an object’s data, potentially against external data.

3 Database SecurityThe following sections detail security-related features pertaining to BCS databases.

3.1 Microsoft SQL ServerMicrosoft SQL Server 2008 R2 is the supported database platform for the BCS development and hosting. Microsoft SQL Server 2012 has been utilized successfully in the BCS installations by some States, but development and release of the system uses 2008 R2.

The following URLs access articles that provide more background on the security features that are native to SQL Server 2008 R2, including configuration and operational features that are not covered in this document:

SQL Server 2008 R2 - Security and Compliancehttp://www.microsoft.com/en-us/sqlserver/solutions-technologies/mission-critical-operations/security-and-compliance.aspx

SQL Server 2012 – Security and Compliancehttp://www.microsoft.com/en-us/sqlserver/solutions-technologies/mission-critical-operations/security-and-compliance.aspx

SQL Server Security and Protectionhttp://technet.microsoft.com/en-us/library/bb510589(v=sql.105).aspx


http://technet.microsoft.com/en-us/library/bb510589(v=sql.105).aspx

http://www.microsoft.com/en-us/sqlserver/solutions-technologies/mission-critical-operations/security-and-compliance.aspx





3.2 Data EncryptionSQL Server provides several methods for data encryption for data at rest. Articles that provide overviews of the various data encryption methods can be accessed at the following URLs:

http://technet.microsoft.com/en-us/library/cc278098(v=SQL.100).aspx

http://msdn.microsoft.com/en-us/library/bb510663(v=sql.105).aspx/css

3.2.1 Cell-Level EncryptionCell-level encryption provides the ability to encrypt specific database fields. Because cell-level encryption imposes certain development, administration, and performance costs, the BCS utilizes cell-level encryption for Criminal Justice Information System (CJIS) data only.

To protect encrypted data from whole-value substitutions, the BCS leverages authenticators. For more information, see: http://msdn.microsoft.com/en-us/library/ms365192(v=sql.105).aspx/css.

Cell-level encryption and CJIS implementation details are described further in section 4.

3.2.2 Full Database-Level EncryptionFull database-level encryption is provided by SQL Server Transparent Data Encryption (TDE) technology. The use of TDE is recommended for all UAT and production environments, but is not required for system operation. Full database-level encryption provides a second level of protection to data that is already protected through cell-level encryption.

3.2.3 Disk-Level EncryptionDisk-level encryption protects data at the file or volume level, but does not explicitly encrypt the database. Recent versions of Microsoft Windows also support the following disk encryption technologies which can enhance or replace the database-level encryption:

Encrypting File System (EFS) – File-Level Encryption

BitLocker Drive Encryption – Volume-Level Encryption


http://msdn.microsoft.com/en-us/library/ms365192(v=sql.105).aspx/css

http://msdn.microsoft.com/en-us/library/bb510663(v=sql.105).aspx/css

http://technet.microsoft.com/en-us/library/cc278098(v=SQL.100).aspx


3.2.4 Transport EncryptionSQL Server supports transport-level encryption via support for Secure Sockets Layer (SSL) and Internet Protocol Security (IPSec). SSL is the more widely used of these two options. An article that provides a quick overview of encrypting connections to SQL Server can be accessed at the following URL: http://technet.microsoft.com/en-us/library/ms189067(v=SQL.105).aspx.

3.2.5 Data Access Layer (DAL)The BCS DAL is implemented using Microsoft Entity Framework (EF) with supplemental stored-procedures and user-defined functions. The majority of database access is performed via Language Integrated Query (LINQ)-to-EF queries, although a few complex queries and reports are implemented through stored procedures. Both of these methods are strongly parameterized to prevent susceptibility to SQL injection attacks.

3.2.6 SQL Server Reporting Services (SSRS)Users do not have direct access to SSRS. Ad-hoc reports are generated via the ReportViewer control within the web application. PDF files are rendered server-side via the SSRS web service. All SSRS reports capture and log the username of the user generating the report.

3.2.7 Best PracticesA white paper describing several best practices related to SQL Server security in an operational environment can be accessed at the following URL. Each hosting organization is responsible for following the best practice guidelines.

http://download.microsoft.com/download/1/2/A/12ABE102-4427-4335-B989-5DA579A4D29D/SQL_Server_2008_R2_Security_Best_Practice_Whitepaper.docx




http://technet.microsoft.com/en-us/library/ms189067(v=SQL.105).aspx


3.3 Windows Communication Foundation (WCF) Web Service SecurityThe web services hosted by the BCS share the following security requirements:

Transport Security – requires HTTPS/SSL

Caller Authentication/Authorization – must be a valid BCS Service User with appropriate permissions to call the requested method

Further security measures can be configured based on the deployment environment:

Web Service Definition Language (WSDL) hiding

Firewalls

4 Criminal Justice Information Systems (CJIS) DataCJIS data refers to data that would be subject to audit by the FBI CJIS Division or equivalent State agency. This section describes how CJIS data is stored securely within the BCS.

4.1 Encrypted TablesThe following tables contain CJIS data and, thus, contain encrypted data fields:

DeterminationOffense

FileChunk

NoteEncrypted

LookupEncrypted



4.2 CJIS-less DeploymentThe code containing CJIS functionality is contained within class libraries that do not need to be deployed to all environments, such as a Provider-Only installation. The following DLL files are not included when doing a website publish from Microsoft Visual Studio (MSVS):

Bcs.Cjis.Dal.dll – for DAL Entity Framework models

Bcs.Cjis.Impl.dll – for queries and business logic

Bcs.Cjis.Log.dll – for logging

Bcs.Cjis.Sani.dll – for data sanitization

Bcs.Cjis.Val.dll – for validation

Bcs.Web.Mvc.Website.Bureaucrat.Controllers.dll – for MVC controllers

Bcs.Web.Mcs.Website.Bureaucrat.Models.dll – for MVC models

Additionally, the MVC user interface views related to CJIS data, such as rap sheets, can be deleted; they will not function without corresponding controllers and models.

5 AuditingThis section details the various auditing mechanisms leveraged by the BCS.

5.1 Created/Modified ByEvery table in the BCS database contains the following fields, which track who created/modified a record and when:

CreatedBy – username

CreatedOn – timestamp

ModifiedBy – username

ModifiedOn – timestamp



In most cases, the CreatedBy and ModifiedBy fields contain values that correspond to the record’s username field. However, not all BCS deployments utilize forms-based authentication and may not have corresponding records in the Users table. Additionally, some data was created during development and may contain a developer’s username. Finally, some processes create or modify data outside of a user session and may utilize a non-user username such as “TasksService.”

5.2 LoggingThe BCS leverages the Microsoft Enterprise Library Logging Application Block to provide explicit logging functionality. By default, critical errors and events are logged to the Windows Event Log and all errors and events are logged to the BCS Logging database. Examples of logged errors and events include:

Database saves and deletes

Web service requests/responses

System startup

User authentication

File downloads

CJIS data queries

Unauthenticated or unauthorized access attempts

Task service jobs

Unhandled exceptions

5.3 Data LogThe BCS database contains database triggers on all tables that record every insert, update, and delete to the DataLog table. This information is retained for a configurable amount of time before it is purged.

5.4 Internet Information Services (IIS) LoggingIIS logging should be enabled in the State production web farm in order to capture traffic to the website and web services.



5.5 SQL Server Logs and Auditing Database DesignSQL Server provides its own logging. The details of the BCS database design that support auditing can be found in Appendix B.

6 Security TestingAll BCS clients are provided full source code and encouraged to review it for potential security vulnerabilities. Additionally, certain states have performed more robust security tests, of which the resulting modifications have been incorporated into the core code model as appropriate. There are no currently known critical/high security issues, as these are fixed immediately upon knowledge of their existence.



Appendix A – Authentication and Authorization Database Design DetailsThe following image depicts the database model for tables related to user authentication and authorization in BCS deployments utilizing forms-based authentication.



The image below depicts the database model for tables related to user authorization in BCS deployments utilizing pass-through authentication. Notice the lack of the Users table and any table that references it.

Each of the database tables involved in BCS user management is described below



A.1 UsersThe Users table, shown in the image below, contains records corresponding to user accounts in systems utilizing forms-based authentication.

Table columns include:

UserId – Primary key, identity

UserGuid – Secondary key, GUID. Used by applications to hide raw UserId values.

UserName – Unique username used for authentication.

UserTypeId – Foreign key to UserType table. Specifies the type of user: State or Provider.

FirstName – The first name of the user.

LastName – The last name of the user.



Phone – The phone number of the user.

Email – The email address of the user, which is required for password distribution.

PasswordHash – One-way cryptographically hashed (unrecoverable) user password .

PasswordSalt – Additional cryptographically generated text that augments a user’s raw password before it is hashed to prevent dictionary attacks. If this value is null, then PasswordHash is assumed to contain a raw plain-text password.

PasswordExpirationDate – Determines when a user must change their current password.

PasswordChangedOn – Tracks the last time the user’s password was changed.

LastLoginDate – Tracks the last time the user logged into the system.

FailedLogins – Tracks the sequential failed logins so the account can be automatically locked when the number of failed logins exceeds a configurable amount.

UserStatusId – Foreign key to UserStatus table. Specifies the user account as Enabled, Locked, or Disabled.

SecurityQuestionId – Foreign key to Lookup. The security question the user chose to answer.

SecurityAnswerHash – One-way cryptographically hashed (unrecoverable) answer to the chosen security question. This is used in the password reset process.



A.2 UserStatusThe UserStatus table, shown in the image below, defines the supported set of user statuses.


UserStatusId – Primary key. Non-identity, since application code relies on these constants.

o Enabled – Users can login.

o Locked – Users cannot login; they failed to enter the correct password too many times.

o Disabled – Users cannot login; an administrator has explicitly disabled their account.

Name – Label of the user status.

Sort Order – Controls the display order in user interfaces.



A.3 UserTypeThe UserType table, shown in the image below, defines the supported set of user types, of which a user can belong to only one. The UserType table also helps manage what permissions are available to roles, since provider users should never be granted permissions intended solely for state users. The BCS applications avoid testing a user’s UserType directly and rely on related permission checks instead.


UserTypeId – Primary key. Non-identity, since application code relies on these constants.

o State – Users that access the BCS on behalf of the state agency administering the background check program.

o Provider – Users that access the BCS on behalf of one or more healthcare providers.

o Service – A system user type that implements automated technical tasks. (Not shown in image)

Code – Text description of the user type.

A.4 DepartmentThe Department table contains all of the departments supported by a particular BCS deployment (typically only one). Most BCS database tables eventually tie back to a specific department.

A.5 UserDepartmentThe UserDepartment table is a join-table that maps a user to a department. The BCS assumes that one user belongs to one and only one department.

A.6 ProviderThe Provider table contains all of the supported providers with each mapped to their specific department.



A.7 UserProviderThe UserProvider table is a join-table that maps a user to his or her associated providers. This table is typically used only for provider users, since state users generally have a special permission that grants them access to all of their department’s providers.

A.8 PermissionThe Permission table, shown in the image below, contains all of the distinct permissions that are checked throughout the application to authorize a user to view or perform certain actions.


PermissionId – Primary key, non-identity since the application code relies on these constants.

ParentPermissionId – Foreign key to permission; defines the permission as part of a hierarchy where permissions can only be granted in conjunction with all parent permissions.

Name – Label for the permission.

Description – Describes the permission.

SortOrder – Controls the display order in user interfaces.



The image below shows a small sample of records in the Permission table.

A.8 PermissionUserTypeThe PermissionUserType table is a join-table that maps permissions to the UserTypes that can be granted the permission. For example, this table will prevent a provider user from being granted a permission that allows users to make a fitness eligibility determination, which is a permission reserved strictly for state users.



A.9 RoleThe Role table is shown below:


RoleId – Primary key; identity.

Name – Label of the role.

DepartmentId – Foreign key; the department associated with this role.

UserTypeId – Foreign key; the user type associated with this role.

A.10 RolePermissionThe RolePermission table is a join-table that associates a role to all of the permissions that it grants when a user is assigned the role.

A.11 UserRoleThe UserRole table is a join-table that maps a user to each role to which the user is assigned. Users can be assigned multiple roles and will be granted all permissions for all roles assigned.



A.12 PriorPasswordThe PriorPassword table shown below contains a history of each user’s previous passwords. This table is updated whenever a user’s password is changed and is used to prevent a user from reusing prior passwords.

A.13 LookupThe Lookup table shown below is a general-purpose set of records used throughout the application.

In regards to security, the Lookup table is used to store the set of supported security questions a user can select and answer.



A.14 ConfigurationThe Configuration table contains several settings related to security. These are shown in the image below.

Configuration settings related to security are:

AuthMaxFailedLogins – Number of failed authentication attempts before the user account status is set to “Locked.”

AuthPasswordExipresDays – Number of days until a user must specify a new password.

AuthPasswordLengthMax – Maximum length of a password.

AuthPasswordLengthMin – Minimum length of a password.

AuthPasswordMixedCaseRequired – If “True,” passwords must contain both upper and lower case letters.

AuthPasswordNumberRequired – If “True,” passwords must contain a numeric character.

AuthPasswordSymbolRequired – If “True,” passwords must contain a symbol.



Appendix B – Auditing Database Design DetailsThe BCS database tracks changes to individual field values using triggers that write tracked changes to the DataLog table, which is shown in the image below.

The following image provides an example of the contents of the DataLog table.


Introduction - Protecting Vulnerable Populations … · Web viewThe Razor View Engine used by the...

Documents

Transcript of Introduction - Protecting Vulnerable Populations … · Web viewThe Razor View Engine used by the...