dive insurance

joshua berman: hello, everyone. thank youfor joining us for today's webinar, "hipaa and encryption: the best practices." my nameis josh berman and i'm the senior marketing coordinator for onramp. i'll be the moderatorfor today's presentation. in this webinar, we will cover the following: understandinghipaa's take on the topic of encryption, discussing the challenges of encrypting data in transitand at rest, using nist guidelines as a standard for encryption, and best practices for accuratelydeploying and maintaining encryption. our goal is to keep the webinar to as closeto 40 minutes as possible. to keep things moving, we will answer all questions at theend of the presentation. please feel free to submit your questions via the chat windowthroughout the webinar and we will answer

all that we can during our q&a session.leading this discussion, i have with me today chad kissinger, founder of onramp. since startingonramp in 1994, as one of texas' first isps, chad has led the growth and development ofthe company into a leading high-security and hybrid hosting provider, serving businessesin the health care, financial services, and other industries in meeting their it and complianceneeds. alongside chad, we have jeremiah martin, seniorengineer at onramp. jeremiah is a senior it professional with over 15 years of consultingexperience in it security, audit compliance, and project management, with extensive workwithin the hipaa, pci, sox, and nist frameworks. gentlemen, thank you both for taking the timeto talk with us today. and now, jeremiah,

i would lie to pass the conversation overto you. jeremiah martin: thanks, josh. yeah, i think,today, what we're discussing is just the need for encryption and then the change in thelandscape that we've seen. over the years, we've had a shift. a lot of times, most peopleare going after credit card data or something that can financially make them secure. we'veseen a shift, of course, due to computing needs. we're in a cloud world. we've got morevirtual machines out there. i'd like to make a note of the recent trend taking shape inthe health care industry. as many of you are probably aware, in early may, the ponemoninstitute released its 5th annual privacy and security report. in this report, it isrevealed that criminal attacks have exceeded

lost or stolen computing devices. so whatwe're seeing is more pulling stuff in transition versus actually breaching actual servers,stealing actual laptops, stuff like that. this trend speaks volumes regarding the evolvingsecurity climate and in relation to today's topic, it emphasizes the need for encryptingdata in transit and at rest. and we'll talk about what to do in that transition periodand give some cause for applying encryption practices that go above and beyond hipaa standardstoday. before we get too far ahead of ourselves, i think it'd be best to pass things over tochad to discuss hipaa's take on encryption. chad kissinger: thank you, jeremiah. it'svery interesting. i find that interesting that criminal attack is now overtaking theloss of media as the big one. in the past,

the big thing that we would see is laptopsbeing lost, and now we're seeing hackers getting on to servers and encryption is obviouslyincreasingly important. but obviously, today's topic is about best practices with hipaa encryption,and the obvious first best practice is to understand what hipaa says about encryption.real quickly, as most of you know, or those of you that have been involved with hipaa,hipaa has three general rules that talk about what you have to do. one is the privacy rule,which in my words just generally says what data is sensitive, and who can see it andwho can't and what are the rights of the patient to interact with that data.and there's a security rule, which is primarily involved in the administrative, physical,and technical measures that you have to take

to protect the confidentiality, availabilityand integrity, or the privacy, the up time, and the accuracy of the data. so that's asecurity rule. and then there's a breach notification rule, which talks about what you have to doif the privacy rule is broken, if the security rule fails. and the security rule, the privacyrule really doesn't talk about encryption a lot, but the security rule and the breachnotification rule do and they do in an interesting way.first of all, hipaa's security rule has these things called implementation specificationsand implementation standards that are either addressable or required in their implementation- you have to either do them or think about them basically - and they've split up theencryption requirements under hipaa into two

groups. one is encryption requirements fordata that's at rest or not moving. that's data that's on hard drive or on usbkey or something like that, or on a laptop. and then encryption standards for data that'sin transit, the data that's moving and being transmitted across the internet or acrossa network. and the standards for data at rest are addressable and the standards for protecteddata in transit are required. and what addressable means, under hipaa, is that the person that'sexamining the compliance of the data has to consider whether it's reasonable and appropriateto encrypt the data, and usually, it's appropriate. in our business here at onramp, we see thatit's pretty much always appropriate to encrypt the data, but sometimes, it may not be reasonable.and the instances where we see that is when

