Tuesday, October 9, 2018

Inaugural Mental Health & Wellness Workshop at Derbycon8

This year was the first ever (as far as I can tell) Mental Health & Wellness workshop at an information security conference. For those of you that haven't heard my Hackers, Hugs, & Drugs talk a little background is called for first. I've been struggling with anxiety and depression since my mid-teens in one way or another. Poor relationships did nothing but fuel the issues I was already having. When I started interacting with the infosec community about 6 years ago I started feeling a sense of belonging. Through my trials with different medications and coping mechanisms I've started to get a little more of a handle on (or at least a better awareness) of my own mental health. I consider this community my family, more so than most blood relation that I have. This has been the first group of people that understand me and you understand others around you. When I began tweeting, posting, and talking to people at cons about anxiety, depression, and other mental health issues I realized that there are a LOT of people here that not only are struggling with this type of stuff, but trying to tackle it alone like I did for a good 10 years or so. I've had amazing conversations with some super smart and personable people, that you'd never imagine would be struggling. The kind of people that look like they have it together. I want to continue this conversation and try to make it as public and without stigma as possible.

After a year and a half giving this talk at various conferences and meetups I continued to be awestruck at the overwhelmingly positive responses. Each time I would think "Ok, maybe I've given this speech enough", I would have another person come up to me to talk about how it lead them to go get some counseling, or to change their minds about self harm or suicide. After hearing story after story I thought it would be good to continue these efforts at a larger scale. While I love speaking, it only reaches a certain number of people. We needed more. That is when the idea of the workshop came about, and honestly it did turn out to be more of a village with smaller workshops inside of it. After pitching the idea to Derbycon and getting accepted the idea started to take shape. The gofundme campaign was created and earned around $7,000 for not only this particular instance, but to donate to charity what we had left over (more details at the end, so keep reading obviously).

This room turned into something more than I could have ever envisioned. I wanted to help others by providing a quiet space and some information but it sometimes morphed into a therapeutic sharing session and conversations that I even have a hard time explaining. Our four massage therapists were never not busy, so definitely expect to see them back again next year. We fidgeted, colored, created, napped, hugged, cried, ate, and meditated; all with friends and family surrounding us in a positive and calming environment.

None of this would have been possible without the amazing help of all of the volunteers that signed up, and some that didn't really even sign up but were roped in one way or another. I'd like to especially thank @click_wire for helping with almost every aspect at the conference, and keeping me from having a few ongoing breakdowns myself. @v33na for giving us her yoga and meditation expertise as well as leading a group discussion on self care and emotional intelligence. @andMYhacks for covering some time management skills as well as always checking in and being on top of things (not just the air loungers). @JaysonStreet for his deeply touching and heart wrenching talk, he sure knows how to command a room. The responses and interactions with him as our final speaker left the whole room in tears. @0rphik for all of the help setting up and continued interaction and compassion to others around you, for those that weren't crying after Jayson was done, they were when you spoke (oh, and thanks again for the book #squee). @RayRedacted for the immense amount of help and positive interactions you brought to the room as well as an awesome talk on bringing light to our lives. Both @Tr0phywifehacks and @S1r3nn for bringing your supplies and knowledge and helping so many people with it.

Our speakers and discussion group leaders @dakacki, @investigatorchi, @f0zziehakz, @brentwdesign, @ZanshinH4x, @Integgroll, @hoshin, @Blenster, @SteveGroark, @bsdbandit, @5urv1va7rix (and her amazing service dog Trevor) who not only shared personal stories, but listened to yours and taught us a lot of amazing information that wouldn't normally be covered at a conference like this.

Our volunteers that watched the room, checked up on things, and were just amazing overall @oncee, @mr_minion, @SirgurdWV, @landonchelf, @secbuff, @cillic, @EricGershman and his wife Tina, Cherie, Val & my favorite puppy Fava. We also couldn't have gotten this far without the help of @HackingDave, @Karl_Creepy, Dave DeSimone and the rest of the @DerbyCon crew. Not to mention the inspiration I've gotten from @mubix with #hackingtogether and @ihackedwhat.

