This video was brought to you by my patrons. Thank you so much for your support We may have all the instruments and the tracks everything is structured Which was what we did in the previous video. It's time to mix and match our song Oh, we stay turned to the end of the video because I have a tip for those who want to go deeper in the arts of mixing and mastering Well mixing is the process of picking all the instruments the facts everything and Well mixing it all together so that they make sense within the song's context We are going to approach mixing as if each instrument were an actual Instrument the physical instrument like in a an orchestra for instance And our audience the listeners will be right in front of the stage listening to everything together Well picture there for a moment imagine a stage with all the instruments And how the the disposal of each instrument will affect how the audience will experience each Will experience the whole song So if an instrument plays on the left the how this will affect the audience if an instrument plays Right in front of the audience how this will affect their experience This is how we are going to approach that in that sense since the analog bass is a bit too low We are going to increase its volume bringing it right in the front of the audience But we are also going to move it to the left because this will allow other instruments to Still have some room to breathe and to play together For instance, we are going to to use the analog filter. We are going to pan it to the right instead We are not going to move it to to the front We are going to keep the volume as it is but we are going to move it to the right So we can take some of this room left from the bass The synth path is already loud enough and since it will be performing a solo it already takes the room It needs to shine so we are going to move it to the back of the stage by decreasing its volume Now the drums need a lot of adjustments Firstly, we can move them to the back of the stage because they are taking a lot of the room available So they are too loud for us And we are going to decrease both the kick and the snare volume especially the snare let's decrease it by 50 percent Since this snare is way back in the stage naturally it will reverb a lot more So let's increase the wetness of its reverb effect, which was a fact that we added in the previous video The kick though is still sounding way too loud. It sounds like an 808 or something This is because the lowest frequencies are still very high. So they are giving a long tail to the to the kick like boom And this is don't let other instruments to to breathe a lot. So we are going to add a equalizer to fix that An equalizer is like an advanced filter. It has some frequency specific knobs Each affecting a different frequency range, which allows us to smoothly cut off some frequencies while still boosting others An equalizer is another tool that we can use to design our instruments To give a snappy punch feel to the kick We are going to move the first knob of the eq to the right so we can cut off some lower frequencies And we are also going to attenuate this effect by decreasing the resonance So we get a smooth curve to really prevent the drums to go beyond a range We are going to add them a limiter effect To both the snare and the kick and to do that to both of them We are going to use a mixing table In the previous video we saw how we can apply effects to each instrument individually But using a mixing table we can group instruments together and apply a given effect to all of the instruments inside this group We call these groups channels You can add a new channel by clicking on the plus button on the right of the mixing table We can create a new channel, let's name it, I don't know, drums and send both the kick and the snare to this same channel Then we can add a hard limiter to this channel Effects chain and this will make so that this effect will apply to both the snare and the kick Oh, just so you know limiters are effects that work by decreasing the Volume of frequencies that go beyond a given threshold, a given volume So this is perfect for what we need because limiters don't clip the frequencies They attenuate the frequencies keeping them all within a given range Now that we have our drum set we need to open some room for them during the music We can do that by lowering other instruments volumes right when the drums kick When we have that kind of situation where the volume of some instruments is linked to another instrument, we can use side chaining To understand how side chaining works, you need to understand how a compressor works first because a side chain is a compressor So a compressor is a type of effect that will compress the Instruments the effects the frequencies within a given dynamic range So anything that goes beyond it will decrease anything that is still low is lower than the given range It will increase it will boost its volume. So everything will capture within the same average volume This is how a compressor works a side chaining uses this effect apply this effect based on another signal So for instance when the drums kick we will compress other frequencies So the drums will have some room to breathe We can create a new channel to bundle the analog instruments So the analog bass the analog strings and the analog filter all together And then we can apply the side chain compressor effect in this channel But now how can we make the kick control the side chain? Well turns out that we have an effect called pick controller A pick controller basically takes whenever an instrument plays It will send a signal to a controller a control and we can use this control to Control any property of an instrument or an effect So we are going to use this pick controller to control the side chaining levels But here goes the trick to side chaining on synth wave on synth wave the side chaining is Asynchronous with the drums we can't use the same signals because On synth wave the side chaining will work on every music step. So it works like Not together with the drums because we have some drum rolls We have some snare rolls and we don't want that to interfere in our side chain So for that we are going to create a new instrument based on the the kick And we are going to add this pick controller to that new kick and we are going to play this kick on every music step Now we can assign this pick controller to the side chain's level knob By tweaking it a bit we can fine-tune how it will affect the side chaining and get exactly what we want Mastering is usually the final step of music production. It is when we add equalization to the whole song We add some compression as well to keep everything consistent Some limiters to prevent some loudness and get the song ready for exporting I don't know if you noticed but since the beginning that was a default channel on the mixing table You can try to remove it, but usually you can't This is because this is the master channel Every instrument and other channels will send a signal that will end up in this channel the master channel And the master channel will send the signals will send the song the whole song built up To the output of the computer to the audio output The process of measuring is called this way because usually you are working with this channel with the master channel In the measuring process since we are going to try to make everything sound good together Is usually a good practice to Visualize the song so we can see if there is any frequencies that are lacking some volume or if something is too loud For that we can use a spectrum analyzer a kind of effect that will plot the song Using the frequencies a and the loudness and using that we can analyze the song visually So we are going to use two spectrum analyzers one for the raw song and one for after we apply every effect Then we can add an eq an equalizer to boost some middle frequencies and attenuate the others Especially the lowest ones and the highest ones Here is where compressors the common compressors are also useful We can add an a compression to keep everything within the same dynamic range to keep every frequencies sounding Uh on average the same way and also we are going to add a hard limiter to prevent any clipping and any loudness Well with that we have everything ready to be played without fearing of hurting anyone's ears From here you can add more effects to your song to make it feel more dynamic For instance, I created a new channel an equalization channel with an eq effect on it And I send the output of the sidechain channel to this new channel to the equalization channel And also I send the output of the synth pad to this equalization channel as well After that I automated the eighth channel of this effect of the equalization to cut off some high frequencies until we get Only the lowest ones. So we get this very basic song And I also automated it to quickly release all the frequencies all together to give this wavy effect Guys everything that I showed you in this video is just a tiny bit of what I learned from young gurus master classes on skew share If you want to push your song to the next level to a really Professional level I've put two links one for each of the classes that I've watched to make this video On the description you can use them to get 14 free days of premium membership on skew share instead of the usual seven days So that way you can enjoy these and hundreds of other classes on skew share. I really hope you enjoy it For this video, that's it. I really hope you enjoyed Subscribe now to get more of this content. Don't forget to leave a thumbs up as well So I know that you enjoyed and join our discord community there you can chat about everything related to game development That's it. Thank you so much for watching keep developing and until the next time