we have customers with special applicationsthat are trying to insert or read from databases very quickly. or they have some particulardifficulty in their particular instance that makes it not necessarily reasonable to dothe encryption on a server that's not going to move out of the data center or out of aprotected area or something like that. so in that instance, the fact that the standardsand addressable standard says that's okay, they don't have to do encryption. but theymust, if they don't do it, if they find that it's not reasonable or appropriate, they haveto document their thinking about why that's not reasonable or appropriate. and they haveto consider alternate measures that they can do that would reduce the risk associated withnot encrypting the data, and do those measures

if those are reasonable and appropriate. soencryption of data at rest under hipaa is addressable, encryption for data in transitacross unsecured networks - that would be the internet, or any network where somebodythat's unauthorized by the privacy rule to see the data might be - is absolutely required.you have to do it. so that's the first requirements under hipaa.under the security rule, it very simply says "encryption for data at rest is addressable."you need to do it if it's reasonable and appropriate, and if not, you need to do something elseto protect it if it's reasonable and appropriate. and encryption for data in transit is absolutelyrequired. now, what does that mean, though? and is therea standard for how strong the encryption needs

to be and how you need to perform the encryption,and actually there is. and that requirement is talked about in the breach notificationrule. and this is often missed by people that are trying to be compliant and have gone toa lot of effort to be compliant because it doesn't say the requirement right in the breachnotification rule. it just says "health and human services will issue guidance" and thenyou have to go find that guidance. and it's hard to find sometimes, but we've done that.this is the guidance that the health and human services has put out. these are the standardsby which people that are dealing with ephi, when they're encrypting, can make data unreadable,and unusable, and unrecoverable. and they have these different standards for both dataat rest and data in motion.

and the first standard on the breach notificationrule for encryption for data at rest is a nist document, the national institute forstandards and technologies document called sp800-111. and it's the guide to storage encryptiontechnologies for end user devices. and if you go read this guide, it primarilydiscusses how to encrypt or how to protect portable devices like laptops or cell phonesand things like that. it really doesn't talk at all about how to encrypt data in a datacenter or in a facility like onramp. so, there's not a whole lot of direction there, but itdoes set a standard for the level of encryption or the types of ciphers that you use to encryptdata. and that standard under this document recommends what's called fips compliancy,federal information processing standards compliancy.

and in the next standard below that, thatwe have listed up on this slide, is our valid encryption processes for data in motion, andthose are those that comply with nist special publication 800-52 and nist 800-77. and thoseare guides that talk about how to properly encrypt transportation layer sessions, andmost people know those as ffl sessions or https sessions. those are the sessions youform when you connect to a web browser to a secure site. so there's a publication onhow to do that appropriately. and it's very important, obviously, for all of our customersthat are using web-based applications or any type of ip-based web-facing application.and then 800-77 is a guide to ipsec vpns, which is used a lot, in our data centers,by systems administrators and other users

that need to have more complete access tothe servers than just a web page access. and both of these nist documents also say thatyou have to be fips 140-2 compliant to have properly encrypted the data.now, becoming fips-compliant can be difficult. it can be hard to find. when you go to a vendor'swebsite, it can be difficult to see if their particular product can do fips. and it's evenmore difficult to find out how you can configure that product to be in fips-compliant mode.so nist, the national institute of standards and technology, again, created a program calledthe cryptographic module verification program, or "cmvp." and we've got a link up here thatyou can click through to it, but you can also google search "c-m-v-p," [space] list, "l-i-s-t."and what they've done with this program is

they've looked at cryptographic modules, andcryptographic modules are two fancy words that basically mean a piece of hardware ora piece of software that's encrypting or decrypting the data.so examples of cryptographic modules are firewalls, routers sometimes do it, libraries that areoften used in computing do it. those of you that are using linux or an apache stack ora lamp stack to offer tlf sessions to people on web. applications that people are probablyusing openssl as your cryptographic module on linux.so nist created this program whereby the vendors or the creators of this hardware or softwarethat's going to encrypt or decrypt can go submit their product to the national instituteof standards and technology, and they test

