Cybersecurity is critically important in the healthcare industry. We’ve all seen the headlines about vulnerabilities disclosed, information leaked, and facilities disabled because of malware.
Unfortunately, many organizations have unrealistic expectations of their security teams. These result in missed deadlines, friction with product teams, and an operational model that cannot scale and is ultimately doomed to failure. By understanding the correct functioning of a security group, organizations can reduce overall risk smoothly and effectively.
Let’s look at the journey of an imaginary company, Infuzimed, which manufactures infusion pumps. Infuzimed has been happily making and selling these pumps for many years. For the last decade or so, they’ve been adding network connectivity for greater convenience. Based on recent headlines about hacks, they are concerned (rightly!) about cybersecurity.
Naïve recipe for defeat
Without knowing any better, Infuzimed’s response is to hire a chief security officer (CSO) and create a team that has responsibility for the security of its products.
The team purchases some security testing tools, including source code analysis, software composition analysis, and fuzzing. Then, as each product team nears completion, the security team runs the security tools on the product, reports findings, and suggests improvements and mitigations.
As time passes, the security group becomes a bottleneck in product development, as all product teams are relying on the same small group to perform security testing.
From a product team’s point of view, security testing is a nuisance and a slowdown. First, they have to wait for the security team to perform the testing. Then they have to deal with the security team’s findings, which can be overwhelming and come at a very awkward time in the product development life cycle. When they have to make changes, developers might already have moved on to another product, and finally, the security team must perform testing again.
Furthermore, the product teams have no context for the information they’re getting from the security team and might not understand why it is important. When findings are copious, the product team will pressure the security team to prioritize the issues, then commit only to fixing the “really bad ones.”
As Taylor Swift observed, “Band-Aids don’t fix bullet holes.” This kind of after-the-fact, late-in-cycle security testing is counterproductive and frustrating for everyone.
Faced with an endlessly growing mountain of work and hostile development teams, morale in the security team steadily worsens, and retaining personnel becomes difficult. The CSO acquires a nervous tic, loses sleep, gains weight uncontrollably, and has relationship trouble at home due to added stress at work.
Eventually, despite the best efforts of the CSO and his or her team, security researchers discover serious vulnerabilities in Infuzimed’s products, which in turn become a public relations disaster. Investors panic, the stock price plummets, and the CSO is out on the street by the end of the week.
In case that wasn’t dark enough for you
Things could be far worse. Instead of security researchers finding the vulnerabilities, imagine if malicious attackers find them. These miscreants could exploit the vulnerabilities, causing patient injury or death. Everything else would be as before, including the stock price faceplant and the abruptly unemployed CSO, with the added possibility of criminal and civil litigation.
The security team is not a bucket
The problem is treating the security group like a bucket where the rest of the organization dumps its risk.
Security is everyone’s responsibility. The difficulty is that sometimes when things are everyone’s responsibility, nobody steps up to take action. As Lily Tomlin put it, “I said, ‘Somebody should do something about that.’ Then I realized, I am somebody.”
Healthcare organizations already understand the concept of patient safety. When Infuzimed designs and builds a product, they think about safety all the time. They think about it when they design the product, when they build the product, and when they test the product. They don’t have a separate group that takes all responsibility for safety. Instead, a culture of safety is baked into the product development process.
Cybersecurity needs to work the same way. Security needs to be part of every phase of product development, and it needs to part of the mindset of everyone in the organization.
Security as vaccination
Hiring a CSO and building a security team are excellent first steps. But instead of dumping cybersecurity risk inward, the security team should spread its knowledge and expertise throughout the rest of the organization, like a vaccine teaches the body to strengthen itself against disease.
Viewed in this light, the security team becomes a shining beacon of knowledge, a team of experts in secure development practices and security testing tools. Instead of being a testing bottleneck, the security team helps product teams automate and integrate security testing into established product development processes. Then, as product teams create products, they identify security vulnerabilities and eradicate them just like any other bugs, with minimal friction for developers.
The functions of a happy, well-adjusted security team include the following:
- Create an SDLC and help product teams adopt it.
- Help define security policies for products.
- Be experts in cybersecurity and educate the rest of the organization.
- Be experts in security testing tools and help DevOps teams automate security testing and integrate results into existing workflows.
With the right set of expectations, your security team can thrive, spreading security savvy and lowering risk throughout the entire organization.