Great. So, the topic that we are presenting today is securing microservice interactions in OpenStack and Kubernetes. So, it's going to be presented by Yoshio, my co-founder and I who started Banyan like two years back. So, just one slide about Banyan and I won't bother you with it anymore. So, we were founded in 2015 in San Francisco area. We come from VMware and HP Labs and a PaaS company called MooWeb and we've done a lot of work in virtualization, network security and big data and we were incubator at Stanford, Stardex and our product currently in private beta. So, if you guys have questions, happy to answer that after this. So, before I go to the outline, the show of hands, how many of you are actively using Kubernetes or containers right now? Okay, great. Good to know. About 50% of the audience.  We're going to talk more about what are microservices, why is it creating a new type of attack surface and how the existing solutions that are there, both in OpenStack and Kubernetes, are trying to address it and why. We'll go over as to why that's not at the right level for a lot of reasons if we want to, that it will become clear. And then we're going to talk about a new approach that we think was the right way to go about it moving forward and we'll show a simple demo of what we have as a prototype and then a conclusion and discussion about it. So, introduction. So, what are microservices? So, microservices is a kind of software architecture which takes basically big applications and lets you break it down into small pieces, each of them being a very function-specific piece that can be developed, managed, and deployed independently. And the benefit is that now each component can now specify an API with which the other components need to talk to it and so each individual component can by itself be developed and enhanced independently very quickly. So, to just formalize the three high-level benefits of this architecture, it falls into the typical people process and technology domains that are like kind of the bare-bone back-end, so to speak, for any big organizational shift. On the people side, it allows different teams to build their own single-purpose application component as fast as they can very quickly and it's completely independent. As I said, they just need to specify APIs with which the other guy they're going to interact with it. On the process side, it enables really fast deployments because people can take that single component and tailor it to their needs and then they have experts in that area that go and chug on it and then release it very quickly. So, that way what people have noticed is that what used to take months, what used to take several months to deploy now goes out in days and a matter of hours in many cases and minutes in some cases we've heard too. And finally, on the technology side, it's also critical because each team can or each, for each component, they can choose their own language, their own development framework, their own deployment framework and they can really focus on making it really good for that particular application component. So, with all these great things that are happening, one caveat to note though is that not all applications fit this architecture. So, things like applications that are either closely coupled or applications that have latency requirements or classic examples that are not really extremely well suited to this kind of an architecture. But that said, it is gaining a lot of momentum and I think that a lot of companies out there who are deploying microservices in some form or the other and actually OpenStack itself is an example of a microservice at many levels because it has a neutron and a barbican and firewall of the service and so on, different components that are being developed independently and fast and they all interact with each other. So, with time we are noticing though that the microservice architectures are getting more and more complicated. So, here we see one application that we saw was broken into multiple pieces but typically what we are seeing is that these applications are now getting spread across different clouds. So, in this case you have AWS, someone on-prem and some Azure and then this microservice also has interaction points with the Internet at not just one place but now multiple places. And the other thing to note is that these microservice architectures and microservice applications don't live in a silo of their own. They are present in the context of other applications in the system. Like in this case, for example, this microservice is interacting with SQL database and it's interacting with Kafka messaging system which are not by any means the microservice architecture right now. And this will see over and over again therefore a solution that we come up with needs to address not just simple microservices but should go beyond that. So, what is the problem with microservices in terms of security? And that's the primary question we were trying to answer. When we had monolithic applications, it was relatively easy to secure them. So, we just had this perimeter based on which you could say, you know, things like you wanted and you basically divided up your security space into AppSec and NetSec kind of components and you said on just to clarify here, AppSec people usually typically just refer to application firewalls and OS systems. You are treating it as a much more broader term out here which includes API gateways, TLS proxies and so on. So, more, you know, security mechanism that are at the application level. And then there are NetSec solutions people deploy on top of it which are for more for segmentation, firewall rules and IPS IDS kind of systems and so on.  It's a little more multi tier. It was working okay. But once we start going into microservices domain, this thing gets much more hairy and complicated. So, just to see what are the new types of attack surface that this microservice is introducing, if you look at this earlier picture, first thing that you see is that there are rapid deployment that are happening to each of these components. Each of these components are individually being developed and pushed at a rate that's commensurate to that team's velocity. So, that makes it very hard for on average to track as a security product to see what's going on at any given time. The other interesting bit is that before you had just one application and so it had a bunch of and it exposed a few APIs. But now once you break it down into small pieces, like taking a sphere and breaking it into small balls and so you currently there's the number of entry and exit points into it suddenly blow up out of proportion. That kind of what happens with your more exposed APIs. And not just that, as I said, they also interact with existing SQL and Kafka and whatnot, other systems. So, even those, the attack surface, even for those kind of blow up because of this. The other aspect is the communication channels. An interesting part of microservices is that they take function calls, so to speak, and convert them into network traffic and network calls, network API calls. And so therefore you need to not just worry about data flowing just within your application, but now it's data flows on the network and potentially across clouds. So, that opens up one more communication, one more attack surface to the whole system. And also these, and finally these apps and infrastructure also are becoming less trustworthy. So, because these are so fast, developed so fast and also many of times they're just pulled off the internet and open source components and just run without proper wedding. So, it ends up being that they can easily, if one of them is goes wrong, it can attack your other applications and this can spread very quickly. And also the infrastructure in terms of people using different types of clouds and so on makes it less reliable as well. So, with that, why do we care about this attack surface becoming larger? What are the primary issues with that? The major thing is that it puts your sensitive data at risk and that's the key problem by going to microservices. So, just to put a little more meat into it, let's say you have an on-prem system with OpenStack and Mesos and so on, deployed on your, deployed on premise, then you have AWS and Azure running Docker Swarm and Kubernetes kind of deployments. And their communication is now not just within a cloud, now it's across clouds. And also the communication, like here there's an orange service talking to a blue service and if you actually expand it out, each of these services are potentially spread across multiple hosts. And you have communication not just across hosts but also within hosts. So now you've entered this world where you have communication all the way from intrahost to cross cloud. And this is where most organizations we see are moving. So, the cloud-native and microservice architectures are changing the function calls network traffic, causing this intrahost to crossword communication. These agile deployments of containers also introduce, in addition to the dynamism we talked about of new containers and FMR infrastructures coming all the time, they also introduce these privileged components into the system, like orchestration engines. And they themselves can be the source of vulnerabilities and problems like the RSA conference recently, I don't know if you guys saw, they showed how a Mesos cluster can be compromised by leveraging the fact that there is some part of the orchestration system that wasn't secure enough. And finally, as we move to public, private, I'm sorry, public, multi and hybrid clouds, the other thing that happens is that there is no, it gets really hard to have global identities for all these different components in the system. So, people used to rely on IP addresses and so on for identifying any given service and now it gets really hard. And as you go to multiple clouds. So, with this in mind, if you look at the evolution of compute, cloud, et cetera over the last three decades or so, see that the physical machines turned into virtual machines and containers are the faster, better arguably, versions of virtual machines and so on. And that has led to cloud deployments also being like moving from physical to private clouds, public clouds to hybrid clouds and so on. And applications moving from monoliths to three tier and now more like microservices and function-based applications. And it's interesting here how security is evolved in two dimensions here in silos, NetSec and AppSec. They've been evolving at their own pace but they've still been in silos like network appliances, overlays and VPCs and security groups and so on are popular in different environments and SDN micro segmentation are the newer ones, newer kids on the block, so to speak, that are trying to do more finer grain network-based isolation. And on the AppSec side it's more like physical appliances, virtual appliances and more recently HDKs and RASP and so on that are coming that are trying to secure your application. But all these are fundamentally built pre microservices and pre this dynamic sprawling infrastructure era. And so the question is what is the next thing that we think could actually come and address these new attack vectors that have been opened up based on these microservice architectures? So you should now go over some existing solutions and talk about the trade-offs. Thanks, so we looked at this problem and then tried to figure out what are the requirements for a good solution to it. And so this is what we came up with. So the first thing is that it actually has to solve the problem that we laid out this sprawling and dynamic attack surface has got to secure it. It's got to be as dynamic as the infrastructure that you're trying to secure and it's got to be as distributed as that infrastructure. And it should have minimal trust in the applications and the infrastructure that's running on. The second requirement is that it should work across both traditional and modern environments because it's just a fact that microservices need to interact across these different environments. And so kind of as a consequence of that, a requirement of the solution is that it needs to be independent of that underlying infrastructure like to the network frameworks you're using and so forth. And it should work in polyglot environments that shouldn't lock you into some set of programming languages or frameworks. And finally, to be actually secure, it has to be easy to use because if it's unusable, it's not going to be secure. So it needs to be able to express things, to express policies at application level, something that humans can easily reason about their deployments rather than having to deal with the low-level infrastructure constructs, things like IP addresses, and so forth. It should provide single-paying visibility and control so it's easy for a security team to come in and just get an overall picture of what's happening and control. And then it needs to be self-verifying so that you just set it and then forget it and have confidence that it's going to do the right thing. So let's take a look in the context of OpenStack and Kubernetes and see what are the kind of tools that you have out of the box that you can try to put together and configure a solution that gets as close as we can to this. So in OpenStack, we have actually a very rich set of network APIs in Neutron that allow you to configure virtual network topologies and then to provide connectivity between them through virtual routing and firewall as a service. And then at the instance level or even the virtual interface level, you can attach security groups, which are sets of rules that define the kind of ingress and egress traffic that's allowed. And these are expressed in terms of the IP protocol like TCP, UDP, and so forth. The address range, CIDR, and the port range. And you can also specify the peers security group ID as condition. There's also a role-based access control mechanism now that allows different OpenStack projects to share access to a Neutron resource like, say, a virtual network that you can then share between multiple projects. So these are all very rich, complicated mechanisms that you can drive through programmable APIs, which is very nice. But it's kind of at the wrong level of abstraction. What we really want is to be able to control microservice to microservice interaction. And what this is giving you is kind of network primitives. And so you have a semantic gap that you have to bridge yourself. At the application level, there are a couple of things that OpenStack gives you. Now there's the barbican, which provides you a secret store API that allows you to store secrets and certificates and stuff like that in things like hardware security modules through a plug-in mechanism. And then applications, your applications or microservices could be developed. The code in those applications could be developed to consume those secrets and exchange them and kind of use that as a basis for doing policy, like controlling what APIs something is allowed to access. And then there's also, and Neutron provides you the load balancing as a service plug-in. Some of the load balancing as a service plug-ins can do L7 policies as well to kind of control which APIs things can access. So from our perspective, this doesn't really meet those requirements that I set up upfront because it interferes with the application developer in the case of secrets. And we have to kind of rely on them to do the right thing.  And in the case of load balancing as a service, well, you've got to get the networking right to make sure that traffic cannot simply evade the load balancers. And the load balancers are fundamentally separated from the applications. And so they don't have the kind of application context that they need to always make the right decisions. So in terms, if we look at Kubernetes and see what's available there, Kubernetes has kind of a much simpler networking model, kind of a flat networking model by default. And the network policies which are used to control reachability between Kubernetes pods are defined at a more abstract level than what's available currently in Neutron. Here you define reachability based on the labels that have been assigned to pods and the values of those labels. And you can define very complex label selection rules that define what kind of traffic is allowed into a particular pod that has a network policy attached to it. Segmentation is also possible in Kubernetes installations through various CNI plug-ins, container network interface plug-ins that are available like Open Contrail and Calico. But it's kind of not a first class citizen of Kubernetes itself. And then at the application level, there's been some recent work. There's a fairly new Secrets Management API. And there's a lot of discussion in the community about adding service level policies in addition to the network policies that I described. So again, these kinds of solutions are different levels of the stack, the network level, application level. They still kind of require applications to do things like the application code. And so there's kind of no easy way to both bridge that semantic gap and make sure you've got everything configured coherently in harmony to achieve that high level goal that you really want in terms of microservice to microservice interaction and security. I should also mention in the OpenStack world, we have some higher level tools that kind of can coordinate across the different levels. Like there's the Heat Project, which allows you to create templates for reusable deployments. And then there's the Congress Project, which allows you to specify kind of policy invariance that should hold in your configurations. But they kind of don't really solve the problem of having to get all of these low level details right in the first place. So how do people combine OpenStack and Kubernetes together? There's kind of two fundamental ways you can do it. One is just deploy them side by side as separate clusters. The other way is to deploy Kubernetes on top of OpenStack NOVA instances, like VMs. And there's a couple of different alternative ways to do that. One is through the cube up script that Kubernetes provides. And another way is to use OpenStack Magnum. So either way, with your doing side by side or Kubernetes on OpenStack, we have the issue of what do we do about the network? How do we, you know, what level of integration do we want between these two networks? And what implications does that have? So this is a highly oversimplified explanation. You can get super complicated with all the networking options available for these two environments. So one approach is just treat them as completely separate networking frameworks. Don't try to unify at all. And then microservices that are deployed in the two different environments can communicate, but they can only communicate through the cluster exposed external IP address and ports that services can, you know, kind of export from their cluster. But then you lose some of the advantages of network integration, like you lose some of this ability to provide segmentation and so forth. So there is a project in OpenStack, Kerr, which you've probably heard about. So this is a very promising project that allows you to have Neutron spanning both of these environments, OpenStack and Kubernetes. It's basically a controller that sits there and listens for Kubernetes events, like new pods are launched in Kubernetes, and then it assigns Neutron resources to it. And that assignment is accomplished through a CNI plug-in that sits on every Kubernetes node. And the end result of all of this is that you get all the Neutron functionality of the virtual topologies, security groups, load bouncing and servers, all of that stuff now applied to Kubernetes pods, as well as your OpenStack Nova instances. Okay, so there is at least some way to integrate them and then you can use all of those as long as you again get all the details right in that low-level networking to achieve your high-level goals, you can kind of do that with OpenStack as well. It's a little unclear how this will work with the Kubernetes network policy, which specifies connectivity at a kind of different level than this. In terms of application level integration, I haven't seen very much, I don't know if you know better, but as far as I know, the secrets management frameworks are kind of separate things. And as I mentioned before, secrets kind of impose requirements on applications that can be burdensome. And similarly for the L7 authorization, if you're using Kerr, then I guess you can use the loop balancing of service kind of across those environments, but otherwise you kind of have to have some kind of custom solution. So I think that the takeaway here is that you have a lot of knobs, you can turn a lot of configuration at different levels. In both of these systems, OpenStack and Kubernetes are quite rich, but there's still a huge gap between the capabilities that are there and kind of the objectives that we really would like to achieve. And even if you could achieve that with these two environments, it's just a subset of the general problem that Giant's laid out where you have traditional infrastructure as well as private cloud and public cloud resources and you want to control microservices deployed across all of these environments. And so that's kind of motivating us to look at seeing whether there's a kind of fundamentally different approach that we can take to this. So I think Giant will lay that out. Thanks, you're sure? Yeah, all I heard was everything is very complicated. All right, so all these indicate that we need to think about this problem in a slightly different way. And I think one of the key approaches, a new approach that's gaining a lot of momentum to securing these microservices that are distributed and dynamic and spread across all the different environments is something that we're calling security micro engines. So you can think of security micro engines as like these app sec and net sec tools that we have. Think of them as miniature versions of those that kind of spread across or distribute across your entire environment. The idea is that they can now be very specific to your given microservice that you're trying to secure and you can invoke the kind of functions that are needed for securing that specific microservice. For example, the kind of microservice you want to do for like an HTTP-based application, microservice might be very different from the one that you want to do for like a SQL server, for example, and so on. So you can actually create these really tailored solutions for the different parts of the equation. I think you can think of this as like going one level from like as we moved from physical to virtual we had some level of programmability and now we are adding a newer level of programmability by actually having these micro engines spread across your entire infrastructure. And we believe that that's probably the right way as we go from this current set of security tools that we have to the next gen where we think that the security micro engines will play a really key role in it. We envision the security micro engines as kind of converging these application and network security layers, so to speak, into this brand new micro services layer level security that kind of lets you achieve a lot of these objectives. And I think one of the way to think about it is that a lot of intelligence for security was placed either in SDKs and applications or in terms of underlying network like in terms of security groups and so on. So now you can imagine yanking out a lot of the complex functionalities of those and setting it at this level which is at the micro services level and so you can talk and reason about it at that level. So that's kind of what we think the world is moving towards. And that's based on this is what we've built out a platform which we call Banyan security micro engines platform and that basically tries to bridge the gap between traditional and modern by creating a layer that's universal across these different environments. We've come up with a layer called Cryptovisor. I'll go over a little bit about what it is. It's a virtualization layer that basically lets you have a centralized policy management based on which you can control the activities that are happening all across these different environments by providing a distributed control plane and enabling enforcement of all these policies in a transparent manner and being able to visualize it. So Cryptovisor, you can think of it as a programmable security virtualization layer that's present on a host or a VM, depending on what you have. It sits between the application and the network stack. It's completely independent of the application and underlying network stack also. So that way you can plug in your favorite network network infrastructure. You can have your different applications in any languages you please. And this layer is a very thin virtualization layer that kind of builds in security into this ecosystem. And so any traffic that goes between applications goes through this layer. And so this kind of knows what exactly is going in and out of these different applications and uses that knowledge to kind of program different levels of security into your system. So as an example, let's say we have this case where you have the web browser and the mobile app accessing these front end kind of applications of services like web portal and catalog services and some middle tier services like payment services, user services and so on. And then you have some more database services like MySQL and Kafka or it is. So what traditionally instead of this perimeter based security for application security, think what which would have allowed either micro service going rogue and accessing other applications or having an intruder that can actually either access any given microservice or access the traffic between two microservices. We envision the final system should look more like this where we're able to program or configure the interactions between microservices in a way that is appropriate for that microservice. For example, here the payment service we can based on policies you can specify that it can only be accessed by a web portal service and it can only be accessed with mutually authenticated TLS. And something like Redis can only be accessed with notification service and it needs to be in a way that it needs to be in a way that you identify the client as a notification service, not based on its IP address, but as a more powerful cryptographic mechanisms which we'll go in a little bit. And finally, you can also imagine that this layer is gonna take something like protect applications like Kafka and say it can only be accessed by user service and web portal, but in addition to all that, addition to having mutually authenticated TLS to access it, you need to be able to provide differentiated access depending on which resource. And that's for Kafka, that's what they're called topics, so which topic you're accessing, you can provide differentiated access to it. So this is kind of where we're going to end and so that we can thwart all these intrusion attacks, so to speak. So what are the key attributes of this solution that I just described? One is that it's a transparent security layer, so you don't need to change your application or infrastructure and it works across modern and traditional IT, so you can insert this and you can automatically take your connection and now you can upgrade it to like TLS, for example, quite easily. We enable you to, we provide a global identity to all the endpoints in your system and this is cryptographically secure and signed and so on, so that way we can be sure that who we are interacting with is what it says it is not just some IP address support. And finally, this is high performance and low latency kind of a thin layer and we can provide the desired level of security depending on what service you're trying to protect. And we'll show an example of RBAC and ABAC policies that we use to kind of make this happen. So this is just a very high level picture of how this thing happens and I think I don't wanna go into too many details here but we have like in this case, you have two VMs running, like one of them running S1, the other running service S2 and they're trying to communicate with each other and they're potentially present on two different clouds. So we have our crypto visor layer that's sitting between your application and the network stack and all of these are controlled using this centralized dashboard which allows you to have all these different features that we talked about. So we provide cryptographic identities to all these endpoints and when they wanna communicate with each other we automatically create these secure trusted channels based on TLS between them and this allows us to communicate securely and we know exactly who we are talking with on both ends. So I think your show will now show a demo of some aspects of this that would be very interesting to look at I guess. Okay, so this is the dashboard showing kind of the overall snapshot of the current state of all of your clusters that you've got us deployed on. We can go to the network map and then we can see all the individual clusters like here is a Kubernetes cluster we've deployed and the applications on it. We have a databases cluster and a Kafka cluster where we have one application for Kafka. If we go to the all clusters view here we've grouped by cluster name so we can see those clusters that we've defined and we can see for example that the Kubernetes cluster is talking to the database cluster and let's see. So if we go to one of these applications in the Kubernetes we have this thing HelloCab the microservice application we developed and here we've chosen to group by service name so we can see all the services. Oh, that's the wrong mode, okay. So here we see all the services and the numbers here indicate how many instances there are of that service. So like this one passenger management says that there are three instances we can kind of expand that and then you can see those are three different containers on three different machines I guess. These are Kubernetes pods actually we can click on the links and see the kind of traffic that they're generating. So you support a few different L7 protocols. So basically that crypto visor layer is seeing all the traffic and then we kind of can accumulate that information, compress it down and send summary statistics up to this service. So let's jump to the Kafka one. So this here we've grouped by host name you can see there's two client hosts that are accessing the Kafka service and what we've done actually is we've set up a policy for this Kafka service and the policy has two parts to it. So one of them says that KClient one which is actually that first client has access to all resources that's a star and can do any operation. So here the resources are Kafka topics and the second client KClient two has access to topic one and topic two and it turns out those are the only topics it's accessing. So if we go to the events page and we select just unauthorized access events for the Kafka service, we see there's nothing. Okay, so now let's take a risk here and try to change the policy. So go to the JSON view and I'm going to remove topic one from the access from the list of resources that Kafka KClient two can access. So now it should only access topic two and if it accesses anything else that's an error. So I clicked update there and then we go back to the events tab. Oh, okay, yes and we see an unauthorized access. Sometimes it takes a couple seconds but whoops, I always do that. We can click on this and we can see the details of it so we see that a client with role KClient two has tried to access topic one and that is not allowed, it's an authorization failure. So that all kind of was a very simple user interaction but under the hood what has happened is the crypto visor has identified all the workloads in all of these different clusters, has assigned cryptographic identities to all of them which has transparently encrypted the traffic to the Kafka service, mutually authenticated so we know who the client is and has been parsing the Kafka protocol and applying the policy, looking for changes to that policy in real time and then adjusting its enforcement accordingly. So all that has happened with click of a couple of buttons so that's sort of the feature set that we wanted to show you today. So, okay, so let's just go back. This is where my lack of PowerPoint skills comes in, can you help? Okay, yeah, so just to sum up, so we have described a new attack surface that are raised by microservices and containers and hybrid clouds. I've described the kind of the mechanisms that you have available in OpenStack and Kubernetes to kind of deal with that and showed you why we think that there are shortcomings with that and motivated the development of a new solution, tailored to these microservice architectures and working across modern and traditional environments. It's based on this, the solution that we've come up with is based on the security virtualization layer that brings together AppSec and NetSec in bridges these different application environments. So we think this is a kind of very powerful layer that you can use to embed programmable security functionality over time. So with that, I'd like to open it up to questions, discussion because you could come to the microphone. Hi gentlemen, Scott Fulton from the new stack. I'm curious, first of all, we've talked a lot today about the two ecosystems, the OpenStack ecosystem and the Kubernetes ecosystem kind of overlapping one another. Do you gentlemen foresee a micro engines ecosystem emerging a third oversight scenario where you take something like you've shown here in the demo and integrate that into a separate management platform that's used by a separate group of InfoSec personnel or do you see this being integrated somehow into either OpenStack or Kubernetes? So I think you could do it either way. The approach that we've taken was to do the first way to have it be a separate ecosystem, so InfoSec people could come in and apply their policies across a diverse environment in an enterprise. And we tried to design in such a way this hierarchical so that the administrators of a Kubernetes cluster could control just the things that were relevant to them and a broader InfoSec team could control things across different clusters or across clouds. And one other thing I'd like to add is that a lot of platforms are usually responsible for the infrastructure and network layers and a lot of stuff that we're doing is more at the next level which is the application layer. And so a lot of functionalities arguably fall in a completely different domain. How do you solve the performance problem especially with microservices? The transaction gets smaller but the overhead remains the same. So the ratio rose with the amount of compute resources that you need for analyzing that particular transaction is authentic or not. So I think the overhead doesn't really grow like that. It's gonna be scaled proportionally to the throughput of your system. So if you have N transactions per second and you have some overhead of 2% for every transaction, there's still 2% scale by N. So whether that's in one node or spread across multiple nodes, it kind of doesn't matter because we don't kind of have an additional kind of communication or coordination overhead. It's just like a per transaction kind of cost that you're paying. So it kind of doesn't matter how it's split up if I understand your question, right? Well, I was thinking like a typical DNS transaction. The reason why we stack things together and get rid of security between them is because it takes like a one transaction actually multiplies by three when you wanna do a security DNS request as opposed to a non-secret. Oh, I see, okay, yeah, yeah, yeah. And in general, microservices are increasing the amount of communication you have. And so your communication overhead in general is going up because of your adoption of microservices. You know, that might impose a limit to how much you distribute, right? And what is the proper grain size that you want to support. But I think you can think of a system like ours as being something that is a local overhead, right? It's processing local traffic and it's not adding additional messaging. It's just adding some cost to every message that occurs there. So but there is a fundamental problem with microservices that as you scale out more, you're gonna have communication that scales probably super linearly with the number of nodes. I was thinking if there's any kind of data you have on latency that's added, so the system might decide that this is not good to be separated, it's more expensive to separate. Oh, to kind of help you do capacity planning or something like that. So when you scale out to a particular size, it's bad to scale this way. Yeah, so we haven't kind of gone in that direction of performance, helping you optimize performance and re-architect your applications. We're just saying, given the application you have, how do we help you secure it? But I think in the future you could kind of look at systems like that. Yeah, and I think one point to add there is that, yeah, so I think the fact that you can tailor security solution for each microservice means that you can, like let's say you figure that, parsing your L7 protocol is adding a lot of overhead, but you don't really care too much for it, you can just turn it off. Things like that are much more feasible if you have programmable architecture and that's kind of where we were going with the whole thing. Can we take one more question? Yes, I was actually gonna ask the same question from the gentleman over there, but let me ask you a bit differently. So when you establish the connection, then you do the negotiation with TLS or whatever that is. The expensive operation is the asymmetric encryption and the negotiation of the symmetric key. So is this an operation that you do for every connection or once it gets negotiated and then you're operating with a symmetric key, then you just keep using that? Yeah, so I think the answer to that is probably session reuse so that, I mean, a lot of applications are smart enough not to generate tons of connections between microservices, some are not. And so for those that are not, you need to do some kind of session reuse so that in TLS has support for that so we can leverage that pretty easily. The challenges with that come in when you have, when you have to load balance or where the traffic could, from one client, separate connections might go to different instances on the back end, then that session reuse state has to be portable across all of them, right? There's techniques to deal with that. So I think that we're out of time but we'd love to talk more if you wanna come up here. Thanks. Thank you.