it. they test it to see that it can be madecompliant and forced to operate in a fips-compliant mode.and what they do once they've passed is they enter this cryptographic module on a listof approved vendors, of certified vendors. these people have been certified to be producingproducts that are going to operate in fips-compliant mode. and when you go to that list, what youdo is you search for the name of that cryptographic module.so what i've done is i've gone to the list and i've searched for an asa 5512, which isa model number of a well-used, well-known cisco firewall which terminates ipsec vpnsand a variety of cryptographic operations. and what we've done is, on that list, whenyou see a, say, 5512, we searched for it,

at the link where it shows that it's certified,it has a link to a document called a security policy that's been written and maintainedby cisco. and when you click through that link on thatsecurity policy or arrive at the pdf document, and i've got a cover of it here and excerptfrom it. what's really neat about that document is it not only tells you how to properly deploy,and how the device operates, and how it maintains cryptographic authenticity, it tells you howto configure it and how to test that it's properly configured. and up here on the rightside of this slide, you can see an example of the commands that you type in to a ciscoasa 5512 to make it operate in purely fips-compliant mode. and then later on in that document there'ssome commands you can type in to get it to

report back to you that it's properly doingthat. so by knowing what hipaa says, and by choosingthe proper ciphers and proper encryption levels, and by ensuring that we've got compliant encryptiondevices and modules to use, we've gone a long way to addressing the concern of properlyencrypting our ephi. but there are other concerns and there are other things that we need tothink about, and there are other measures that we can take to complement our effort,to just knowing what to do, what to encrypt, and what to encrypt with. and i'd like topass it back a little bit to jeremiah to talk about some of those other key best practicesthat can help us supplement choosing the best cipher.jeremiah martin: all right. thank you, chad.

that was a great intro. first off, i'd justlike to explain the idea of encryption first off so we all understand what we're lookingat. encryption does not guarantee that your stuff is protected. that's the one thing torealize, this is a mathematical algorithm that can be broken. for those of you thatare familiar, if you're from the tech world, maybe you're familiar with the eight queenstheory? if you're not, maybe you're familiar withthe wheat or rice on the chessboard for the king as an exponential algorithm? encryptionis exactly the same way. so for right now, we're looking at aes 256 as our gold standardof what we want to use out there. there's a lot of stuff that's still 128-bit encrypted.what this means is that there's not enough

computing power and resources right now toactually crack those codes. now, that said, as computing resources improveand technology improves, we're going to see that coming to an outdated standard. so whenyou look at how they encrypt stuff and what to encrypt, you've got to keep that in mind,and eventually you will need to update this stuff. it's not a one-time deal. you needto look at what benefits your culture and what you need to encrypt to protect your datawhile still allowing people to work. so we're going to look at separating your keys fromyour data, how to do that, what type of algorithms are useful, strength versus processing power,the longevity of them, and of course, key management.first off, when you do encrypt something,

you're going to have a key to decrypt it,so you'll want to make sure those are stored properly. there's a bunch of different avenuesto follow there. some people use them on external thumb-drives. some people have hard copies.you want to make sure that you have these keys separate from the data. so if someonegains access to the server, the key is not stored right there on the server, they canget to it. chad: and in fact, real quickly, if i caninterrupt, that's a requirement in hipaa in the breach notification rule, is that if youhave a piece of media like hard drive or a tape or something, an external drive that'sbeen lost and you can prove that's properly encrypted, that's great, but if you can'tprove that the key is secure still, if it's

on the device, then you'd have to do breachnotifications. jeremiah martin: oh, exactly.chad kissinger: it's important to keep the key.jeremiah martin: i mean, it's sort of like the idea of the laptops. if you lose a laptopthat's an unencrypted laptop, you're looking at quite a big fine from hipaa, you're lookingat quite a big data risk, you're looking at tons of stuff that could happen. drive's encrypted?you're out a grand for the laptop. that's all you're really worried about.chad kissinger: that's right, so keep the key separate.jeremiah martin: exactly, and when you're managing those keys, you also want to do balanceof powers. if you have key custodians, you

want to separate those out. you also needto make sure you have back-ups in case something happens to them, so that you can access themstill. and of course, the big thing that i think becomes a problem down the road is wewere talking about how the algorithms will eventually become outdated.events and expirations also will come up and you'll have to rotate those keys. so whenyou're doing that, you need to keep in mind that, if you're ciso leaves and he's one ofyour key custodians, you need to rotate those keys. if you have a developer who has fullaccess to those, you need to rotate those keys at that time. so not only explorations,but you want to look at events that happen that would cause you to actually re-do yourencryption and rotate those keys out.

