Home Forums Discussions Meaningful Use Core Measure 15: Security Risk Analysis

How are people complying with Core Measure 15: Security Risk Analysis? Do you hire third party to do the analysis? Or do you have a template and do it on your own? What analysis will withstand the audit?

Wing and a prayer.

A while back I believe it was Sandeep who posted a link for meeting Core 15 using a self-assessment tool. That's how I met the requirement.
http://www.texmed.org/WorkArea/DownloadAsset.aspx?id=25071
However, I agree with Tom as to the best way to withstanding an audit.

Yep that's the one. The main thing is that they want you to document what information processes PHI and whether not it's vulnerable. It can help people identify some obvious risks that they previously thought were not so obvious. If we're going by AC standards, most professional security risk "analyzers" should note that allowing Everyone on the shared permissions is a big security risk since it requires only physical access to the network to compromise the data.

Also buying a server (Active Directory) and adding Everyone to the permissions list just really defeats the point of having a server.

Thank you Sandeep.

That spreadsheet is very complicated. Do you have to answer all the questions on that? Some of the things are very subjective, like "VERY LIKELY " and "MEDIUM" and "LOW" etc.

And what practical solution do you propose for setting permissions?

It seems complicated but it just takes a long time to fill out. There are some subjective portions that require to assess the possibility of certain events. (e.g. a break in). Whether or not things like disk encryption are necessary. Disk encryption just protects physical theft for example.

You can just recycle it for the following years. Usually you want to reduce the number of risks each year.


You can grant users access individually using Shared Folders feature in the SBS console, but a better way would be to use the Security Groups feature of the console.

You can make a group called AC Users and grant them full permissions to the folder.

Hate finding an "Everyone" permissions folder; delete it from permissions when I find it. Agree with Sandeep about using Active Directory to manage the permissions on the folder if there is a DC.

For folks running a non-server environment, create an "acuser", give it permissions on the share, then use those credentials to mount the share from every other machine. GTG

Indy,
For us non-servers, can you translate your method above into non-technical lingo with instructions for us to follow?

Donna,

On the machine that is serving AC, create a non-administrate/standard/limited user named acuser. Give it a decently complex password.

You go the AC folder, right click to get to the properties.

One of the Tabs should be Sharing. Go into the Sharing Tab, and if Everyone is in the list remove it. Select/Add the user acuser. Give acuser full control (permissions) on the directory.

Now go to each machine that connects to the ac server, and map that AC folder as a network drive. When it asks for you to login to that folder, make the user acuser, and click the check-box that says to reconnect at login.

If there is interest, I can go through this in more detail with screen shots.

BTW Donna, great to hear you are joining us in San Diego!

Thanks, Indy, that clarifies it. I did not understand "mount the share". I think mine are set to everyone, so I'll see about changing it.

Looking forward to our next meetup!

SanjeevP,

I practice in Maine, and our REC gave us that same exact spreadsheet.
Yes, it's complicated.
Yes, it takes a long time to fill it out the first time.
However you can update it and use the same spreadsheet in subsequent years of MU attestation.

If you want to survive a CMS audit when they came knocking on your door three years later asking for the money back, I would STRONGLY suggest that you complete it. I have this spread sheet for each of the THREE years that I've attested to MU (2011, 2012, and 2013).

Simply having passwords on your server and in AC will definitely NOT sustain audit.
Sorry for the hard truth, but I'm passing along both what i've researched from CMS and the REC in Maine.
Please be careful attesting to this requirement, it's the most complicated of all.
Remember it's an INVENTORY, it's not a requirement of compliance. You have to identify the status of potential security breaches. You don't actually have to fix them, but you need a plan in order to address the deficiencies even if you don't actually fix the deficiencies. that being said, if you identify deficiencies you really SHOULD fix them to prevent a violation of HIPAA and the revisions to security passed in the HITECH act (OMNIBUS ruling).
sincerely,
Adam

Thanks!