We often get questions from both the tech staff and security officers about what should be documented regularly and why it should be done. There are three reports from IT that you need to get on a regular basis IMHO. Today, we will discuss those three reports, why you need them and what to do with them.
In this episode:
Three reports you need from IT
Today’s Episode is brought to you by:
Kardon and HIPAA for MSPs / Security First IT
Where to meet us
- 4medapproved Healthcare Cybersecurity Officer Live Webinar Workshop – Sept 12, 13, 19, 20, 2018 Use GRINDLE20 to get a 20% discount.
- Georgia Pediatric Practice Administrators, October 18
Next HIPAA Boot Camp
Live in Tucker, GA
October 25th and 26th
www.HelpMeWithHIPAA.com/bootcamp
Want to be part of Help Me With HIPAA? Donate to the cause at www.HelpMeWithHIPAA.com/give
HMWH App now has more features. You can now access a PDF with the show notes ready for your HIPAA training documentation! Find it under the bonus feature in the app for both the Apple and Android versions. It is a little gift box on the app bar.
Like us and leave a review on our Facebook page: www.Facebook.com/HelpMeWithHIPAA
[6:36]
Three reports from IT
It is often a tug of war game between tech folks and others in the company. One of the things we cover in our boot camp is the interaction between tech folks and “everyone else” must change. It needs to change in both directions though. Tech people need everyone else to help and can’t talk down to or at everyone when explaining things. Other people need to stop treating tech folks like they are someone you can ignore or not treat like they are some weirdo to avoid. Granted on both sides it may be very hard to accomplish this truce but it is important.
Along those lines, we have our clients ask their tech teams to supply documentation for their book of evidence. That sometimes kicks off one of those games of tug of war between the two sides. We are looking at what both sides need for our example today. So, we are covering three documents required from the tech team to have the essential documentation needed by those in charge of managing the privacy and security programs.
Documentation is required to prove the technical policies and procedures are being followed. This documentation can be requested as proof that things happening today for the next 6 years. Yes, 6 years. Let that sink in a minute. This entire conversation is directly related to that point. Everything that both sides need to understand eventually points back to this requirement.
If you are in charge of managing documentation you need to make sure you get the documented proof things were taking place and keep it organized for access up to 6 years from now. That also means that someone will need to look at the documentation and actually be able to SEE that it is saying “we have confirmed that something was being done.” It isn’t something the client is supposed to guess what it means. They aren’t supposed to have to decode it. I should be able to look at a report and know what happened.
Most tech teams are not very good about documentation. In fact, many of the issues that arise in a crisis are directly related to lack of proper documentation. As one developer said after I explained all of this to him “So, you want me to eat my broccoli?” Yes, that is what we need for you to do. No matter how confident you are in your work today we may need to find a way to that prove you did today’s work 6 years from now. You are doing the work and making the decisions, we just need you to generate documentation in something that at least resembles English.
What are the three reports we are most interested in getting on a regular basis? Certainly, there are likely more than three but let’s start small and build on that for now.
Three reports
1- Patch management evidence.
You will need to prove that if your policies and procedures say you will be installing software and operating systems patches on a device that it is actually getting them. If they aren’t being installed then you have to know why they were not installed and when they will be installed.
Equifax is a perfect example of this issue. The software vendor security patch was announced March 6, 2017. That was one day before the vulnerability news was released publicly. What happened next has mostly been reported as follows.
- Equifax apparently had an internal memo circulated about the flaw on March 9. Their policy says that the patch should have been applied in 48 hours. It was not.
- It was time and labor intensive to install the patch but it was clear by March 9 that the flaw was being used on a massive scale by hackers.
- Equifax didn’t install it until 146 days later on July 30, 2017. That was also the day after the breach was “discovered”. So, we know they wouldn’t even have done it then without the breach occurring. It was time and labor intensive but when properly motivated they managed to get it done in one day.
- The ex-CEO blamed one poor guy for the whole thing because that one person was responsible for identifying and installing security patches. The entire organization had a single point of security failure when this person did not install it and did not inform the organization it wasn’t being done.
If someone was actually taking the time each month to review the security patches that had been released (a memo should have triggered it to go somewhere), they would have found the major problem long before the breach. At least within a month.
The person who was blamed for not escalating it may or may not have done what they were supposed to be doing. However, if someone else was waiting for a monthly update on security patches that should be installed and their status someone would have caught the issue within a month.
Assume that the person did escalate things properly and reported the need to install the patch repeatedly on their monthly report. Things would probably be going much better for them these days.
Let’s assume you don’t have a breach of this magnitude. Hopefully, no one listening to this podcast will have one. If something else does go wrong or if there is an audit or a detailed reviewing during an acquisition it will be required to prove that work was being done.
2- Antivirus and antimalware evidence.
You will need to prove that every device that my policies and procedures say should be running proper solutions are running them and everything is up-to-date and clean. If they aren’t being monitored in some way then how well are they really working?
A single undetected malware program can create a lot of havoc. If the systems are logging quarantines and suspicious activity then who is checking those logs to see if that is your “canary in the mine” indication?
Don’t forget that malware can come into your system in many ways. It doesn’t just arrive through emails and websites. It can come in from a computer used on a home network or a USB drive. A regular review of how you are monitoring your network for malicious software can make sure you are covered all the way around.
Pay attention to the number of devices that are monitored that number shouldn’t change unless you changed the number in your office. The versions installed should be consistent across all the devices. If there is any variation that isn’t expected, someone needs to evaluate what is happening and document what changed.
3- Network device firmware review and patching evidence.
You will need to prove that every device that my policies and procedures say should be running security tools and monitors are, such as a UTM. If they aren’t being patched then why isn’t it happening? When will it happen next?
Often there is concern that updating these devices may break something else. That is understandable but not a reason to just not do it. It may be very likely that someone at Equifax thought it would take too long or cause problems with something else so they put it off. Too bad the millions of us that paid the price for that decision. Remember, it is about making sure nothing goes wrong on your watch that you could have prevented with a single patch. Who wants to be the one who has to admit that in a meeting, in court, in an investigation, before Congress or worse?
If you believe there is a reason to skip a patch and install it next time, then document that clearly. Address it properly and your decisions are acceptable. But, you have to be willing to write it down and put your name on it. If you aren’t willing to do that then you should probably be loading up that firmware patch pretty soon.
Report content
If I get a report that basically just says “trust us we did it,” I really can’t prove much about what happened. If I get a report that says we updated 3 servers and 38 desktops with patches, again not very helpful. A summary report is great as long as it is backed up with a detail report. When something happens I will need to say that specific computer was updated on this date and these were the applications and operating systems versions at this time.
When things hit the fan it will be your fault unless you can prove everything that was reasonable was being done to prevent an incident. The reports should allow you to show that was happening, in something like English, 5 years from now.
While reporting isn’t something any of us get excited about doing, it is essential to any formal privacy and security program. The only way we can prove years from now that we were doing all of this today is to document it. So, yes, you must eat your broccoli and document the things you are doing. There is no one asking you to document it because you have done something wrong. In fact, everything hinges on you documented all the things you did right. Don’t hesitate to ask for these reports until you have them as often as you need them and how you need them.
Please remember to follow us and share us on your favorite social media site. Rate us on your podcasting apps, we need your help to keep spreading the word. As always, send in your questions and ideas!