chad kissinger: and that's interesting yousay that, because that directly addresses what we were talking about in the first slide,which is that people have been thinking about losing the media . . .jeremiah martin: the hardware. chad kissinger: . . . the hardware and thenhaving to do breach notification. and now we're thinking about malicious activity becausethe data is worth so much money that there's a good financial reason for people tryingto steal it. and we need to think about not just people outside the organizations, butpossible malicious hackers inside the organization. that's where you need to think about changingkeys if somebody inside the organization has changed.jeremiah martin: right. and we also have to

think about how to encrypt stuff, where, aswe move away from laptops and standalone servers, we move into cloud architecture in the virtualenvironment, how do we encrypt it to make sure that it's safe? you look at differenttypes of encryption and what's going to work best for your environment.encryptions can be expensive. there's hardware encryption, there's software encryption. whichone works best for you? we need to look at different types of encryption, be it disk-levelencryption or file level encryption. when you look at a laptop, obviously, that's someone'spersonal laptop that they're using for business - full disk encryption makes perfect sense,but the problem is once someone gains access to that laptop, they have the keys to thekingdom.

so when you look at a server environment,if you have a domain admin who accesses the server to do maintenance, to do needed workfor the business, or you have a developer that needs to write code and access that data,you give them permission to the actual full disk, they have permission to see everythingon that disk. so there's ways to mitigate it, but also along those lines, you can lookat different ideas of file level encryption. if people need to access the server but theydon't need to access the data, let's go ahead and lock that down and encrypt the actualfiles themselves or directories. one thing to keep in mind at this point is,if you have people on there with a full disk encryption, all your basic security principlesneed to be followed as well. you want to make

sure that you're malware's protected, youhave a domain admin who logs on, and they have some malware installed on that computer,your data is now compromised. we also look at in this area, we look at peoplewho do need access to the data for specific purposes. one of the best examples would bepeople coding for an environment, they need access to the actual phi data or credit carddata. they need to be able to access that data to write their programs, to make theirprograms run. encryption may not always work best in that scenario. you also can do otherthings like truncate it and mask the data so that those people can access the data towrite their code or do their job, but they don't have to actually be able to see thedata, so you protect yourself in that way.

chad kissinger: i think we're a little bitahead of ourselves, but i think a thing that we're talking about is how to choose the properencryption at rest . . . jeremiah martin: correct.chad kissinger: . . . and what you've covered is, if we encrypt a hard drive, and if weuse hard drive encryption or volume encryption, it's something that's done below the operatingsystem, in my words, then anybody that gets into the operating system is not going tobe protected by the encryption. jeremiah martin: correct, yeah.chad kissinger: they're going to have openings. the hardware and the software's decryptingthe data for them to see. jeremiah martin: right. so if you get someonewho has full permission to that box, if they

logged on . . .chad kissinger: or like you say, a virus. say the systems administrator accidentallyopened it and he has access or she has access and the virus takes over and the data's notencrypted, well, now the data can be compromised, can be copied out of there of that environment.so another type of encryption would be possibly to choose software encryption or databaseencryption or file level encryption, like you mentioned.jeremiah martin: file level encryption, where you can encrypt the data that's actually importantfor your environment. they can still access everything they need to on the server, whereit's doing back-ups, whether it's doing patch management, anything along those lines, butyou're not allowing them to the data that

could be put at risk, and that's if theiraccount was compromised, not necessarily that they're a malicious insider. you do have toprotect the . . . chad kissinger: yeah, compartmentalize everything.jeremiah martin: correct. balance of power, sort of when we were talking about key rotation,you have the two people who have this, like, key, so that way one person does not havefull access to all of the decryption. so you have to have both people agreed, both peoplein there, and you have their back-ups to make sure . . .chad kissinger: these aren't requirements of hipaa, but these would be things that mightbe reasonable and appropriate to supplement if you didn't encrypt something or if youchose just hard drive encryption instead of