Also, for those of you that poured your heart out, found help, connections, friends, family, support, and whatever else you may have needed or felt like you could give at the time. I love you all and can't wait to see you again!!!!

Some final numbers and information about the workshop:

GoFundMe Info

  • Total Views: 1571
  • Total Donors: 28
  • Total raised: $7,026
  • Donating to Charity (Brain & Behavior Research Foundation): $1,321


  • 22 volunteers
  • 8 presentations
  • 7 group discussions
  • 2 hours of yoga
  • apx 120 chair massages given
  • gallons of tears
  • 1 flattened Lintile

Up Next

  • Looking for corporate sponsors - If you're interested in donating or volunteering in any way we're looking to switch from a gofundme to corporate sponsors in some shape or form. Feel free to contact me through here or twitter.
  • Headed to @DachFest in Munich to run this again
  • Possibly doing this as a village for @BsidesLV and more

Tuesday, January 23, 2018

HIPAA vs Security: Building security into medical purchasing decisions

What the security community says about a specific industry vertical usually holds true for a good percentage of what is seen in the wild. You can ask any hacker, defender, CISO, etc what industries struggle the most and there are common themes in their answers. Top of the list includes healthcare, manufacturing, government, and financial. Some of the most heavily compliance controlled and regulated are also some of the least secure. Why is this? Is it due to administrators and senior management taking compliance standards as gospel? Maybe it’s a lack of knowledgeable staff like the blind leading the blind.

Rapid technology growth in the healthcare space definitely has not helped. Decision makers are slowly working security practices into business initiatives, but that doesn’t account for all of the security debt that has built up in this technology boom. So now what? How can business work to quickly protect their customer’s data, their own data, their products, while still doing what they do best? Do not fall into the habit of performing tasks, going through routines, or completing configuration with the mindset of “This is how we’ve always done it.” That type of mindset will only hinder progress and decrease security posture in the long run.

Humans are allergic to change. They love to say, “We’ve always done it this way.” I try to fight that. That’s why I have a clock on my wall that runs counter-clockwise.” — Grace Hopper, “The Wit and Wisdom of Grace Hopper” (1987)

How and why should security be tied to HIPAA?

The requirement to comply with one standard or the next does provide a few benefits to your organization. Certain standards leave significant room for interpretation, giving you the ability to tie security measures that should be implemented to a portion of that same standard. When compliance is involved there are now social, political, and legal components added that can be leveraged to implement security controls and process changes that may not have been possible otherwise. It also may present the opportunity to piggyback off another department that has excess budget for a project.
The Health Insurance Portability & Accountability Act (HIPAA) was enacted in 1996 as law and establishes national standards for electronic healthcare records. It includes any organization that stores or processes ePHI (Electronic Protected Health Information) healthcare providers, health plans, and clearinghouses. There are fifty “implementation specifications,” divided into administrative, physical, and technical safeguards. Most specifications listed involve having policies and procedures in place. Addressable specifications involve performing a “risk assessment” and then taking steps to mitigate the risks in a way that’s appropriate for your organization. One of the largest HIPAA penalties against a small organization was levied not because an event occurred, but because the organization failed to address the possibility. Loss of ePHI can cause significant harm to not only the patients whose data has been compromised, but also the provider and individuals at fault as they are required to report violations to the US Department of Health and Human Services (HHS), the Federal Trade Commission (FTC), and are susceptible to extremely large fines and jail time. The HHS provides a breakdown of each portion of the security rule portion of HIPAA and assistance with the implementation of the security standards.

Is HIPAA enough?

HIPAA has been put in place as law as a standard of compliance. It has *not* been put into law as an exact roadmap to secure infrastructure. It is a guarantee that with a secure infrastructure, compliance will follow. For example, the HHS points out

Four implementation specifications are associated with the Access Controls standard.
1. Unique User Identification (Required)
2. Emergency Access Procedure (Required)
3. Automatic Logoff (Addressable)
4. Encryption and Decryption (Addressable)

