Executive Perspectives Pt 3: Reporting to Legal

Here’s a third installment of discussing reporting lines between security and executive leadership. Previously we’ve talked about going up directly to the CEO, and reporting through IT/Eng. In this post we’ll talk about reporting through legal.

Three of my career lifetimes ago, the security team reported up through the General Council. This was for a healthcare communications organization, so you could smell HIPAA with every turn of the head, but it never really made you change anything you had to do from day to day (but if someone screwed up, they were almost always dismissed out of hand — you do NOT tolerate PHI being mishandled!). I don’t know if it’s the same for all corporate attorneys, but I got the impression that the General Council was almost as busy, if not more so, than the CEO. I know all executives think the glory of God shines on them alone, but just shadow the General Council and you’ll see the woman behind the curtain. Amiright, counselor?

Advantage.

Let’s start with the most significant advantage of reporting through Legal — you are only one step from the CEO. The CEO has been guided and protected by attorneys on their side since they made enough money with their lemonade stand to have to pay taxes. They trust their attorneys. When the attorney says it’s time to jump, by gosh that org will jump.

Disadvantage. Or is it?

With this comes the most critical disadvantage of reporting through Legal — your boss only speaks in regulatory concerns and is worried about incidents insofar as they force disclosure to third parties. The security team starts to look and feel like an Internal Audit department. All The Other Things you must care for don’t disappear, but they might take a back seat. Let me be clear — this is not a true disadvantage — this shouldn’t make your job any harder than it would be with other reporting lines. All The Things will *not* take a backseat to regulatory obligations. You need to just view them through the lens of regulatory obligations.

Leveraging Legal Requirements to Make Security a Requirement

HIPAA says you need to know where your PHI is and protect it as sacrosanct. So do your data mapping and flow, and make those DBs, repositories, apps, and transactions your highest priority. Protect it all with all your end-point security (think: EDR (Endpoint Detection and Response)), control who has or has no access (think: RBAC (Role Based Access Control)), and control what they can or can’t do with the data (think: DLP (Data Loss Prevention)). Monitor activity around these objects, locations, and actions (think: SIEM (Security Incident and Event Management)). Make sure external access is being monitored and baddies are rebuffed (think: Firewall (protecting the corporate network if you still meet in an office) and WAF (Web Access Firewall — this goes in front of the app). Take care that you have all the policies in place and do all the training on how team members are also responsible for the security of the data, and then audit and report, of course. You also want to ensure you have a good incident management plan for if any HIPAA is touched when it shouldn’t be, and know who needs to be involved and informed. When you have the basics in place, monitor the Dark Web to see if anything you’ve put in place failed without you knowing and your data is ‘out there’. Make sure the app is being closely watched — check for vulnerabilities that could expose HIPAA (or any other data) or give unauthorized access to any such data as early on in the development process as possible. Threat Model with Product. Scan the code with SAST (Static Analysis Software Testing), DAST (Dynamic Analysis Software Testing), and IAST (Interactive Analysis Software Testing) tools to find any potential weak spots or inappropriate access vectors to HIPAA data before they go live. Get some tools to check the infrastructure of your cloud instances to make sure everything is being done as well as possible to make sure that environment isn’t breachable.

All these things need to be done to be able to give assurance to the legal team that HIPAA data is protected. And hey, you know what? There is almost no additional work to offer the same levels of control, observation, and reporting to all the other data simultaneously! Look what you’ve done! You built a robust security posture to protect all the HIPAA data and locked down everything else, too!

Who Wears the Privacy Hat Here

If you ever have had to wear that hat with your security leadership role, Privacy will be off your shoulders. Privacy is a specialty of lawyers; even if they don’t have the bandwidth, they’ll take it on them. This makes it a pretty smooth arrangement, and things will flow back and forth with data mapping, data management, and data security.

Having a Lawyer in Your Court

Another excellent advantage to this relationship between security and legal is you have quick access to someone who is on top of legal requirements and interpretation of legal obligations and requirements. When you’re working on client demands for your security posture, you’ve got someone who’s happy to push back on anything you want to push on. In truth, there were times when I had nothing, and the lawyers wanted me to push on *something*. So I said, “uh….can we push notification on an event from 48 to 72 hours?” “Yes! Let’s give ourselves that room — they’re certainly asking for a lot from our support team, this will be good. Thanks for coming up with that.” “Uh…happy to help.”

So, this is a quick summary of this reporting model. This one isn’t my favorite; reporting to the COO is. It may have been the COO I reported to (he was terrific and taught me a lot about the startup world; I think I’ll share some of that in another post if there’s interest).

What Should We Talk About Next?

But what would you (the reader) want me to write about? Let me know in the comments or send me an email (sean [at] shunkydave [dot] com). I don’t want to blog into the void; I’d instead make it a back-and-forth.