Xander Heemskerk

Okay. My name is Xander Heemskerk, and I am not a DevOps or agile salesperson within the company. I am not driving agile sales or agile or DevOps-type initiatives in the company. I am a product security officer, director of product security.

This is the highest waterfall in the Netherlands. I had to Google it, of course, because it is quite a flat country, but there is still some elevation there. The company I work for, Royal Philips, is a company that needs a form of, well, is built up on waterfall-type development of solutions, and therefore also still needs to enforce that to be able to create products which comply with all kinds of regulations.

I will talk about the Philips context, digital transformation in healthcare, Philips solution creation, how Philips solutions are created, the regulatory context, and the adversary and hacker context. I have here "attempts" because when Gene sent around an email and said, if you want to present here and you are not sure, just send it up and we will see if it works, and it does not have to be a success story, I thought: actually I am not sure if I want to present, but I do want to go finally to this conference. I also do not think it is a success story. It is also not a total disaster story. I think we, like many companies, are somewhere in the middle, muddling in the mud.

But we have agile approaches to making waterfall a bit more flexible than it actually is perceived, or is. Then: what do you need for agile security? They were also asking, what are your open issues? What do you still want to have addressed? I have sort of a wish list at the end, but maybe it is too much reaching for the moon.

Who am I? I am Xander Heemskerk. I am the director of product security with Philips. You can see on the website all the details of a lengthy career, more than 30 years in IT. When I started working for a company 37 years ago, it was for a Japanese corporation, Ricoh, over in Amstelveen close by. The boss took me for lunch in Okura, so I had my first bento box in 1986. Indeed, Japanese corporations were the example for everybody in the world, like yesterday was explained. A bento box I had never had before. Now I have had many.

Through those years, I grew up through all the cycles. In the Japanese corporation, everybody does everything. Even the boss did operations. After Ricoh, I worked for many other companies and did sort of everything in IT, from operations to education to solution architecture to programming, et cetera. Not DevOps, because it did not exist 20 years ago, but similar things you did. Actually, the Japanese corporation had similar things like DevOps because you did everything, both putting on the tapes in the mainframe as well as programming the mainframe or programming the PC.

Through those years, I grew up through architecture, solution architecture, into IT security, cybersecurity would be the modern name. Around the career I also did all kinds of advanced development and went through all the flavors of what was the silver bullet, or announced as a silver bullet at the time: do it right the first time, extreme programming, DSDM, feature-driven development, the whole thing. They were always announced as the silver bullet, including agile and including DevOps. Then after a while the realization came that maybe you should not be too religious about and too fundamentalistic about all those methodologies. Common sense still played a role.

The role in Philips is product security: building security into the products and services we deliver to our customers. What I do is govern that business units who create solutions indeed implement the appropriate level of security. Appropriate level should mean definitely not too little, but also not over-engineer and do too much.

It is not about driving agility. It is a little bit like the police officer, the local Dutch sheriff, perceived at least by the businesses, but I try not to be like that. Just to make sure: if there is anything said and it is not in line with what corporate communication wants, this is all my vision and not so much the company's, or all the companies I worked for before.

Philips: yesterday was the birthday of Philips. On the 15th of May, it was 132 years old. It is one of the real Dutch conglomerates, many huge companies. ASML comes out of Philips, NXP, et cetera. It is also an old company, and could be seen as set in its ways, but it has also been very agile in changing its business models. In the seventies and eighties, if you went on television and worked for Philips, people would think of light bulbs from Eindhoven. Royal Philips, the one and only Philips I work for, does not create lighting products anymore. Nor televisions, washing machines, coffee machines, chips, or the chip machines from ASML. That is all produced by other companies, but they still have the Philips logo, so you still recognize it.

Philips reinvented itself as more or less a medical company. One part of this huge conglomerate is now focused only on medical solutions. That is from big iron MRI scanners and image-guided therapy to, in the area where I govern product security, wellness and softer medical solutions: connected shavers, connected toothbrushes, apps for pregnancy, milk-bottle measuring. For me it is interesting when it is connected, so it is all that type of connected solution. It is still a huge company. It used to be bigger, 30 years ago 400,000 people, but it reinvented itself as a smaller and leaner type of company.

