Synergies Between Regulatory Compliance and DevSecOps

After 15+ years building medical device software, I've learned something counterintuitive: FDA regulations don't slow down secure development—they accelerate it. For as long as I've been a Software Engineer, I've thought about the things that can and will go wrong in software, and what the security implications could be.

The modern view of this is called "DevSecOps". This is short for Development, Security, and Operations, a software engineering culture and practice that integrates security into all phases of the software development lifecycle, promoting a culture of shared responsibility for security.

If you think about how this point-of-view maps to the world of regulatory compliance for medical devices and software, there are fundamentals that are key for both. For instance, ISO62304 and the DevSecOps are concerned with Hazard Analysis and Threat Modeling respectively, as well as requiring traceability and auditing capabilities as foundational for risk management. The emergence of DevSecOps has driven a welcome "left shift" of cybersecurity into the software development cycle, making security part of requirement and design. This is getting teams to think about security earlier and not consider it a "bolt-on" activity. The regulatory requirements actually enhance DevSecOps. 

For Instance: Paying attention to the software manifests and SBOM from the start can help drive conversations such as "Do we really need that library?", "What vulnerabilities does the library have?" and “Do we really need 47 dependencies for one feature?”.  If you have to answer these questions at deployment, without having given them prior consideration, it is a painful, rushed and more error-prone process than it needs to be. An SBOM that meets FDA guidelines is going to support good vulnerability management practices.

Lastly, the testing required for medical devices usually exceeds the scope and depth of testing done solely for cybersecurity. It's not a question of either/or but both for a successful deployment/release.

 

Colorful

Use words and phrases that create pictures and carry emotion.

How do you add color to a presentation? Must every presentation send you scurrying to the thesaurus looking for adjectives to create those vivid, emotive images? Will you torture yourself trying to create similes "with all the colors of a peacock’s tail"? No.

No? Then how? One word:

Stories

Storytelling is a powerful tool for communication - not mere entertainment, but to carry powerful messages down through the ages. Look at the bible and the teachings of almost all religions. Key precepts, ideas and commands have been passed down over millennia, all through the power of stories.

Think of storytelling in every presentation - even otherwise dry technical talks will benefit from the color of stories. 

If you spend the time, searching, wracking your brain, and struggling to find the stories behind what you are speaking about, you'll gain the color needed to breathe life into your speech. Stories are a proven way to create pictures in the listeners mind. Add color and life without resorting to tortured, overly adjective-laden, purple prose. In addition, a good story, which pits your protagonist against obstacles which need to be overcome - creates natural emotion through tension and release. The story involves the listener in the presentation.

Right about now you are saying to yourself -"yeah right... if it were that easy I'd be doing it all the time". Don't give up on me yet, here come some ideas on finding the stories, which for many are elusive.

Finding your stories

First, ask questions. Look at the who, what and why. Who needs (or needed) to know about what you are talking about? What would happen if someone didn't know about what you are going to talk about? Why would these things happen?

A good story has a main character, the main character has a problem, and the main character works to overcome the problem, the main character overcomes the problem or meets a tragic defeat. If there is a defeat, there had better be a good moral or lesson in the story! 

As an engineer I was asked to give a demonstration to a few hundred sales and support folks. I started to approach the outline of the speech as a simple how-to recipe - first the customer dials into the system, then the system responds with a prompt asking for either a claim number or customer id and then one of two things can happen... and so on. I described the system, flawlessly, but I was terminally bored on first reading. I wanted the audience to want me to stay not wait breathlessly to leave. Then I remembered that the point of the software being demonstrated was to connect a customer and customer service effectively and efficiently. There are people, characters involved. And I already knew that something happens! So, I recast my "how-to" as a story - I presented the customer making the call, the software system and the customer service agent all through role-playing and dialogue. I would step to a different part of the stage for each "character" and made most of the speech dialogue and "stage directions".  With each shift in posture and tone, the audience wasn't just hearing about the system; they were in the call, feeling the customer's anxiety and the agent's empathy. All while telling the story of how the underlying software had made the transaction more seamless and effective by ensuring the call was routed to the correct agent, that fully capable in solving the customers problem.

Second, remember. If this is a technical or how-to speech, look back at when you were learning about what you are speaking about, what difficulties did you overcome to achieve mastery, where did you make mistakes and have triumphs? In essence, make your self the main character.

Along the same lines, if you are going to make an appearance in a story, think about what prompted you to select your topic for the speech you are giving? Were you mad about something? Are you confused or maybe even just quizzical? The answer allows for you to bring a person into your speech, to solve a problem - in short, a story.

I urge you: Don't just present data; breathe life into it. Don't just deliver information; weave a tapestry of stories that will resonate long after the last slide fades. For in the realm of communication, it's not the facts that linger, but the feelings they evoke. Go forth and tell your tales!

Aim Higher

The post "Having Trouble Finding a Job? Aim Higher" really struck a chord with me. The author (Oztech) makes the case that you should lift your sights for a very practical and pragmatic reason - to look for jobs which require more of the worker and are ideally offer fewer competitors. This is reasonable advice.

But, buried more deeply in the post is the message that you need to aim higher in all things - improve your skills to expand your aspirations, work to present yourself better and to take advantage of opportunities and challenges that expand your horizons.

C.A.L.M. when speaking

You strive to be calm when speaking in public, right? Here's why - you want to be:
C.A.L.M.when speaking.

Colorful
Articulate
Lively
Modulated

Yes, it's an acronym, a mnemonic (Professional hazard as I am an engineer by trade and mien.)

An oft-overlooked skill - taking meeting minutes

From Lockergnome, Diana Huggins presents Meeting Minutes 101. This points things to do in preparation for a meeting that make it easier to take good notes and minutes.

I reccomend reading it as she offers helpful points on taking effective meeting minutes - a task frequently done poorly.

I think the article is missing one important point - always be ready to take meeting minutes.

I'm guilty of the "if I ignore it, it'll go away" syndrome. You are too, I'll wager.

I have worked myself into the state of dreading having to take minutes - thus I do everything to be unprepared to do so - all in the hope that I won't have to, someone else will, they won't be needed, etc. and etc. Generally a bad plan - an approach to fail.

Rethinking this approach and instead taking these tips to heart is much more realistic. Here's a way to look at it:

• If I'm going to spend my time in a meeting, then I'm probably going to take notes, since the act of taking notes helps fix the discussions, the issues and my thoughts firmly in my mind.
• Now, if I'm going to take notes, there's really not a lot of difference between the preparations and techniques for me as a simple note-taking participant as compared to a "scribe" (minutes-taker). These tips are in the article by Diana.
• So, my thinking goes, I'm actually ready to "take minutes" for most any meeting I attend.

So where Diana suggests:

"If you find yourself having to take meeting minutes, here are a few pointers"...

Instead, read that as "Since you're always prepared to take good meeting notes and minutes, here are a few pointers..."