While both 3 and 4 are both addressable, they are not a requirement, rather you're permitted to have a compensating control, or documentation on why you can not meet them. Doing that as opposed to implementing them, would be akin to "accepting risk" on something you shouldn't be accepting risk on. Not only are there some items that aren’t specific requirements, but the documentation also leaves a lot of room for interpretation. Security practitioners will often look down on HIPAA as a standard. However every environment is different, so there is no standard or guidelines out there that are going to be the “end all, be all” answer. HIPAA can definitely be incorporated into a security architecture plan that includes in-depth knowledge and strategy, so can most other compliance standards. By using it as a guideline to implement a proper design both compliance and security can be achieved.

Building security into medical purchasing decisions

Malicious attackers are using multiple vectors including exploiting vulnerabilities in medical devices and printers. Networked medical devices represent a significant security challenge for hospitals, because their IT teams cannot upgrade the underlying operating system and third party applications embedded into these devices. Many medical devices using older versions of Windows and Linux have known security vulnerabilities and are at risk of malware contamination. The vendors supplying these devices sometimes will not allow them to be updated, or have their own remote process and procedure to do any type of update at all. When a third party vendor comes in to show off their new product, here are a few questions that should be asked prior to any purchasing decisions being made as well as a general secure answer.


Is remote access required for support? If remote access is needed for support, it should be only enabled when needed, and segmented from accessing any other devices in the environment. Remote access clients should not be installed on any endpoints as that scenario gives unmonitored and possibly unlogged access into the network. All remote access should be over a secured network, logged, using multi-factor authentication, and segmented to least access needed.


Who is in charge of endpoint software updates? No matter if software updates are provided by the vendor to be applied by an internal team, or applied by the vendor themselves, they should be tested in the environment prior to deployment.

Who is in charge of endpoint OS updates? It is recommended that updates are distributed in the same manner as the rest of the enterprise. If using WSUS, separate deployment groups can be created if needed.


Does it require any third party applications? (Java, Adobe Acrobat, any type of SQL server, etc) Hopefully not. Having third party applications such as Java, Adobe Reader, etc significantly reduces the overall security of the endpoint. If there is no way of getting around this, third party software updates should be managed automatically and timely. Configurations on any type of database, web, or other service server should be hardened and patched to sufficient standards as well.

Is there support for upgrading third party applications to the latest patched version? If the vendor doesn’t support upgrades, move on to another vendor. As time moves on, more and more vulnerabilities will be discovered and the application’s security will continue to decline.

Do any firewall ports (host or network) need opened? If they have specifics that’s great! A good vendor should have the specific incoming and outgoing ports documented as well as what external IP address they will need access to. This complies with least access. Port forwarding should never be an approved option, and any direct communication involving sensitive data should traverse over a secure connection.

What data access is required? Many medical devices need interface access to other portions of the infrastructure. Whether it be data in an EMR, scheduling data, x-rays, etc knowing what type of data access is needed and in what matter it will be obtained is valuable information for asset management and documentation.

Is data stored on disk or in memory on the device, and if so, what type? You can’t protect data if you don’t know where it resides or how it moves throughout the organization. Knowing where the sensitive data is and how it is structured will go a long way in ensuring the correctly formatted rules are in place.
Data at Rest: Data in databases, on file servers, or in custom applications not only should be identified as previously stated, but also encrypted and in a secure physical location.
Data in Motion: Common avenues of data access to pay attention to (and their ports) are FTP (21), SFTP(22), SMTP(25), HTTP/APIs(443/80/8080), SMB(445). Any network monitoring solution should be able to alert on sensitive data in transit.
Data in Use: Data that can be exfiltrated using things like CDs, USB drives, or with copy/paste to external websites from the user endpoints.

What security testing is applied? Software should go through regular penetration tests and code audits. Usually companies that have bug bounties are more security conscious as well.

Are the endpoints added to the domain? In a windows environment (which the majority if not all of medical organizations are) adding all endpoints to the domain or a subdomain is preferred to leaving them to be managed manually. The security options are far greater when a client is domain joined as opposed to just sitting on the network doing its own thing. However, prior to even connecting a vendor device to the network, it should be offline scanned for malware and viruses.

Is there any application/device specific logging? If so, this could be helpful to collect into a SIEM or managed detection service for alerting or aggregating for later use in the event of any IR performed.