Medical solutions have what we call a digital transformation or digital revolution that is increasing complexity. Solutions consist of loads of interoperability. There is IoT: connected shaver, connected toothbrush, connected everything; a connected MRI scanner for maintenance; a device connected to an app through Bluetooth and then from the app to a backend in the cloud. In the cloud there is data collection and AI-type analysis. For baby cameras, there is sound analysis, cry analysis, analyzing if the baby is hungry or needs a diaper change, and that is actually a meshed cloud sub-solution. The app connects to all kinds of things in the cloud.

There are all kinds of collaborations: business to consumer, business to business, business to business to consumer, business to government, and a hugely complex supply chain: open source, commercial off the shelf, OEMs, ODMs, finished-good suppliers. Any fashionable way of creating products is also part of the ways Philips creates solutions.

Because we are a medical device company, we are also in a highly regulated environment. That means the FDA, the CFDA, which is the Chinese FDA, because we are also big in the Chinese market, as well as EU MDR, the EU Medical Device Regulation. You have to have a QMS, a quality management system. I joined Philips seven years ago, and this was the first time ever I experienced a quality management system. Here it is really written down in detail what a process needs to look like and who needs to do what at which moment. It can be audited by the FDA. The FDA will come up and say: what do you have in your QMS? Show me that you have actually done that.

What all companies in medical devices have, or should have for the FDA, and most do for the Chinese and US markets, is a V-model. It is like a waterfall going both down and up. It says you have got to get your requirements and then later check if they are implemented. It does not really have the feel of agile.

The QMS describes definitions of what the process must look like: formal specifications of security and other requirements, as well as security-quality requirements. It must be validated at the end. The FDA can audit your QMS against what you actually have in place. You have a design history file, and you need to describe the full product lifecycle: pre-market, meaning before you create a product, and post-market, meaning how you are going to manage the product throughout the lifecycle. Do we have the people ready to create patches, analyze vulnerabilities, et cetera? If the businesses are moving to an agile way of working, those people need to be agile in addressing those aspects.

If we are talking about agile and short cycles, for hardware, IoT, and finished-good suppliers, that is complex because they need to know how the plastic is going to be molded at the beginning. That trickles down through the whole development.

We create across the globe. This is the Zimmer Tower in Lier, Belgium, with the different clocks. It is globally distributed development. Everybody is in their own time zone. It is optimized for cost. IoT comes from China. The software from Bangalore or Pune is designed often in the US or the Netherlands. There are also all kinds of developments in Israel, et cetera. They are all in different time zones. It is very hard to get them all in a room together. It is also very hard to share a pizza with them if we want to do some selling; plus, not in all geographies do they like pizza. India does not always like pizza; in China they think it is a snack for in between, but not really a meal. That complicates development, getting together, and building up the relationships necessary for an agile way of creating products, or actually governing product security. Hence, Conway's Law for agility: how we are organized is how we create products.

What comes out of agile is self-organizing teams. When the agile development team is religious, they say: we want to be self-developing, self-controlled, because we go faster and we do not want to be bothered with you. What you cannot have, or what makes it very complex, is self-approving teams. You will quickly get developer bias. I have been a developer also for 20 years. You do not see the flaws in your own code. It cannot be good: it worked at my station, so why does it fail there? The idea that some hacker could break it is too difficult for them or not something they think about in general. I am generalizing, but that is a usually complex aspect.

Therefore you do need some outside governance. You need a person outside of the team who says, if we do some threat modeling and look at this, I think this and this can go wrong. You need some testing from somebody outside of the team to explain that it is not just the happy flow. There are also unhappy flows possible if you put it out in the wild, on the internet.

We also have increasing regulatory obligations. Product teams already need to comply with so many things, but then they also get extra laws. Regulators and governments have seen that if we leave it to the market, the market will do whatever it wants. That is similar to leaving it to development teams: they do what they want and approve their own stuff. If you leave it to companies, they will not follow the regulations, or will do only exactly what is necessary and see what they get away with.

