There are some interesting influences on medical devices related to cyber security (yeah, I know, cyber. Common parlance is common parlance.) that you may or may not be aware of. I am not saying that medical devices are special snowflakes and nobody else knows our pain, but there are some things that are worth mentioning when we talk about cyber security in the context of medical devices.

Today we will explore the co-dependent trilogy of patient safety, validate state, and cyber security.

Patient Safety

Let's start with patient safety. Patient safety is paramount when we are talking about making changes to medical devices. This is especially true for devices that can kill or seriously harm you like infusion pumps and x-ray machines. It is less so for things like ultrasound machines and blood pressure cuffs. However, this is always the first question that must be asked when we start to make a change for security purposes. Will this increase, decrease, or be net neutral from a patient safety perspective.

Note: There is an underlying concern about usability that sneaks in to patient safely. It relates to making sure the device can be used in a situation where time lost using the device can equate to harm to the patient, i.e. can't get an x-ray quickly enough because of poorly designed security controls which means the surgeon doesn't know exactly what to do and the patient dies.

Validated State

Validated state. What the heck is that? I had no idea before coming to work for my current employer. The validation process performed on a medical device is when the manufacturer implements procedures to ensure that the product

"meet[s] specific requirements for identity, strength, quality, and purity. In order to comply with cGMP, companies are required to record, track, manage, store and easily access various production documents and their detailed change history including Standard Operating Procedures (SOPs), Master Production Batch Record (MPBR), Production Batch Record (PBR), Equipment log books etc."

That quote is taken from this page. If you really want to punish yourself, you can read the actual FDA guidance on this here. What does that mean in regards to real life and cyber security changes? It means that for every change to a medical device, the manufacturer MAY be required to perform a complete validation cycle. These validation cycles are expensive and time consuming.

Luckily, recent pre and post-market guidance from the FDA have clarified some things directly related to security updates that allow for a less strenuous validation process and there has always existed the possibility for a less intrusive process to be performed referred to as verification.

Cyber Security

This brings us to cyber security. Cyber security engineering for medical devices, as in all development, is best done early and often in the development process. This ensures that patient safety concerns are constantly addressed and the device's security stance is inherently included during any validation efforts. That takes care of development. Simple, huh? Of course, as the saying goes, "Simple doesn't mean easy."

What about security patching? If it can be demonstrated that the installation and/or configuration change being made does not affect the intended use of the device, a full validation cycle may not be needed. However, if it does, then validation must be done. This is a contributor to why you will see what appears to be rather long patch release schedules for some medical devices.

This is my no means a full treatment of these topics, but I thought it was worth a few words.

Questions? Comments?


{ 1 comment }

The last time I posted on this blog was March 13th, 2013 immediately following my last public speaking engagement at an information security conference. Who was to know that a year later I would be done with enterprise security and working in a totally new vertical? Certainly not me.

In May of 2015 I started working as a product security consultant for a major medical device manufacturer assisting a variety of medical device engineering teams. My scope and focus moved from the abstract 50,000 foot view of enterprise security architecture to deeply technical, in the weeds work with  those engineering teams developing design inputs to move medical devices security forward.

To say that it has been a massive learning experience is an understatement. However, it has also been extremely rewarding. I work in a space where we are making changes that have real positive impact on the safety of human beings and the protection of the information they share with their healthcare providers.

I perhaps have a blind spot, but the mass of communication I see online seems focused rather stridently on how bad things are and how medical devices are the next blah blah blah we're all gonna die blargle blargle blargle.

Are there bad things happening?

Of course.

Are medical devices a bit (lot) behind the times when it comes to their security posture?


However, there are some of us out there making changes and trying to move the needle. To that end, I'll be offering some thoughts here and there about what I see happening and what kind of changes are occurring.

I hope you find it interesting.

To that end, I am always happy to focus my attention in places where people have questions, so leave a comment mentioning things you are curious about related to medical device security and I'll do my best to speak to them.