software encryption.jeremiah martin: these are more best practices. like i said, there's different things youcan do to protect your data. keep your stuff up to date obviously is one of the biggestthings out there, managing your keys and having a policy of what you're going to do in casethere's a scenario. if the ciso walks off immediately, you need a policy in place ofhow to rotate the keys and you need to practice that.in certain environments, it could take a lot of resources to actually decrypt and re-encryptall your data. i've seen places where it can take up to six months to go through that process,depending on how much code and proprietary stuff you're writing in-house.chad kissinger: and i think that's a good

subject to touch on real quickly is the costof encrypting and the difficulty of encrypting and the danger of encrypting.jeremiah martin: right. chad kissinger: everybody wants to encrypteverything. "well, i'll just encrypt everything." but there are some gotchas. it's expensiveto do, it creates a burden because you have to do this rotation either periodically becauseit's just a requirement of cryptography, and the reason why you do it periodically is somebodyhas surveillance and they're seeing the encrypted data, over time, they could be cracking thecode, as it were, and the encryption. so you want to change the key so that they're lookingat a different code every once in a while. jeremiah martin: and as we were talking aboutearlier about the actual algorithms used to

do the encryption . . .chad kissinger: and they get weaker, right? jeremiah martin: yeah. the fact is we wouldall love to have the highest-bit encryption possible. it's just not reasonable. we wouldnot be able to have the time to actually encrypt everything, decrypt everything. so 256 issort of our gold standard right now because we don't have the processing power to crackit easily. it would take years for most even big environment, big attacks to actually getthrough that. and so that's what we look at. we look at what time resource it's going totake, what's actually the most reasonable amount of protection you can have right now.chad kissinger: so it's expensive, and the last thing i think we haven't talked about,but we touched upon it, and we touched upon

it in making sure you have multiple copiesof the key and back-up copies of the key that obviously need to be secure, but if you loseyour key, that's not a cost of encryption. you're going to lose all your data. it's justas if all the data was erased permanently, without a back-up.jeremiah martin: correct. and i think the biggest problem to see, of course, is thattransition period. so i think a lot of people are really good, especially in a cloud environment,in both using ssl and keeping things secure access to the data, because your customersneed access to those environments and those services. and your domain admins, everythinglike that, they need access to certain resources on the servers.you need to find a way to actually protect

the data in transition. so when someone logson, how to protect that either file level, full disk encryption, someone logs onto theserver and just different ways to protect that data while it's being worked on or utilized.and that's when we were talking about masking the data or de-identify the data so that peoplecan still work with that data but not have full access to the data.chad kissinger: so these are other reasonable and appropriate measures that we could take.we're not encrypting the data so, if somebody has to use the data. and this is consistenthere at onramp. here at onramp, we don't just deal with hipaa data. we have companies thatare banks that are dealing with what are called gramm-leach bliley data, and we have peoplethat are dealing with pci data, credit card

data. and a lot of the things that they consistentlydo in their industries is they try to reduce the scope of the risk, and one of the waysto do that is to cover up the data, to mask it, to make sure that you're not seeing allof it, so that's a complementary measure. jeremiah martin: and it's very effective.again, you can use that from a customer level, to not be able to access other people's data,and from an internal level so that your techs, your admins, your developers can still workwith that data but not have access to it. the insider threat is always probably thebiggest threat you're going to see in the environment.lastly, there's a couple of encryption gotchas. there's a ton of software out there that cando these for you - pgp, semantics, the leading

resource re-seller in the u.s. for that. there'sgreat resources out there that'll help you secure your cloud, secure your environment,secure your data center and walk you through what would be the best way to do that.there's some things you've got to consider. you want to make sure that you're using secureprotocols for any type of transmitting of the data. watch your sys admin access. unfortunately,a lot of times in your environments, have keys to the kingdoms. you want to make surethat if once they're on there, they don't have keys to everything. watch your back-ups.there's people that use san, people that use paid backup still.it's hard to say what is good and what's not. you may have stuff, you may have a seven-yearrotation plan. remember, if you're going through