The regulator recognized that. If you see the equivalent with GDPR, that has been a huge improvement by putting in the fines and really checking things. You will see that across the board of cybersecurity laws: checking things and making sure. You get ship-hold monitoring. If a product has exploitable vulnerabilities, you are not allowed to put it in the market anymore. This is upcoming regulation, not in place yet, and the market is working on fine-tuning those kinds of regulations. But that would be a huge impact. Zero vulnerabilities, or zero exploitable vulnerabilities, would be almost impossible to release against. The caveat is that in the market and in newspapers, exploitable and vulnerable mix quickly; it already becomes an incident while it is actually just a vulnerability.

The Software Bill of Material is also from Joe Biden. If you want to sell to the US government, you need to explain everything you have in your product. From a developer or engineer point of view, that sounds logical: you know what you have in your product. But modern development is a lot of downloading from all kinds of websites, putting it in there, and seeing if it works. Later on they are asked what is in there, and they have not registered all this. This also has a huge impact. The biggest customer of Philips is the US government, the Department of Defense. The second biggest customer is the VA, the Veterans Association. If you want to deliver something to the federal US government, you have to fully explain, including down the whole supply chain, what you have in your product. That means rigorously checking and governing how you build your solutions.

Regulators want to see the evidence that you are indeed following secure software development lifecycles. The FDA is also focusing on threat modeling and the evidence of threat modeling: really looking at your architecture, but also at your company structure, and seeing what can go wrong and how to address that and make those your requirements. Steps in the SDLC include static code analysis, security testing, and risk management. All of those need evidence. You communicate with regulators by creating documentation. That is seen by agile teams as a burden, as an impediment of fast delivery, which business leaders and developers want.

The consequences are that ship-hold monitoring and zero vulnerabilities reduce your risk-management negotiating power. Risk management is, for me, the way to still have teams develop things while there are vulnerabilities. You can say: these types of risks are acceptable; they are within our risk tolerance and risk appetite. But these things are above. If you still want to release, then someone higher up in the food chain, not you, not the project manager, not your boss, but the boss of your boss, if they say these are acceptable risks, then we can go forward, acceptable from a business point of view.

With ship-holding for vulnerabilities, that is hugely reduced. It will make me more powerful, but I actually do not want to be Dr. No, because you do also want to create products. I still want the company to thrive and sell things. But with zero vulnerability, somebody has to say: this is not acceptable. In most companies I worked for, that lies with the product security or security officer. Business leaders are the ones who look at the different angles, both the benefits and what can go wrong. But if ship-holding becomes a legal obligation, then there is no other way than becoming Dr. No.

Another context: hackers are extremely agile. They can do whatever they want, and they can focus all their time on breaking one thing while the company and security have to defend all the aspects. That does not just come from hackers or adversaries, but also from security investigators: people who look at the vulnerability, do a CVD, coordinated vulnerability disclosure, and say you have 60 days to close that. If you do not, then I will go to a hacker conference, a DEF CON or Black Hat type of conference, and then it will be publicity. Reputation-wise, that is often even more risky than an actual hacker because there is much more publicity.

I have to refer to this one. It is from The Sun and excellent for getting a catchy phrase. It is only a vulnerability, right? It says here a security investigator found out how they can break it, but it is brought as if the pacemakers are already broken. That is how it goes with reputation. Definitely with any kind of cybersecurity thing, a vulnerability, which is just a weakness, will be translated in the popular press as an incident, as things already happening. That is a risk we need to cater for.

How can we still, in an agile way, add some agility and Dev to this whole waterfall process? The regular stuff: automating static code analysis in your CI/CD pipeline, automating SBOM, bill of material scanning, using products similar to the Sonatype product, building up a repository of where it is. Then when there is a vulnerability, you go to the repository and say this vulnerability is in these products. That is also what Joe Biden's law wants: as a customer, quickly be able to see whether there is Log4j in your product and these products, and you will have to take an issue. Now products are delivered, but customers do not know they have Log4j because their supplier has not told them. We need to start telling that. An automated SBOM library will at least make it more agile, or faster, to create those.