Until next time, hopefully not three years from now, later.

{ 1 comment }

The following question, paraphrased, came up during my RSA 2013 presentation on why an Enterprise Information Security Architecture (EISA) matters:

Do you factor in threats when developing your EISA?

My initial response was essentially "no." The person who asked the question came up after the presentation and wanted me to think about that response.

Fair enough. I have been. Quite a bit.

I am going change my answer to "yes", but I want to qualify that a bit.

The primary qualification I want to make is scope. We need to be aware of the threat environment when designing our architectures, not necessarily the detail. While we need to understand the environment our enterprises are operating in from a broad perspective, we do not need to keep track of specific actors or threat actions at this level.

For example, when an architect is designing a building for an environment where tornadoes are common, he has to account for that in his design. However, he doesn't focus on architecting for a specific tornado. He can't.

Here's another example. If I am designing an EISA for a financial institution, being aware of the criminal element is important. Tracking exactly which group is using which malware is not, at this level.

I do want to make a huge plug for threat intelligence at the operational level though. Understanding who is operating against you, what they are doing, and the tools they are using is hugely valuable in tailoring our monitoring and response tooling.

So. Where does the threat environment information get captured?

In our context map. I didn't talk about context maps, and a whole bunch of other stuff, in my talk. I will be in future blog posts, but the short version is that the context map is a way to capture and represent the influences that make up the context our EISA will be developed in. "Understand the Business" is a big part of this context. Threat environment is another. There are many more influences.

So there it is. I flip-flopped.

What say you?


PS - To the person that asked the question, thank you!



On Friday, March 1st, 2013, I delivered my first RSA USA talk. It was a 20 minute talk on the need for and the value of an Enterprise Security Architecture. In addition to extolling the benefits of an EISA, I also provided a high level description of what one should look like and a quick blue print of how we go about starting down the path of developing one. Below is the text of the talk. I tend to wing it a bit during my talks so it is not a verbatim transcript, but all the thoughts and ideas are there. You can download the here, if you wish.

Winchester House Security:
Why Enterprise Security Architecture Matters


Oliver Winchester made his first fortune in the clothing business, but is best known for establishing the Winchester Repeating Arms Company which produced the Winchester Repeating rifle, referred to as the “Gun that won the West.”  He married Jane Ellen Hope in 1834 and they had three children, Ann, William, and Hannah. When he died in 1880, he left the company and his fortune to his son William.

Sarah_WinchesterUnfortunately, William died of Tuberculosis shortly after his father’s death and 50% of the company and an income of $1,000/day, roughly $22,000/day in today’s dollars, passed to Sarah, his wife. Legend has it that Sarah visited a medium who told her that the spirits of the dead killed by Winchester rifles were angry with her family and that’s why bad things were happening to them. The medium further told her that she must move west and build a house for herself and the spirits. Sarah took this advice, moved to San Jose and began construction of what is now known as Winchester house.

WinchesterHouseConstruction began in 1882. Fueled by her belief that the spirits were angry with her family, the words of her medium regarding what would happen if she eer stop construction on the house, and effectively an endless income, construction continued 38 years, day and night without any apparent overarching plan or architecture.

In summary, someone with a lot of money decided to follow an unusual belief that led to 38 years of perpetual building… without a plan. Does that sound eerily familiar?

So what does a house built over the course of 38 years, with lots of money and no plan  turn out like? StairsWell, rather chaotic. There are stairways that lead to nowhere, doors that lead to a…. Doorrather large first step, a long fall and a rapid deceleration.  There are  purpose specific rooms that never get used, a floor plan that, well, isn’t, and a lack of any real idea of exactly what’s what.


So, let me ask you the these questions:

  • Do you know exactly how everything used to secure your enterprises fits together?
  • Do you know everything you have?
  • How about this? How many of you have a complete set of solutions that all talk together?
  • Do you have some solutions that don’t talk to anything?
  • How many have multiple solutions for the same purpose, but not on purpose?

