Quality Testing

Quality is delighting customers

Hippa Complians Check list for Security Testing(Medical Projects)

Activity to be checked

Recommendations

HIPPA Compliance Checklist

Verify the Authentication to the application / web server.

Windows Authentication via domain users with clients using user credentials(Single User, Single Login, No DB Saved)

Verify that anonymous user access is permitted only if a user access application not in the domain.

Only If client does not support passing credentials.

Non-Domain user

Verify that User passwords is encrypted (hashed with salt) before being stored in the database using SHA-1 algorithm (FIPS compliant)

 

It is recommended that a separate Salt column be stored in the database for each password preferably in a different table than where the password is stored so
that if the Users table is compromised, the salt values are not immediately
known. This salt value would be unique for each user and used in the
encryption algorithm.

 

Verify that medical information is encrypted when sent to network or stored in database.

 

·    Secure Sockets Layer (SSL, 128-bit encryption) is recommended for secure
communication to the browsers when requesting any patient-related information.

·    Test Certificates for development purposes can be used / Actual Certificates to be
purchased.

Verify that login information of a user is encrypted.

·    Secure Sockets Layer (SSL, 128-bit encryption) is recommended for secure
communication to the browsers when a browser submits the user login
credentials.

·    Test Certificates for development purposes can be used / Actual Certificates to be
purchased.

Verify that User passwords is strong and contains at least eight characters long containing at least one uppercase letter, one lowercase letter one number and
one symbol.

 

For Example: Pass@word!341

·    Minimum Length of Password: 8

·    Frequency of Password Change

·    Use letters, punctuation, symbols, and numbers for password

Verify that database connection string does not specify any username/password information.

For Example:

Integrated Security = SSPI

 

Verify that users have no access to directly Update, Insert or Delete records in database.

·    Always use Update, Insert or Delete statements within the stored procedure.

·    Only allow execute on Stored Procedures and Select statement in code / web server
level.

Verify that If the impersonation section of the Web.Config is used to specify impersonation information, it should be encrypted using
the

DataProtectionConfigurationProvider

or

RSAProtectedConfigurationProvider

 

 

Always use ADO.NET command parameters in SQL statements issued from the web server to mitigate against SQL-Injection attacks

Do not concatenate strings parameters.

For Example:

SELECT * FROM User WHERE username =  ‘+ <Login Name Here> + ‘ and password =  ‘+ <Password Here> + ‘

Verify that database have functionality of auditing.

·    Auditing is necessary to identify any security breaches.

·    Third Party auditing solutions can be used.

·    Changes made in any table of the database must be recorded / logged as per column
level. But this may create a performance issue.

·    The deletions will also need to be associated with a user identity.

For Example: Modified By, ModifiedDate etc.

·    Triggers can be used to log changes to only auditing columns

Verify that users are periodically forced to change their password either by the application or by a standard operating procedure.

 

For Example: Any Note / Message on the Login page like:

·    ‘Change your password periodically after 15 days’

·    Implement the password policy.

Verify that system requires the user to re-login after a specific period of inactivity.

·    This can be handled as a standard operating procedure (patient data should not
remain on an unattended computer screen) and as an application function.

·    Windows based clients can use a timer to require the user to re-verify their
password.

·    Web based clients can use forms authentication ticket timeout that redirects to
the Log In page again after a period of time. This can be specified in the Web.Config file with the timeout
property.

<authentication mode="Forms">

<forms loginUrl="Login.aspx"

cookieless="UseCookies"
name="RegistryAuth"

timeout="60"

path="/" />

</authentication>

Page Expires after 60 mins & re-directed to Login.aspx

Verify that security context of the server components is least privileged.

Setup specific least privileged user domain account that component impersonate to connect to DB server.

Verify that SQL-Server Security is turned off.

·    Always use windows authentication to connect to the database server.

Or

·    Create an admin account with strong password &” remove sa user.

Verify that sensitive sections of Web.Config file are encrypted.

By default Web.Config will be accessible to administrators only.

 

Views: 14

Comment

You need to be a member of Quality Testing to add comments!

Join Quality Testing

TTWT Magazine

Advertisement

You Can


Call for Articles

Advertisement

Videos

  • Add Videos
  • View All

Badge

Loading…

© 2012   Created by Quality Testing.

Badges  |  Report an Issue  |  Terms of Service