the encryption cycle, and every two yearsyou're renewing your encryption process, go back through and you're going to have to re-encryptall those back-ups with your newest technology. chad kissinger: and this is really important.this is the place that, when people, other than dealing with laptops and they lose alaptop this is the number-one place that we see enterprises have breaches of securityand privacy rules and have to do a breach notification is they lose backup medium. soproperly encrypting backup media is probably one of the first places an enterprise shouldlook at protecting. jeremiah martin: exactly. so if i have a seven-yearrotation period for my backups, i guarantee you that five to seven years ago, we wereusing 128-bit encryption on a tape. so if

that tape gets lost, it's not going to takea whole lot of processing power these days to actually crack that and get to the data.and of course, logging is a big thing. you always want to be able to know when peoplewere accessing your data, when they attempted, and what they gained access to. you may notfind out about a breach or someone getting to your data until afterwards, so you needto be able to go back, and find it and make sure that you can see those, how they didit, what they accessed, and what you might need to protect next time.chad kissinger: and we see some of our clients that are dealing with web-based applications.oftentimes, they'll generate log messages and the log message will contain data thatwas involved in the error, and that data itself

may be phi. so we need to be thinking aboutthe log itself could be sensitive data and need to be careful of that and think aboutthat. jeremiah martin: right.chad kissinger: so with that, i think that . . .joshua berman: yeah, i'll take it from here. so jeremiah, chad, thank you both for thisinsight. we'd now like to open the floor for a q&a session. we will begin by answeringquestions submitted via the chat window. if you would like to ask a question, please doso now. we do have one question that has come in over the chat. "do faxes need to be encrypted?how is that handled?" chad kissinger: that's a great question.jeremiah martin: yeah, that is a really good

question, because fax, i think it's sort ofgoing away now, but when hipaa started, it was pretty much the primary way to transmitdata between hospitals, it's an older-school system. and there really isn't an easy answerfor "are fax appropriate?" unfortunately, a traditional fax uses the regular phone linesand that's not secure at all. however, hipaa doesn't necessarily give you specific guidelinesfor that. they actually give you regulations to make sure that you're secure. so you wantto have policies in place to record that stuff and make sure that no one sees your coverletters, different policies that will help secure that data.the main thing is, if you're still using fax in your environment, there are alternativesto the traditional fax. most companies nowadays

still utilize fax, but they'll submit it throughe-mail, which can be encrypted. there are secure faxing methods out there that can beused, but basically, like i said, the main thing is to have the policies in place sothat you don't send that fax to the wrong place, because i think that was one of thefirst hipaa violations to come out whenever it was started.chad kissinger: sure. so you've addressed an interesting concern, which is how do youensure that the recipient is who you intended. jeremiah martin: that's the main thing.chad kissinger: but other than that, other than worrying about that, if you can senda fax and know the recipient is secure, the things that i think that are salient is ifit's a real, traditional fax that's going

across a public switched telephone network,generally, that's been regarded as it doesn't need to be encrypted. the fax itself is encryptingit. the modulation and de-modulation of the fax across the pspn itself is . . .now, if you have some of these fax emulation programs, then it's not really going acrossthe public switched telephone network, but it's being sent across the internet as a packet,then no. i would say that it needs to be encrypted just as anything else does. it needs to befips-compliant as fips-compliant encryption, either in the protocol that it's sent acrossthe internet under, whether that's a pls or something like that, or within the body, themessage body of the e-mail. jeremiah martin: and i think this is a goodarea to talk about. hipaa's really interesting,

and it will lay out many requirements, rules,principles, but they're all flexible and don't really prescribe to specific practices oractions that must be taken. i think, when you look at fax, when you look at your environment,when you look at actually the old mail system, traditional snail mail, this permits the organizationsto find ways to adequately protect themselves and protect the privacy of phi appropriatepeer circumstances. smaller hospitals may still heavily rely on fax and they might nothave an option to submit it through e-mail or digitally.so, it just depends on what your environment is. you need to take the steps to make surethat the data's secure when you're transmitting it or that it gets to the appropriate recipientand no one can actually access that data from

there.joshua berman: i actually have another question that's come in. "when operating in a saasenvironment, does storing the keys and data on a separate server suffice for separatingthe keys?" chad kissinger: so the threshold is, wheneveryou have a security incident in which you think a malicious hacker's tried to affectthe confidentiality, availability, and the integrity of the data, that's a security incidentand you need to investigate it and in hipaa, the breach notification rule has a whole requirement.you're supposed to ask yourself four questions of whether it's been exposed or not. and oneof those questions deals with is the key secure and was it secure?so it depends on the type of breach. if the