Then DevSecOps security testing. We have a separate group of security testers in Bangalore who will take the product. They are not part of the businesses. They take the product and, like a hacker, look at it and see how they can break it. Security ninjas, as we call them. It is beneficial to also have similar people with similar skills already in the pipeline who are not just doing the automated testing, but are semi-part of the product, while also still having some independence to call things out. Why do you want independence? Because you do not want a boss to say, this vulnerability is fine, for the moment we are going to do something else, or we do not think it is that important. You want that independence, but also for them to quickly do security testing while the product is not really finished yet for final testing. It reduces the cost and the time, which is why business units do not want the full-time testing. It reduces the amount of time needed for the full testing.

But you still need the independent testing. That is for regulatory approval. You need to be able to show that a team not part of the business has looked at it in an independent way. Again: self-organized teams, not self-approving teams.

The agile way to add security to DevOps is the risk context, or risk management. It is technically the agility lubricant. It makes it possible for me not to be Dr. No, and to still go on but still have risks managed in a certain way. Of course, when there are safety consequences, which you could have in medical devices, the risk tolerance is much lower. The bottom point comes from Kevin Fu from the FDA. In risk management, you look at probability and impact, and multiply them. That is the actual risk. But with cybersecurity incidents, what he states, and I think it is a good point, is that an adversary, a hacker, will work 100 percent of his time on just this 1 percent probability of exploit. That changes the dynamics, definitely also the metrics in doing the risk calculation.

Security also requires agility. Teams come to me and say: you must be more agile, we want more flexibility. But I also want flexibility on their end. Many teams are working with QMSs where requirements are set up and in the end tested if they are implemented as they are set up. But through hackers and vulnerabilities, the requirements can change at any moment. I am the messenger that the goal posts are moving and that they need to not work on this feature now; they need to immediately start working on Log4j. That type of agility is what I want from them. It is not a one-way street. They want some agility from our side, but we also want them to work agile on security issues that are found at any moment. "We scanned it yesterday." Yes, but today you could have a vulnerability that was not scannable yesterday because the vulnerability is found today.

So you need to keep people on the bench, or the businesses need to be aware, or reduce the number of features you can put in. Agile security: one of the statements from the Agile Manifesto is individuals and interactions over processes, but that does make everything negotiable. They say they want individuals, yet they keep on buying and selling: if we do this, is it then fine? That makes security often in the trenches of a constant negotiation and handling of risk analysis. It can be perceived as subjective. They say, we do not see it like that. Hence independent testing is useful, because it gives an authority if something is actually an issue. With legal, privacy, and regulators, that makes it a constant negotiation.

With businesses, the tactics I use, or I see them as agile, are choice architecture. If you do not want to do this, then you will have to get sign-off somewhere higher up in the food chain, up to the highest level depending on the type of risk. There is also social engineering going up and down. They try to social-engineer me by saying, if you do not do it, then we cannot deliver. I do it the other way around. It is hardball governance. At some point you must be able to say: this is not acceptable, and you actually need to do this in a different type of way.

That brings me to the open issues, as asked for. This is the last bit of the dike which made the South Sea into the IJsselmeer, another big protection for the Netherlands. Agile quality management: I did say it was a wish list and maybe a shot for the moon. Agile change management also. I think there was a hint this morning on how to do that: change management for large populations. I have many teams. I could do experiments with one team and say, make it a bit looser depending on the type of solution and the context, but before you know it, they all say, we also want what the other team has; we also do not want to have to do the testing with the security center of excellence, the expert group; we want to only have the DevSecOps team. When I did an experiment to see to what extent that would work, that makes it very complex with a big wheelbarrow full of frogs: when they are all in the wheelbarrow and I say one of them can go out, they do not all jump out and go different directions. That makes hard governance necessary again.

That is my final on this one. Any questions?