Kind of starting sound like we may have some of the same problems as the Winchester Mystery House.

So what’s the moral of the story?

Whether building houses or security, building without a plan – in other words, an architecture – leads to a real mess. Lets use the lessons of the Winchester house to focus on the needs of security.

Think about the value architecture provides:

First it establishes   a comprehensive view of where we are, or our current state. It’s really hard to figure out how to get somewhere if you don’t know where you are in the first place.

Next it provides a future view of what we want our security practice to look like, a target state. In the rare event the current state and target state are the same, it’s time to celebrate. How many here are in that position? Stand up so we can all celebrate.

The rest of us -- most of us -- have things that we want to change;  the target state is different than the current reality.

Once we have those two states defined, the rest of the architecture helps us define the path we are going to take to get from here to there. In some cases, there will be intermediate states that are worth documenting, but not in all cases.

In the case of information security, we will refer to this plan as the Enterprise Information Security Architecture. It is the guiding plan on how we are going to secure our enterprises. It does several good things for us.

  • It describes the risk posture of the organization based on the over-arching business strategy and drivers. Without this context, we are incapable of making informed decisions on how to implement security controls.
  • It builds on the current state and the target state.
  • It includes/requires a gap analysis between the two states and finally, and most importantly, produces the roadmap to get from here to there, from current to desired/target.

There are five major goals to keep in mind:

First, the architecture needs to be business driven. We are not trying to do security just to be doing it. The goal is to support and enable the business to get done what they need to get done. That means we need to understand what that means. More on that in a moment.

Second, our architecture needs to be a top-down plan. Moving from higher levels of abstraction down to more detailed directions. Think of how a building is architected. We don’t start by architecting the bathrooms. We start with the gross building features and move to greater levels of details as we progress .  Just in case the fact that we BUILD buildings from the ground up, starting with the detail, getting more ‘abstract’ as we go, is crossing your mind, remember that we are talking the enterprise architecture. The work that guides detailed level implementation is solutions architecture which is used to realize the enterprise architecture we define.

Third, it needs to be structured. It needs to flow appropriately.

Fourth, it needs to employ appropriate levels of abstraction. At the enterprise level, describing the details of how of the security settings for our browser of choice is going to be counter productive. At the enterprise level we would describe the need for a secure browser. Again, later solutions architecture work will get into the specifics.

Finally, it provides a common language for discussing the information security work of the organization.

As just mentioned, the first thing we have to do when we start down the path of building our EISA is to make sure we understand exactly what the business is trying to achieve.

This goes beyond just know that we are a bank, or manufacturing plant, or a pick your business type. We need to understand, specifically, what drives the business.

That means we also need to understand the business's goals AND the strategies the business plans to use to reach those goals.

Of all the things we can do as information security professionals to help the business, understanding their goals, drivers, and strategies will arguably gives us the biggest bang for the buck. If nothing else, it shows the business that we are engaged in what they want to achieve.

Now that we are on the same page as the business, we need to understand the business's key processes. This will drive out where the data is, who needs to get to it, and, most importantly, how they need to get to it.

The final bit we need to work on with the business to understand is what their risk tolerance is. That bit right there is hugely important. Without understanding what the business is willing to risk, we cannot provide appropriate levels of control.

With a good understanding of the business, it’s time to get to the nuts and bolts of building the architecture.

The first step is defining  the principles that are going to drive the development of the architecture. Principles are the underpinnings of our architecture. They are informed by the business understanding we have. One warning, principles are not policy. Principles are fundamental stakes in the sand which should be non-negotiable. Well, maybe not non-negotiable. What is ever non-negotiable in what we do? If you are looking for a good start list of principles, check out The Open Group's Enterprise Security Architecture. It has a really good list.