hacker or whoever compromised it had accessto the first server and the second server, then i would say a breach has occurred andyour encryption is invalid. if after your investigation, it shows that they only hadaccess to the first server and not the second server, then i think you're fine. it's nota breach. you still have a valid, enforceable encryption that's unreadable.jeremiah martin: i think that's a great idea, when you think about it that way. so storingthe key on a separate server's a great idea, but obviously if someone gains access to oneserver, they probably can gain access to the second server. and this comes down to yourenvironment, what works best for you as a company, what works best for you and yourcustodians. ideally, what i'd recommend is

a split key on thumb drives, and to have thoselocked up at a bank where it requires both key custodians to show up to decrypt and gainaccess to the thumb drives. if not at a bank, there's safes out there that require two keysto access. chad kissinger: but it can be difficult ina server environment if you want a server to be able to reboot or something like that.it can be difficult. and if you want to make sure there are types of server systems that'llshow a key vault . . . jeremiah martin: it can, it can, yeah, itcan. and this again goes back to whether we're doing full disk encryption or file level encryption.if you have access to the data that's masked and the administrators don't need to do itfor patching, something along those lines,

if you're actually encrypting the code you'rewriting or the data itself, but you don't need to be able to access that because it'sall masked, then we can do off-site keys. now, if you do need it on-site, there areother ways that having it on a different server would be good and you can still utilize thumbdrives and have a safe on-site to be needed by the key custodians.chad kissinger: now, one of the mistakes we see people doing, oftentimes, the key fortransmission for a tls session will be placed on the server because the encryption is meantto protect the data while it's being transmitted, not at rest, right? so the encryption's notintended. the key's never going to be transmitted. it's just on the server. now, the mistakethat we see people making is when they do

encryption at rest. again, during a reboot,they want that key to be available, so they'll put it somewhere on the computer and thatmeans it's been compromised at the same time the data has.jeremiah martin: and another option you can do is the key server. you can have a serverset up specifically to manage those keys. chad kissinger: right, which is a hardenedserver. jeremiah martin: exactly, and in that server,no one really needs access to it other than the people that need access to those keys.so that's a server that you can lock down. it doesn't need to be available to the public,it doesn't need to be available to other people. but that way, your maintenance people, youradministrators, people like that can still

access and utilize it.joshua berman: i have another question that's come in. "for a rest-style, web api servicethat uses private patient data, is https sufficient encryption? or should message-level encryptionbe layered on top of it?" jeremiah martin: the simple answer is yes,because it meets the requirements. now, what works best for you in securing your environment'sa little different, and that's dependent on your situation, and the environment. for me,it's always about going above and beyond without interfering with the day to day jobs of yourcompany or your environment. chad kissinger: yeah, so the data being transmittedis obviously at rest. api's going to be transmitting across the internet or an unsecured network,and it's https is a tls, and that nist document

that we talked about earlier, nist 800-52talks about selecting the use of transfer tls implementation, and it would say thatall you need to do is the ephi needs to be encrypted to fips-compliant level. so whatevercryptographic module either at the tls level or https level or at the message level, whichevercryptographic model is used, it needs to be fips-compliant and it needs to be placed infips-compliant mode, and then either way is sufficient.joshua berman: i have another question that's come in, and it actually brings up a prettyinteresting topic. "so how does hipaa and encryption apply to mobile devices?" that'sa pretty hot topic right now. chad kissinger: well, just in the same waythat we've been talking about before. just

think of it as a mobile server. a cell phoneor a laptop or anything like that transmits and stores data, so the standards are thesame for both storing the data and transmitting. i can say, though, that the only special guidancethat the office of civil rights, of hss, the people that enforce hipaa, since hipaa's beenput out, has been about the announcement that they're really having a lot of trouble withlaptops and mobile devices. so the standard practice, the standard measures that jeremiahtalked about earlier stand with mobile devices. jeremiah martin: yeah, i think one of thebiggest concerns i see these days with mobile devices is, they have full access. we haveoutlook, you have your e-mail, you have idrive, different things you can access to gain evenmore data. there are policies that's your