was published in JAMA in 2019 by Vander wheel and colleagues that from the Harvard School of Public Health and their flourishing index has a six key domains for reimagining health. And those domains were originally focused primarily on thinking about health for patients and populations. But we cannot adequately think about health for patients and populations unless we also think about those delivering health and healthcare within the overall system. And so I just want to invite you to think about the components of that index as I go through my comments. So those six domains are happiness and life satisfaction, physical and mental health, meaning and purpose, character and virtues, social relationships and then financial and material security. So with that index in mind, let me move forward and share an overview of the three key areas that I intend to cover in my remarks today. The first is to provide an overview of gender equity in medical education writ large, followed by three case studies that come directly from the clinical learning environment. And then finally to conclude with frameworks and I will share two frameworks to support flourishing related to gender equity in medical education. So let me begin with this overview of gender equity in medical education. And I want to make two particular comments about gender equity in medical education. And the first is that in thinking about what I might say to you today, I obviously had a lot of opportunity to think about my own career in medicine which has been very strongly and unbelievably aided through mentorship largely of men who helped me along the way. But on continued reflection, I'm also well aware that our profession of medicine has embraced science and technology in a way that has transformed health and healthcare in America. And I think about the kinds of discoveries related to the gene for cystic fibrosis or the ways in which the human genome has been decoded for us. Or in fact, the ways in which immune therapy has led to unbelievable progress in treating our patients with cancer. And I could go on and on with those scientific advances that every day our patients and our systems and our population are benefiting from. So what is it about our profession that has allowed us to adapt and implement scientific advances at breakneck speed but we've not been able to do the same thing related to human capital. And we've not been able to do the same thing related to our training programs. That's something I think about a lot and I hope I'm going to invite all of you to help me change the world around those things because we've known about these issues for a very, very long time as a profession but yet we haven't seen the same kind of uptake that we have related to our scientific advances and there must be some things that we could do differently to affect change. The second thing I wanna say is that the references that I'm using for today's talk really speak of gender as a binary and I think all of us know that gender is not so simple, it's not a binary but I am going to be referring to it largely as a binary because that's where largely the published literature has existed for a very, very long time but also because I did spend so many years on this campus, I have the personal relationships with students and faculty who have transitioned and I don't want to unfairly misrepresent any particular individual in any of the comments that I might make. So I wanted to just offer a disclaimer about referring to gender equity as a binary without the explicit statement that it's obviously much more complicated than that. So to get started, let me just provide a broad overview of a few of the issues related to gender in medical education and this is not meant to be comprehensive but there's the issues that I will focus my comments on today. So first is that we clearly have some disparities and professional opportunities. I'll share a snapshot about that. We have higher levels of mistreatment that fall along gender lines. We also have an association with bias and grading assessment and content of narrative evaluations and we have a clear impact on childbearing and child rearing that we've known about for a very long time and have made some but very, very little progress related to that. So what about the disparities and professional opportunities? This really is a snapshot from the Association of American Medical Colleges database from 2023 showing on the left hand side of your screen applicants to medical school by gender, men in blue bars and women in the orange bars and then matriculants by gender on the right side of your screen and this just really gives us a snapshot of the last decade and you can see that we have achieved diversity by gender in our profession. However, the thing that's not obvious from this slide is that this diversity in fact was achieved on this campus in the mid 90s. And I remember being the internal medicine residency program director at that time when the Chicago Tribune and many different media outlets in Chicago were on this campus interviewing our students and then Dean of students Norma Wagner about the University of Chicago achieving for the very first time an equal number of women and men in our entering class in the Pritzker School of Medicine. Again, that was 1990s not depicted on this slide. So the point is as a profession we have achieved diversity by gender in medical education but we have not achieved equity with this wonderful diversity which we have attained. I think you've seen this slide before in this series because one of the authors is our very own Dr. Vinnie Aurora and this is a very important slide that shows the pay disparities. Man represented here in green, the women in gold, the difference by the orange bar and over the course of a career in medicine all aggregated together women are in general going to earn $2 million less than our male colleagues. And then of course this disparity is greater for the surgical professions but nonetheless it's a very large number however we cut this data. We see disparities in promotion in the academic ranks and this is a paper that was published in the New England Journal in 2020 and what we see is that the disparity in promotion between men and women occurs both at the associate professor level and at the professor level. And this is a really well done and quite elegant paper controlling for a number of different variables and the disparity persisted throughout the many different ways in which the authors analyzed their data. So over a 35 year career women were less likely to be promoted and there was no apparent narrowing in that gap over time. I don't know if you've seen this slide before but it's from the Association of American Medical Colleges database and I think it makes a very powerful visual point about women at leadership levels in medicine and how that pipeline gets progressively very narrow as we move from medical school applicants to those who graduate from medical school, those who become residents and then faculty and then look what happens at the highest levels in terms of the percentage of women represented as division chiefs, attain full professor status, attain roles as senior associate deans and very, very small numbers here for department chairs and deans of medical schools. We also have gender disparities and publications and there are a lot of different ways that this has been illuminated in the literature but I chose pediatrics as the discipline to share with you today in large measure because it is a discipline that is heavily populated by women as faculty members and even in that field you see the first authors of various publications by journal type on the left-hand side of your screen, men in the darker bars, women in the lighter bars and on the right-hand side of your screen by article category. And so this was a surprising finding in some ways but obviously a durable finding in terms of the number of journals and the types of articles that were analyzed by these authors. We also know that there are gender disparities in work that gets done in caring for patients and in doing the teaching to train the next generation that is not renumerated. And so one of those examples is narrative feedback to learners and what you see in this study by Montanian colleagues is that male faculty compared to women faculty were much more likely in the assessment forms that they filled out on their learners to provide nonspecific comments or no comments at all. And the reason that this is important is that accrediting agencies are looking specifically for narrative feedback. That's one important thing, but students themselves and residents themselves are looking to improve their performance. And when there isn't narrative feedback it makes it much more difficult to try to understand what the performance level is and how to help the student or resident perform in a more effective way. The second example here is the workload undertaken by the Electronic Health Record and Rittenberg and colleagues. I think published a really incredible paper about women primary care providers spending 28% more time in the EHR in basket and 22% more time on notes than their male colleagues. But in large part that's because they're receiving almost a quarter more messages from staff and from patients when compared with their male colleagues. So no wonder they're spending more time in the Electronic Health Record they have a lot more activity coming into the inbox. And of course they are not being compensated for that work. Now, I don't know if you've seen this paper before but I wanna point out that this paper is has the first author, a graduate of this medical school Teosie Adesie Oyi who graduated in 2012 and is in a surgery position at MD Anderson today and she started an online community for physician mothers and this online community was invited to share their experiences as mothers in medicine. And from that survey, which she shared with the group a total of nearly 6,000 of the respondents reported discrimination and those fell into various categories which you see on this slide. Specifically my pay or benefits were not equal to my peers and those who experienced discrimination as mothers are in the lighter gray bar, those who did not experience discrimination in the white bar. I was not fairly considered for a promotion or senior management. I was treated with this respect by nursing or other support staff and obviously that has the highest rating for discrimination. I was held to a higher standard of performance than my peers and I was not included in administrative decision-making. So multiple different snapshots for the ways in which the physician mothers were feeling discriminated against. Another part of that survey was a question. What are the three workplace changes that you consider most important? And these are the three things that group asked for. A more flexible weekday schedule, a higher salary and a longer paid maternity leave. Okay, let's turn to the second major category that I'd like to cover today and that's case studies from the learning environment. And as I've already signaled, these cases are based on incidents which occurred while I was here at the University of Chicago. I have changed some key details so that I'm protecting the privacy of the individuals involved. Many of you have seen me use this framework in prior presentations and it's a framework that's actually fairly old written by Lauren DeLos and colleagues and educational psychologist where he plots challenges on the scale from low to high against support levels from low to high. And you see in the lower left hand quadrant that when challenge is low and support is low, stasis occurs for the adult learner. When challenge is high and support is low, retreat occurs for the adult learner. When challenge is low and support is really high, the learner generally has confirmation that what they're doing is just fine and appropriate. When challenge is high and support is high, that is where growth occurs and that's where I hope we all aim to be working and living in that space of growth. But obviously things can go wrong and there are always things that we can do better. So it's in that spirit that I present these cases. So the first case involves Jane Doe, a third year medical student on her surgery clerkship who was doing her two week rotation in neurology. The attendings and residents were all men and the other third year student rotating with her was also a man. In the outpatient clinic, she was routinely assigned only to the women patients because quote, patients will be more comfortable. However, her colleague medical student received patient assignments of both genders. In the operating room one day, Jane was asked to place a Foley catheter and as she was performing the procedure under supervision, the resident called out, hold it like you mean it. And then those in the operating room that day erupted in laughter. So following this episode, Jane met with the surgery clerkship director to share that she was feeling as if she'd been denied some patient care opportunities during this urology experience. And she considered what had happened to her in the operating room that day, a really obviously uncomfortable and hostile kind of experience. So the question for all of us to think about is how should the clerkship director for surgery respond to this situation? I also wanna say that I could have chosen a very large number of cases where men doing their obstetrics and gynecology rotation had similar kinds of thematic experiences. Okay, so for those of you who do not know when students graduate from medical school all across the country, they are invited to complete a graduation questionnaire where they report on a whole range of experiences that they had in medical school. And then after the students graduate, the school receives in aggregated fashion feedback on the responses of their students. And they also get to see the school gets to see the national benchmark related to each individual question. So among the questions on the annual graduation questionnaire, ask students whether or not they felt like they were denied opportunities for training based on their gender, had they been subjected to sexist remarks or names and do they think they received lower evaluations or grades solely because of gender rather than performance? So we and other medical schools regularly have the opportunity to see our performance on those various questions. And what you see here is a paper by Hill and colleagues published in JAMA where we see the national aggregates by women and men, women in the orange bars, men in the blue on their reports of one episode of mistreatment, two or more episodes, public humiliation, subject to sexist remarks or names, lower evaluations, denied opportunities for training and unwanted sexual advances. And in every one of these categories, obviously, women are reporting these events at much higher rates than their male colleagues. There's also a very important component that is not displayed on that particular data set. And that's the component of intersectionality where underrepresented students who also happened to be from underrepresented in medicine groups had the highest levels of racial and ethnic discrimination being reported. Asian underrepresented minority, multiracial and LGBTQ students reported a higher level of mistreatment than male white heterosexual students. There is further work being done by this group at Yale on this topic and the Macy Foundation actually is supporting this work in follow-up grants. So you will hear more to come. So let's go back to our students. So Jane Doe had this experience during her two-week rotation on urology. So how should that clerkship director respond given everything that I've shared? So a stasis response might be, well, I'll speak to the surgeons, but it was really just a bad joke. And why are you worried about your grade? The attending saw you place one fully, it was fine. Nurses do it all the time. It's really not that complicated. Low support, low challenge. Retreating from that state might be you can't take a joke, lighten up. Remember patients have the right to be comfortable. If you missed out, no big deal. You weren't going into urology anyway. Some of these are actually kind of verbatim quotes just so you know. Or to confirm how Jane might be feeling. Oh, so sorry that that was said, we've all been there, you'll get over it. Don't worry about the patients. I checked with the attending. He said, you're doing well. The more ideal response might be, I will speak with the program director and you're attending. Your experience in the operating room was unacceptable. I'll make sure that you have time in our sim lab to practice skills if you feel that you need more educational opportunities. So again, I'm not aiming for perfection here, just aiming to help all of us think of ways that we might be more effective and do better. So let's turn to the second case. And this is a case of gender bias and assessment. Mary Smith is a second year emergency medicine resident. She aspires to become a chief resident. She knows that there are specific attributes associated with being chosen for leadership, including decisiveness and confidence. Recent evaluations have discordant narrative feedback around her autonomy and assertiveness. And indicate that she's lagging behind in meeting her milestones. Mary actually compares notes with the other residents. We all know that happens all the time. It's one of the ways residents survive, checking in with one another. And what she hears is that several other women are feeling similarly and reporting that they also are receiving conflicting feedback in their narrative evaluations. However, she's not hearing that from her colleagues who are men. So they decide that they're going to ask the program director, is this real? Does the program director have a perspective about this? So what do we know? And once again, part of what we know came right from this institution. I actually remember when this was presented at Medical Education Day, long ago, Vinny Arora is the senior author and it was our own student who took a look at the feedback from attending physicians in terms of the milestone ratings that they were awarding to residents in emergency medicine. And what you see is residents in the PGY one year, men and women basically earning milestone ratings at the same rate essentially. There's a little bit of variation there. But by the PGY three year, there are very significant differences. And those differences are such that men are achieving their milestone ratings. So if you get all the way to the right hand side of that scale, milestone level five, being able to practice without supervision, men are achieving those milestone ratings at a faster rate. And the aggregation of this data set shows that it adds up to about three or four months of training indicating that men could finish three or four months earlier, women have to extend their training three or four months. This is a really important paper and very important findings. There's another paper from the emergency medicine literature which these authors looked at the narrative feedback in particular. And what you see displayed on this particular graphic is the times when the qualitative assessment of narrative feedback for men was in aggregate five percent or more greater than for women. And likewise, when the commentary was five percent or more influencing the women's performance, you see it plotted here in the gold bars. And so the kinds of things that were favoring men are all those domains that you see listed on the left hand side of that graph, professionalism, provider communication, differential diagnoses, critical thinking. The women were more commonly referred to in their narrative comments about their adaptability, their confidence level, their assertiveness with treatment and more commonly rated below the performance of men. So I think there are a lot of very important observations by this qualitative data that should help us look very explicitly at our systems of assessment and do better. So what happened to Mary and her colleagues in emergency medicine? How should the program director respond when the women residents ask this question? The program director could say, well, we're using the forms that come from the American Board of Emergency Medicine and the ACGME, they're the milestones forms. So I'm sure everything's fair. Don't worry about the faculty feedback. This is the best program in the country and you're getting a great education.  The faculty are doing important work and they don't need your criticism. To confirm their experience, the program director could say, listen, the milestone ratings are meaningless. Don't play such close attention to them. You're all doing great. Or, you know what? This is important feedback. We will look at our assessment data and if we discover bias, we will provide faculty development and come up with a fair and constructive way forward. I'm gonna have the faculty ask you specifically what kind of feedback you'd like to receive so that they can pay attention to areas that you'd like to work on and develop further. We clearly know there is a lot of bias in our assessment systems and so I think this is another example of where we can do much, much better as a profession. So let's turn to the third and final case and that is maternity leave. So Molly Jones is in the first year of a cardiovascular disease fellowship program, a field in which only 21% of fellows in America today are women and Molly thinks she'd like to be an interventional cardiologist. After many years of trying and rounds of in vitro fertilization, she becomes pregnant with her first child. During her pregnancy, she develops preterm labor and is assigned to bed rust for the last three months prior to delivery and a six-week maternity leave. Her colleagues in the fellowship program are happy for her but resent the additional burden of work. They worry that even when she comes back, they will continue to carry a disproportionate load. Okay, this is unfortunately a really common kind of issue and this is a paper from Stence and colleagues which I think makes it important visual description of the ways in which our profession makes it really hard for women who wish to be mothers. And you can see that depicted here by the age at which people on average graduate from medical school when they complete their training, their first attempt at conception, age at first pregnancy, compared with the general population in the black bar and then the infertility diagnosis. And once again, Vinny Aurora and colleagues published a very important paper about what are some of the strategic ways that we could address these issues? And one is fertility related education. Certainly wasn't talked about historically in this profession, it was a one-on-one thing but not a general conversation. Health insurance, big, big issue for all Americans and in particular for those training in our profession and then overall support. So I also wanna share an anecdote, it's a really powerful one and one that has stayed with me for my entire career and that is that for many years I was a member of the American Board of Internal Medicine and I sat on that board with one other woman at a time when we were presented with a proposal by the staff of the American Board of Internal Medicine to cancel maternity leave for all women. And on that particular day, I went beyond the wire arguing for why that was such a bad idea and why that would set our profession and our discipline back decades. As I said, there was one other woman in the room with me that day and unfortunately our argument lost. And it lost on the premise that as you know, internal medicine and pediatrics offer combined training. At that time, in the early 2000s, internal medicine had a provision for maternity leave. Pediatrics did not have a provision for maternity leave and isn't that ironic? Pediatrics didn't have a provision for maternity leave but they didn't. And so those who led the ABIM at that time felt like we were diluting the American public by saying that everyone training in internal medicine had 36 months of training when in fact, if you had a maternity leave, you would not technically meet that requirement. And so that day in that board room, maternity leave was canceled. So I could write a book about all the arguments I lost and that was one. And it obviously stuck with me for a very long time. But the thing I'm inviting all of us to mobilize around is why has it taken so long for us to change what is pretty straightforward kinds of things? Like how can you expect to be in internal medicine in your late 20s and 30s or later and not have a provision for a maternity leave without extending your training? Well, the American Board of Medical Specialties which is composed of all the specialty boards, internal medicine, pediatrics, obstetrics, and gynecology, radiology, you name it, if a certificate is awarded, they're a member of the American Board of Medical Specialties. And so what you see here is that that organization will now allow for a minimum of six weeks away one time during training for the purposes of parental caregiver or medical leave without exhausting your vacation or sick leave time and without requiring an extension of your 36 months of training in the case of internal medicine. Now, when do you think the ABMS made that rule? Yeah, yeah, July 2021. Amazing, just amazing to me. So I think you know how I feel about that. Okay, so back to Molly Jones. This is a really challenging issue and because of Molly being in her first year of fellowship, she wants to be an interventional cardiologist. Fellowships are really small programs, really small. So you have very little latitude as a program director. So how should the fellowship program director respond and support Mary in this situation? You see here that I do not consider this situation one of low challenge. I think this is a high challenge situation. So we're not even gonna consider the quadrants of low challenge. So if we're going to accept that this is high challenge and with low support, the program director could say, are you sure you wanna be an interventional cardiologist? I don't see how you're gonna be able to manage it. You'll be lucky to get through this fellowship at all. And that conversation has happened all across America in a whole variety of specialties for many decades. Or the program director might say, okay, we can help you get where you need to go, but for right now, let's put the timetable aside. I think you should consider asking for a formal leave of absence, focus on your health and the health of your baby and we will stay in touch and reassess on a regular interval when you wish to return. Okay, priority number one, take care of the patient, take care of the resident, take care of the fellow in front of you. Now, this fellowship program director though also has all those other fellows in the program. So how does the fellowship program director support all those other fellows in a way that is as fair as possible? And I'm now going to step into Nirvana. It's not a low challenge situation. And I know that it's not necessarily going to work this way, but in high challenge and low support, the fellowship program director could simply say, well, this is why there are so few women in cardiology. This is what needs to happen. I've made out a new schedule. You'll all be on every third night call for the rest of the year. That's not going to go over well, but it happens all the time. More healthy approach might be, I've gone to the department chair and I've asked for approval to hire an additional fellow outside the match. I will be also offering opportunities for other fellows and third year residents in medicine who might be interested in cardiology to take some of the on-call responsibilities. Now, again, we can talk more about whether Nirvana exists. And I know and actually sat up in the seats where that kind of a request would come through and often get denied. But that's, you know, let's just say that this would be a more ideal situation and one that we should all be fighting to make happen. Okay, so I promise that I was going to share some frameworks and I do wanna allow time for questions. So let me share those frameworks and then we'll get to some conversation. So one framework is well known to those of you in the audience who focus on ethics. And that is we should be using an ethical framework for training the next generation of physicians. If we were to do that, how would you assess how we're doing on these four domains of autonomy, respecting persons and their right to make choices, beneficence, obligation to contribute to a person's welfare, non-molificence, obligation not to inflict harm, and justice, the distribution of resources in a fair and equitable manner. And I just invite you to reflect on, you know, the three cases and the many cases that are well known to all of you and think about how well we might be doing or not as a profession. The other framework is the one that I introduced at the very beginning. So this framework, as I said, is meant to apply to individuals, our patients, to systems. And we cannot apply this to our patients and our systems if we don't also apply it to our healthcare professionals. And so how are we doing in those domains? And what will it take to change? So I wanna conclude by talking about what will it take to change? And invite all of us to look at the image from the Agnew Clinic from long ago and compare that with an image of our own internal medicine residency program from the mid 1990s. We have clearly diversified this profession and I've shown you some of the data about that. But I've also shown you the data that demonstrates we have not achieved equity and we continue to propagate inequity from our assessment systems to the policies that we enact both locally and nationally. So what is it going to take to achieve equity? One is to dismantle the training and career pathway expectations that are based on the traditional model. And that traditional model was invented more than a hundred years ago and we've made very little incremental change around that model. The second is to dismantle a culture of education that disproportionately mistreats women. And we've seen that data in our graduation questionnaires for many, many years. And yet we keep seeing the same kinds of data reported in the medical literature that I shared with you here today. We need to address and combat and correct this physician pay gap. And I know you have work underway here that you've been at work on now for many years. We need to recognize and reward the work that's not compensated. And I gave you examples of that. And then very specifically, we need to provide on-site affordable childcare and resources which promote healthy parenting. And I would have a lot more to say about that if time allowed. So I know most of those things take money. However, I believe there are strong and powerful quantitative arguments that could be made that then allow us to tee up choices about how we use our money. And I believe those arguments could be very persuasive by looking at the toll that the various biases and discriminatory practices take on women in medicine in particular. So what strategies are really needed to reach the tipping point where I'd like to believe we are where we find ourselves. I would like to have thought we were at a tipping point back in the 90s when we achieved equity, with diversity on this campus. And now you've seen, we've had at least a decade really of diversity in medical schools, but our pipeline doesn't have that. So there are three agents of change according to Malcolm Gladwell in his book, The Tipping Point. The law of the few. And that means taking the people who are the connectors, the managers and the producers to make real change. I believe you have all those people right here at the University of Chicago and you are in positions for a national platform to make real change. The stickiness factor, what can you do in the various tactics that you might take that will have the stickiness that will be durable over time and not just dependent upon who the department chair is, who the dean is, who is the person who has the decision-making authority, what are the stickiness policies that will allow this to really be a new world for the next generation of physicians. And then finally, the power of context. And that is to examine health and healthcare in America today, to examine those who are choosing to pursue careers in medicine and using that context as the engine to drive real change. Why do we wanna do that? So that together we can all flourish, our patients, our population, and importantly, the women who are choosing a career in medicine. I'd like to thank my colleagues at the Macy Foundation who I have the pleasure of working with every day and a particular shout out and thank you to Dana Levinson who joined me at the Macy Foundation a little more than a year ago, two years ago. And she's here in the audience today. So Dana, thank you. And I know that many of you will wanna say hello to her. So I'm gonna stop there, Julie and we'll be happy to take questions. Great. Dr. Levine, you wanna ask the first question? That's so great. Thank you so much. I have a question about that flagging number only about 18% of women achieve who are coming to department chairs or deans. And it seems to me that now again, there's more and more organizations that are luckily looking for a new position. So the more we're looking for women, yeah, women are still being held back and feeling that they're holding back themselves to go after those positions. What should the universities be doing to help promote their own women to encourage them to look for these positions or think about achieving the higher level women are. Okay, that is a great question. And I think it starts with who's in the pipeline and I think you are in a very good position here on this campus, but nationally, we also know the beginning of that pipeline in good shape. Search committees need to be composed of a very diverse group and in particular, but include women, not only as members of the committee, but when appropriate and often I hope as the chair of those search committees. Identifying the women's candidates as well as your pool of candidates, but in particular, setting up the interview day and the whole process in a way that is supportive of the person who you're aiming to hire. Once the decision is made to hire, that's when actually the real work begins. Some people think the real work begins by having a coach in place, and that's important. Coaching and having a support system in place, but very often institutions fail on the support system that's in place. And I would say I really have a transition team made up of more than one person and that transition team would not only welcome the new woman's leader to your institution, but would be composed of thought leaders, individuals who have their connections within the institution to have the back of the person who you're hiring as your leader. And then the institution as a whole needs to stand behind the leader, have a lot of forgiveness when things go off track and the ability to help that leader be successful. As a professional, I think we have done a horrible job in general, how we support our leaders. We toss them out when something goes wrong. We don't really set up a system to help them succeed. So I think we have to carry it through the full, to the full end of not just the appointment, but to the successful performance ultimately in that leadership role. Now, having said all of that, I think it is very important that the individual who we want to promote to apply for those kinds of positions be coached and guided about speaking a new language, speaking the language of quantitative argument. So not just making an argument based on the qualitative reasons why the strategy should be put in place, but quantitatively. Why is this a good business decision? What is the profit ratio? What is the margin on this decision making? What kind of investments are we going to do? Sometimes in order to speak that language, people will need a really in-depth background in business and financial analysis. But that doesn't mean you have to have an MBA. That means you need to be intentional about how you prepare for those kinds of roles. Likewise, I think the community, meaning all of us together, need to decide what do we value most and how are we going to hear the messages that come from the leader? And are we open-minded in giving people the benefit of the doubt? Or are we harsh and critical and ready to move on to the next leader as soon as some mistake is made? And I think that framework actually applies to all genders of leadership. So I kind of took your question from women leaders to leadership in general.  Oh, sorry, sorry, sorry. So this is an anonymous and I think this was a really great question based on the kind of scenarios that you gave is basically there's often in these scenarios that you gave tension between giving immediate feedback to the person because there's not anonymity if you give the feedback right away versus in the typical situation we would wait six months and then aggregate feedback and then say to the person that these things happened. So what the person's question is what are your thoughts about this practice and what's the best way to address and it's treatment in a timely manner? Okay, thank you for that question. It is a really important question. And the first thing I wanna say is please don't wait six months. I understand why you would so that you have aggregated data point but I would say number one feedback in the moment or shortly after whatever incident was is extremely important. Number two, most of us unless we trained in psychology and psychiatry may not have the skills to be able to do that feedback in a way that is comfortable and effective. And so know what you don't know. And when I didn't know how to have a conversation like that I would call someone who I knew knew it better. Elizabeth Keith right here in the audience is someone who I could call and say, hey Elizabeth, I have this situation. I'm thinking I'm going to say this and sometimes she say, Holly, that's exactly right but sometimes she say, well Holly you may wanna reframe it this way. So anyway, important to give the feedback immediately or as close to the situation as possible. Don't worry if you feel uncomfortable because we all do know how to get help for yourself to give difficult feedback and know who your resources are to draw and to get that help. And then if you find yourself lost there are two little tricks that I've used my whole career when I found myself in that kind of a situation of giving difficult feedback in the moment. The first one was question asking how do you think this went? What do you think happened with Mrs. Smith on the oncology service last week? Every time I asked that question I learned a whole lot of things I didn't know before that actually added texture and context that was extremely helpful. And the second little trick I used when the person in front of me just was not making sense and even if they pushed me to the point of clenching my own fists and teeth like why did you do that? And I wanted to say something that I might later regret I would say to myself, Holly someone loves this person. Might be their mother, might be their spouse but somebody loves this person. Control yourself, Holly, you know there's someone in the world who really loves this person who is driving you crazy right now. Now that is not based in psychology or psychiatry it's just a little trick that worked for me. So if it helps you I share it in that spirit. Elizabeth, did you wanna ask your question? Yes, so great question. So the first question is based on my experience in medicine where if I could choose only one place for an intervention where would it be? And the second part of the question is based on everything I've seen across the country is there one example that we could all learn from? So I'm gonna answer that question but I need to preface it by just saying I'm biased based on my experience but the one place I not only would but do every single day focus on with a laser beam is the clinical learning environment. Our training environments that our residents and students are working and learning in could be vastly improved compared to the historical programs that we have in place. So the clinical learning environment and what is the key or there are many keys to the clinical learning environment but among the most important keys are engaging our male colleagues as allies. Our male colleagues were my personal mentors. My male colleagues are the reason I stand before you today. My male colleagues are the direct reason that I had the chance to have a career in medicine. And that's not uniformly the case all across America but I know that we have men at the University of Chicago who are incredible allies. And the more that we can draw from them from their experience, their wisdom and their allyship the more we can make a change in our clinical learning environment. And I know you're all doing that actually every single day in the clinical learning environment but broadly that's where I'd focus. What have I seen by way of example that we could learn from? I'd love to come back and give you a talk on that because the Macy Foundation has just launched a catalyst awards. We've just identified seven institutions for our catalyst awards and the catalyst award winners who we chose the seven who we chose all to organize themselves spontaneously not at our direction but they all organize themselves spontaneously around a theme of creating environments of psychological safety without bias and discrimination in the clinical learning environment. So one of the projects at Duke University is to train their leaders and residents as civility champions. So anyway, I could go through all of them but that's probably another talk. I'm just gonna ask one more talk. There's a couple more but we can't answer so many but Dr. Lester retired pediatrician, pediatric faculty basically asking about gender concordance. Does the gender of the leader or the program director affect the with the gender of the trainee and how you manage the situation? Yes, thank you, Dr. Lester. It's nice to hear from you even in cyberspace and I just want to share with the whole audience that if you have not read Dr. Lucy Lester's book I commend it to you. It's a really comprehensive and beautifully written book about a long history of women in medicine. So thank you for the book and thank you for the question about gender concordance. Gender concordance is important for women and it's important for those who come from historically underrepresented groups in medicine but it's not the whole story meaning if you do not have gender concordance if you do not have racial concordance that doesn't mean you should back away from the opportunity to mentor guide and lead. So when you have it, it can be helpful it can also be harmful when you have it. And so I would focus quite particularly on the skills and investment of the guide and mentor irrespective of their gender. Well, let's just give one last thank you to Dr. Humphrey. Next. Next week we're going to be joined by Dr. Laney Ross who as you know was one of our pediatric faculty has moved to Buffalo, but will be joining us back in person back in P117, talking about gender equity and publishing and editorships and things like that. So excited to continue this amazing lecture series. So we will go ahead and close this part of it and then ask the ethics fellows to come down to the front to continue this more personal discussion with Dr. Humphrey. So see you next week. Give us our party here. Let's go. The challenge. Wait, where's the mouse for this? I just want to speak with you. I can type screen me. Good. Good. That was great. That was a wonderful... Thanks Dr. Humphrey. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.


something that goes beyond the obvious it should be informative it should be educated and it should sort of put things in context that's how I would look at it so we can go around with your permission as a chair put for the gold let's see a show of hands


Recorded books, and one click digital present, Someone to Love, a Westcott novel by Mary Balog, narrated by Rosalyn Nandor. CHAPTER I Despite the fact that the late Earl of Riverdale had died without having made a will, Josiah Brumford, his solicitor, had found enough business to discuss with his son and successor to be granted a face-to-face meeting at Westcott House, the Earl's London residence on South Audley Street. Having arrived promptly and bowed his way through effusive and obsequious greetings, Brumford proceeded to find a great deal of nothing in particular to impart a tedious length and with pompous verbosity, which would have been all very well Avery Archer, Duke of Netherby, thought a trifle. Sample complete. Ready to continue?