The next step is to build out our current state. In many cases, if this is the first time an enterprise architecture has been attempted, this will be at the physical level. This is entirely acceptable. This can be both the easiest part and the hardest. Finding all the bits and pieces that need to be included can certainly be challenging. However, this is a vital step and will provide immense value to the organization if you just stop here. Wouldn’t recommend that though.

The next bit is a where we get to cheat a little. There are myriad sources for reference architectures that we can leverage as guides as we develop our target architecture. Reference architectures are idealized architectures that have already been worked out. They obviously have to be fairly abstract, but they can be very helpful in making sure we don’t miss any of the big pieces.

Finally, we take everything we have done to date and describe our target start architecture. At the enterprise level, we will likely stop at the conceptual level, maybe dipping into the logical level a little, when describing our target architecture. The work of further logical detail and physical architecture deliverables will be driven by the roadmap we will discuss next. I do want to urge everybody to not get caught up in letting the current architecture drive the target architecture. There will certainly be influences from the current state, but don’t let current state back you into a corner.

Whew! We know where we are. We know where we want to go. Now the hard part. Getting from here to there. The first thing we need to do is figure out where the gaps are between our current state and our target state. This gap analysis will drive out the work we will need to undertake to move us towards the end goal.

Once we have our gap list and have identified or described the work that we need to undertake to move us along, we need to build roadmaps that give us the dependencies and help drive out timelines and milestones on our journey.

We also need to derive the metrics we need to have in order to track our progress. Have metrics that describe how effective we are at implementing our new architecture is vital to the success of the effort. The only way to know if we are changing things is if we can measure them.

In summary, chaos is bad. Systems, solutions, and controls implemented willy nilly will surely provide some level of security…maybe, but certainly not in the most efficient and effective manner.

We need a plan. We need all our security systems, solutions, and controls to work together holistically.

We need to understand how we are going to support the business in achieving their goals while making sure that vital business processes and data are protected appropriately.

Finally, we need to be able to effectively describe how we are going to get from where we are to where we need to be through gap analysis and roadmaps. All the while, being able to provide measures that demonstrate progress.


The Open Group Enterprise Security Architecture

Sherwood Applied Business Security Architecture

Image Attribution:

[1] Oliver Winchester - Wikimedia Commons - Copyright expired link
[2] Sara Winchester - Wikimedia Commons - Copyright expired link
[3] Winchester House Roofs - Photo by nhanusek - Creative Commons - link
[4] Winchester House Staircase - Photo by InSapphoWeTrust - Creative Commons - link
[5] Winchester House Door - Photo by HarshLight - Creative Commons - link
[6] Blueprint - Wikimedia Commons - Photo by Adrian Michael - Creative Commons - link


Just a quick note to let you know that I will be speaking at RSA USA 2013 in February. I'm pretty excited about it.

The title of my talk is Winchester House Security: Why Enterprise Security Architecture Matters

It's a quick 20 minute exploration of how we manage to end up in a place where:

  • We don't have a good idea how everything fits together.
  • In some cases, we don't even know what we have.
  • Things don't talk to each other.
  • Things don't talk to anything.
  • We have unintentionally repetitive solutions..
  • Etc.

Just so I'm not a complete Debbie downer, I'll also share how you can get started on the path to building an Enterprise Security Architecture which helps us avoid the things listed above.

I'm speaking at 11:40 on Friday in Room 309.


{ 1 comment }

Infosec and the Value of Twitter

by kriggins on December 13, 2012

in Career

The title to this post is a bit of a lie. Well...not a lie so much as a bit restrictive. The value of Twitter I am referring to is that of community and mutual support.

I have a friend, we'll call him Bob, who is somewhat early in his Infosec career and had some questions. He was looking for some advice.

He reached out on Twitter asking if anybody would be willing to chat with him about his situation. We spoke last night, but this is not about me. It's about how with one simple request, Bob was able to have chats with five additional people, all of whom I know and respect.