best way to control that. i would restrictaccess to most of it. another big concern i see with a lot of themobile devices nowadays are hotspots, rogue hotspots in your environment. it gives anyonethat would have malicious intent the ability to transmit large amounts of data in and outof your environment. so those are a couple of things to really keep an eye on in yourenvironment, depending on what goes on. joshua berman: "can text messages be encrypted?"is another question that came in. chad kissinger: so not just through sms. wespend a lot of time at the american telemedicine association conventions, and at that convention,there's a lot of innovators there that are coming out with different ways to transmitephi. and i would say that what we see is

people that want to transmit data across theinternet or through e-mail or all that, there's a variety of ways that they can do it, butwhat i see people end up doing is they send a simple message through e-mail saying, "yourdoctor wants to talk to you. he sent you a message."and then you log in through a portal, which is of course a web portal doing an https ora tls session that's probably encrypted and then you get the data through that portal.and then similarly, what we see with text messages is not people using the standardtext message infrastructure. they'll create an application that emulates text messagingthat has its encryption in it. so no, you shouldn't send ephi through a normal textmessage.

jeremiah martin: and that applies to sms,imessage. those just aren't really secure enough.chad kissinger: they're not encrypted. joshua berman: getting a lot of great questionshere, and actually, this plays off of our involvement with the ata. one question asks,"if i'm looking for a secure video conferencing solution to speak to patients, what questionsshould i ask the company about their encryption to ensure i'm covering my bases?"chad kissinger: well, obviously, that video's going to be transmitted across an unsecurednetwork at some point, so you want to make sure they're encrypting that data all theway from the point that their secured network touches the internet, or the unsecured network,all the way to the point in your network that

does that. so you can do that in two waysor two general ways, there's probably several other side cases. one is, let's say it wasa clinic and a hospital, and you were going to have patients in the clinic see doctorsin the hospital, and they were in two static locations, you could get the firewalls andset them up with permanent vpns in between them that were properly encrypted.and that would be the best way because you would always know the encryption is better.and then you wouldn't really have to worry about the application itself. the applicationwouldn't need to worry about the encryption. that video would never be transmitted acrossan unsecured network because you secured the network itself.and the other way is through the application.

so it's either from the device that's takingthe video and the application all the way to the device where the video's being viewed,and that's typically through a web server or web browser negotiation, and again, that'sa fips-compliant tls session or https session. that would be used if you have a patient that'smaybe roaming to you through their laptop or cellphone or something like that.so in that case, you would want a secure tls session that's properly encrypted. so you'dask that vendor, "how are we encrypting this data as it crosses the internet?" and "howis that fips-compliant? can you prove to me that that's done in a fips-compliant mode?"jeremiah martin: and that is a great thing these days. we're moving ahead in technology,we're getting away from standard phone lines,

especially in the corporate environment. andthis goes back to the fax discussion. most people, even the faxes that are being transmittedaren't going over through standard phone lines. they're being converted digitally, transmitted,and then converted back. most of the professional ones aren't goingto use skype, but even skype is encrypted. they use tls, they use aes, they use goodencryption standards. pretty much most of your digital mediums that you're using totalk these days are going to be encrypted. in a corporate environment, you'd want touse something at a little enterprise level, cisco, something along those lines to do yourvideo conferencing, stuff like that. all of that is encrypted, so we're at a point whereit's good.

now, the thing to consider, though, if you'reusing some of that technology, whether it's cisco voice connect, skype, any of those lines,some people still will connect up from standard phone lines. that will not be encrypted. soit's one of those things. if you're doing corporate to corporate, you're probably safe,but make sure your environment is in a place where it can be encrypted and it actuallyis going over digital. so once it gets connected to analog or cellular, you run the risk ofpeople being able to access that data. joshua berman: okay. well, i think we've justabout run out of our time here. thank you, chad and jeremiah.chad kissinger: thank you. jeremiah martin: thank you.joshua berman: if you'd like more information

about onramp's hipaa-compliant hosting solutions,please visit us online at www.onr.com/hipaa. to stay up to date with our latest news andevents, connect with us on social media, and don't forget to subscribe to our youtube channelfor direct access to today's webinar recording. on behalf of onramp, i'd like to thank everyonefor attending today's webinar. thank you.