How else would a relative newcomer working for a small company have been able draw on the experience of well-established professionals in a range of industries spread across the globe?

Community, mutual support, knowledge sharing, and, yes, occasionally a kick in the pants. These are the things that the Infosec community on Twitter offers. All you have to do is be willing to be a part of it.

So. The next time someone says you are wasting your time on Twitter, just nod your head, smile a private smile, and move on.

You know different.

And that's all that's important.

To my friends that helped out Bob; Elizabeth (@elizmmartin), Michael (@catalyst), Michael (@securitymoey), Brian (@brianhonan), and Kai (@kairorer), thank you for being who you are.

To the list of people that have helped me over the years I've been on Twitter, too many to name, thank you for being who you are too!


PS - You should follow those folks!


Veteran’s Day: Thank You!

by kriggins on November 11, 2012

in General

There are several times every year when I think about the armed services of the United States. Days like Independence Day, the anniversary of D-Day, the anniversary of the attack on Pearl Harbor and others. Many times, I have wanted to let the people who serve our country in this manner know how much I appreciate that service.

On occasion I have had the opportunity to walk up to a serving member of our armed services, shake their hand and say thank you for your service. Nearly every time, the reaction is one of surprise followed by gratitude. It deeply saddens me that the first reaction is surprise.

The men and women who serve in the Armed Services of the United States of America deserve our gratitude and our respect. It is through their sacrifice that we continue to experience the freedom and security we have.

Today is Veteran's Day in the United States. I urge you to find one person who is serving or has served in the armed services and thank them. I will be. Let's make today a special day for these people to whom we owe so much.

To all those who serve and have served to guarantee the freedom and security of the United States of America, I thank you from the bottom of my heart. Your sacrifice is greatly appreciated.



USB Stick of Death: Not Really Low Severity

by kriggins on October 22, 2012

in Uncategorized

On October 21st, 2012, Mateusz “j00ru” Jurczyk, published a blog post describing an exploit he developed which allows one to execute a privilege escalation attack on Windows 7. The attack results in one having SYSTEM level permissions on the machine. SYSTEM is the highest level of permissions one can have, even higher than administrative permissions.

You can read the details about the exploit here. I Suggest you do read it. It is very interesting.

In the post the following statement is made:

...requires the attacker to obtain physical access to the machine and have a local user in the system. Consequently, the only scenario in which it might be a problem security-wise is a local computer shared between multiple users with restricted privileges (e.g. schools, universities, hostels) and thus has been rated as low-severity by both us and MSRC,...

Let's see. Where else might there be situations where this might be of concern? How about any organization that restricts its users from having administrative privileges on their workstations.

Wait, you mean there are places that enforce least privilege on their users?


I work for one. I also know of several government entities that also restrict administrative privileges for most users.

Color me crazy, but I'm pretty sure those organizations would not consider the ability to easily elevate privileges as a "low-severity" vulnerability.

Just sayin'.

What do you think?



My apologies to my readers spread far and wide, but this particular post is targeted at those who are near Des Moines, IA.

Tomorrow night, Thursday, October 18th, at 7:00 PM, Merian Merrit, Norton's Internet Safety Advocate, will share  the latest information about what young
people are doing online, the real concerns parents should have, and actionable strategies and tips for getting technology under control. From social networking to sexting,
and from cyber bullying to cybercrime, you’ll walk away with a new plan for helping your kids learn to use technology wisely and safely.

The event is being held in the Learning Resource Center at 3550 Mills Civic Parkway, West Des Moines, IA.

More information can be found in this PDF: Internet Safety Event



Upgrading my Theme

by kriggins on October 12, 2012

in Announcement

This site uses the Thesis theme. I love Thesis and am going to continue to use it. However, the latest version, 2.0, is significantly different than the previous version.This has the potential to make the 🙂

I hope the change is somewhat seamless, but you just never know.

Please be patient.