Thanks, Kathy. Like prior speakers, I would begin by pointing out the amount of hubris taken to really execute a talk like this as someone who is much more accustomed to worrying about what I'm going to be doing this afternoon. Trying to project myself 20 years into the future is particularly difficult. In the setting, I thought at the outset that I might go back to prior sages and see what they had thought about these kinds of issues. And one that came to mind was this, making predictions is risky, particularly about the future, which Dan Quayle said a number of years ago. And I think this really is particularly apt, but nonetheless trying to move forward. If you think about the future of genetics in medicine, I think there will be a number of unifying principles over the coming years, and these are fairly easy to state. The identification of genes and pathways that predispose to virtually every human disease, the ability to rapidly identify inherited predisposition prior to the development of disease, the production of medicines targeting specific causes of disease, and finally the ability to tailor treatment to the specific abnormality in individual patients. The notion that genes do indeed contribute to all of these traits is nicely illustrated by this apocryphal nuclear family. I think in the absence of genetic variation, we can see that there would be astonishingly little variation in gross phenotypic features such as height and weight, body habitus, down to very fine detailed features of facial structure, and behavioral traits as well such as taste and clothing. So clearly genes are contributing to just about everything we might be interested in, and we now suspect that these are all going to ultimately be attributable to variations in DNA sequence, and the task before us is to how to relate these variations that we're recognizing to phenotypes that are relevant to health and disease. And this really is where we've been in this enterprise in medicine up to the last several years. These lonely riders on a dry, dusty trail hoping to find something interesting but not quite sure how we're going to get there, and as many have pointed out, what we're headed to in medicine is something that looks much more like this, a much more crystalline form in which we know all of the genes, all of the common variants, and it really becomes a matter of putting the puzzle together of which variants contribute to particular diseases and how does this impact our diagnosis and therapeutic approaches. So the key for the next 20 years is, I think, going to be the roots to target identification. At the end of the day, the public expects us to be coming up with things that are going to improve human health, and these are going to be diagnostic and new treatment approaches. The roots to target identification, looking back now from the perspective of 20 years, from the year 2020 back to today, in retrospect it was apparent that Mendelian models of both human and model organisms, multifactorial trait genetics in human and animal models proved to be enormously important in identifying targets for new therapeutic intervention. Equally important in retrospect proved to be altered gene and protein expression in disease states. Also proved critical to be able to bootstrap along pathways to reach drug-able targets. That is to say that many of the genes that were turned out to be causative for disease were not themselves amenable to therapeutic intervention, so it proved important to be able to work our way along pathways until we could reach a target that we could intervene with. And finally, the development of antagonists and agonists against molecules and classes of fertile drug targets that already exist. This is something that the pharmaceutical industry, again in retrospect, recognized that simply they could use genomic mining to identify classes of drug-able target, and without much knowledge about what their actual functions were, were able to develop small molecule antagonists and agonists, and then assess the phenotypic consequences of these molecules, and having these genes in hand made an enormous difference. One illustration of, in retrospect, how genetics and genomics made a big impact on human disease is exemplified by this slide, which is the brain of a patient with Alzheimer's disease. Alzheimer's disease in the year 2001 affected about 4 million individuals in the United States alone, and in the year 2020 this disease is largely controlled, although not eradicated. So this shows the plaques of a patient with Alzheimer's disease from the brain. The biochemical nature of the molecules in this plaque was identified by biochemical studies. Molecular biology demonstrated that one of the proteins, the beta amyloid, was derived from the amyloid precursor protein, a classic, straightforward molecular biology project. Genetic studies had a major impact in identifying that mutations in the amyloid precursor protein, indeed, caused Alzheimer's disease as a rare Mendelian trait. Other rare forms of Alzheimer's disease were shown to be due to mutations in the presynolins, which turned out to be the gamma secretases that were responsible for one of the cleavages that was on the route to production of beta amyloid. And this led to the recognition as well that the beta secretase was involved in this pathway, and although no mutations were identified in the beta secretase, this also was cloned by expression cloning. And this led to recognition of these as amenable targets for drug discovery, and this proved to be very important for advances in prevention of Alzheimer's disease. Multifactorial genetics also demonstrated that there was a common allele that was a major cause for Alzheimer's disease. ApoE4 is a single allele in apolipoprotein E. There was a major risk factor for development of Alzheimer's disease, and was the first example of a common gene allele contributing to a common disease in the new era. Several other diseases have turned out to be, had marked improvement in their treatment as a consequence of genetic studies. Many of these places have been diseases in which we've been able to slow down disease progression, and these have had a substantial impact. One of the major areas has been kidney failure. They're currently in the year 2001. There are 300,000 Americans on dialysis for renal failure. Mortality of these patients was comparable to most forms of cancer. One of the first advances in this area was understanding the molecular basis of polycystic kidney disease, which is a Mendelian form of end-stage renal failure, and just simply slowing, agents that simply slowed down the rate of cyst progression had a major impact on the development and progression of this disease. Aging is another area that has had the substantial impact. Understanding rare Mendelian forms of aging has led to new approaches to treatment. And in the year 2020, I'm pleased to say that Sherm Weissman, one of the fathers of the entire field of genomics, now 95 years old, wrote me recently to tell me about the birth of his 21st child. So, looking back at the genetics of Mendelian traits, in the year 2020, it's evident that expectations of its rapid decline were greatly exaggerated because in the year 2001, only a quarter of the known Mendelian traits had been solved, and only the most obvious half of the viable Mendelian traits had in fact been recognized. So, simply in the period from September to November of 2001, three important new pathways for human physiology have been recognized. A new kinase pathway involved in blood pressure homeostasis, protease involved in maintenance of vascular homeostasis, and mutation in a new gene that has identified an entirely unrecognized pathway in the maintenance of normal bone density, whose loss of function leads to osteoporosis. Over the ensuing 20 years, there were many more of these examples. These contribute to fast and convincing validation of targets for pharmaceutical development that really had a major impact on pharmaceutical development. Just in the year 2001, the development of Gleevec had a big impact on the pharmaceutical industry, who finally realized the opportunities to use targets identified from genetic studies to really direct new pharmaceutical development. Sources of new Mendelian traits became important. As I indicated, we only knew about half of them in the year 2001. Large-scale resequencing of genes and pathways of interest, followed by clinical and biochemical and cell biology, identified a host of new Mendelian traits that we previously had not recognized. In addition, a number of new recessive traits were identified by transcultural studies in the Middle East. What I mean by that is physicians going to the Middle East looking for diseases that had much higher prevalence than found in the West identified a host of diseases that trend out to be recessive traits in these populations with high levels of consanguinity. These had dramatic impact in a number of fields, particularly the neuropsychiatric disorders, which have been desperate for identification of some simple Mendelian paradigms to get a foot in the door for pathophysiology. Another area that had been under explored but proved to be very fruitful was looking for genes with large effect but very low penetrance.  And finally, the use of animal models, particularly forward genetics in models such as the mouse and zebrafish, continued to provide a lot of insight into pathways underlying basic human physiology that proved relevant to disease biology. There are a number of obstacles that needed to be overcome in the genetics of human studies. The rate limiting step for identification of Mendelian traits became appropriate patient collections. And from the year 2000 to the year 2008, we had a real problem in clinical medicine. Regulatory agencies became the rate limiting step to genetic studies. There were overstated privacy concerns that made recruitment of families almost impossible. Paternalistic regulatory attitudes to the study of participants denied their full participation. It was impossible to go back to patients after we had identified mutations to do meaningful physiology on them. There was a regulatory focus on paperwork rather than on protection of patients and human studies. And there was insistence of identical IRB procedures in groups with drastically different cultural norms that inhibited the international studies that would ultimately prove so fruitful to understanding human disease. There are a few improvements that made a big difference. There are major advances made when legislation that prohibited genetic discrimination was passed and real world sensibilities gave way to tangible benefits of research in addition to theoretical harms. There was another important issue that has been alluded to earlier, and that is the finding and training of physician scientists. I would simply begin by addressing the question of, is it important to have physician scientists in this mix? And I would answer it with two words, Barbara McClintock. So if you think back to Barbara McClintock's remarkable career, she had insights that were 30, 40, 50 years ahead of her time, primarily I think because she had such profound understanding of the biology of corn, the organism that she was so interested in. Well, the simple answer to who has that same understanding of human biology, the simple answer is well-trained physicians. And these will be without substitute if we're going to take the full advantage of the opportunities in biomedical science. And things that I think have made a difference are investing in what works. It's turned out to be very important to identify and engage people early in their training, trying to bring somebody after four years of medical school, one or two years of clinical fellowship, and then say, okay, you're going to turn your life around and start to become a scientist. It was a difficult road for many to go. But we know one thing that works is the MD-PhD program. 75% of MD-PhDs funded by the medical scientist training program at NIH go on to academic faculties and NIH funding. And we ought to invest in this until these returns start declining. We need to develop ways for career development to evolve that allows for larger academic teams. This is something that industry long ago figured out, physicists long ago figured out, and we need to do the same thing in biology to allow individuals to make different types of contributions that don't all require that their PI on every grant and our first or last author on every manuscript in order to be advanced. And finally, one of the great opportunities that we have is to take advantage of this knowledge for renaissance in human physiology. GCRC's clinical research centers are lying relatively dormant, but these genes are going to provide enormous opportunity for understanding human physiology, and we have to make sure that we still have physicians around who know how to take advantage of these opportunities. So Mendelian diseases have identified a host of pathways that have proved important in a number of disorders, this one example in blood pressure. Being able to go back to patients and do detailed clinical physiology has proved key. Once you identify these genes, this shows one example where a gene that we had identified causing that changes blood pressure. Once we knew what the gene was and we're able to tease out the patients with these specific mutations and do physiology, we found that they had an unexpected effect on calcium homeostasis and found that the mutation in this gene actually had a large effect on bone density, a classic example of genetic pleotropy, and we never would have been able to do this if we had not had the molecular genetic background and the opportunity to go forward with clinical studies once genes have been identified. So the outcomes of Mendelian genetics over the last 20 years have been identification of new pathways underlying disease, identification of drug-able targets and new small molecule antagonists that were identified, that turned out to be applicable to millions of individuals who did not have mutations in the pathway. And as Jeff Dewick alluded to, this paradigm was well demonstrated by the effect of statins on cholesterol homeostasis. We now are treating tens of millions of individuals with drugs that were developed largely on the basis of the understanding of a disease that affects one in a million in the population. Another area that turned out to be surprisingly productive is pharmacogenomics, the ability to predict adverse drug response, the ability to predict beneficial drug response, and the big surprise was that this actually turned out to be much more productive than I think I would have anticipated, and it turned out in retrospect that drugs are brand new environmental factors and selection had not had a chance to select against undesirable genotypes, so over the last 20 years we found surprisingly many genes with large effect on drug response and risks of complication were rapidly identified. One of the daunting challenges in addressing this problem was routine collection of samples in clinical trials was very slow to develop, and promoting this turned out to be of substantial importance in unraveling this area. Genetics of multi-effectorial traits turned out to be one of the granddaddies over the last 20 years, and it nearly lost all credibility before the year 2003. The expectations were high, and the false positive rates were much higher. So, among the outcomes, there were some standout successes like Alzheimer's disease, where there turned out to be common alleles with large effect that were previously unrecognized pathways that were discovered, and these had an enormous impact on public health. There also were a number of other modest successes where there turned out to be common alleles with very small additive effects to disease risk, and those that defined new pathways turned out to be a very big help, and in the neuropsychiatric field this proved to be particularly important. However, there were also variants that were identified in previously known pathways that had very small incremental effect, and these turned out to contribute very little to either diagnosis or treatment. There were also diseases that turned out not to have common alleles underlying common diseases, and there were many independent disease alleles, and obviously one of the major problems looking back was that in the year 2001, we had almost no ability to discriminate a priori which of these was going to hold. All we were able to do was recognize which genes, diseases were Mendelian, which were not, and trying to distinguish whether there were two genes, three genes or 50 genes contributing to a trait was something that was well beyond our grasp, and we spent a long time trying to take vets and take risks with these approaches. Some worked, some didn't. There were two surprises in multifactorial trait genetics. One was the transcriptional variation turned out to be central to many multifactorial traits, and genomic identification of transcriptional regulatory sites and circuits turned out to be fundamentally important in understanding these traits. And the second part that surprised me in particular is that understanding genetic contributions to disease turned out to be key to identifying environmental contributions to disease as well. Once we knew pathways from genetic factors, identifying how environmental factors played into these turned out to be fundamentally important, and much to my surprise, the epidemiology once again became an important field. Things that made a difference in the genetics of multifactorial traits, basic blocking and tackling. NIH made an investment in large collections of well-phenotyped subjects. There was better consideration of power to find genes with small effect by emphasizing disease severity and emphasizing sample size. We gave up on the notion of collecting 100 sub-pairs and trying to find a gene, or getting 100 cases and 100 controls and trying to find genes that way. This turned out to be the major factor. Systematic testing for population stratification also became routine very rapidly, and VANA I'd like to buy a decent control sample version. Other things that made a difference, wide access to collected populations was made possible once we knew how to amplify genomes so that we could no longer make the argument that I can't afford to send you a sample because I don't have enough DNA to send it to everybody. Once we were able to do faithful genome-wide amplification, that argument went away, and this permitted us to distribute all of these collected samples to anyone who wanted them. On an open access basic, a genome project model that NHGRI deserves enormous credit for, and this permitted much better exploration of data space than we ever would have achieved if we had samples with confined access to a small number of individuals. We also finally solved the question of how to provide wide access to genotype and phenotype data for the same reason. Having a small number of individuals sitting on all of the data and analyzing traits whenever they had the time and opportunity was insufficient, and eventually we were able to give this wide access and allow everybody who was interested to have a go at it. Dealing with the ethical issues here turned out to be particularly thorny, but ultimately was doable. Tool and technology development really drove a lot of this. The decision to do the linkage disequilibrium map of the genome proved to be what permitted the genome-wide assessment of association studies in linkage disequilibrium. Cheap high throughput SNP genotyping turned out to be critical. We look back now at sequinom and just are astonished that we spent $450,000 on every one of those machines. Cheap high throughput resequencing of large chunks of genomic DNA also turned out to be something that really made an enormous difference. We had many small LOD score peaks that we were able to take five, 10-centimorgan intervals and simply resequence 100 cases and 100 controls, and then obviously had enormous computational issues to address in handling the data. And finally, the ability to recognize marks of selection on genomic segments in humans turned out to be surprisingly useful in recognizing when we were actually in a chromosome segment that impacted a trait. Finally, giving up the naive expectation that case control studies would commonly solve disease pathogenesis and instead generate starting hypothesis. This turned out to be important. The outcome of many of these multifactorial trait studies gave us interesting hypotheses but unconvincing final data to go forward, and we realized that geneticists have to be biologists too and use all of the tools available. Human and animal genetics, cell biology and biochemistry, obviously now in retrospect were essential to wrestle these problems to the ground. The ability to monitor gene expression and protein expression obviously has had an enormous impact. Early examples of how we can stratify patients on the basis of altered gene expression, shown in this slide of large cell lymphoma, was just the starting point for being able to reclassify diseases in useful ways based on altered patterns of gene expression. Critically, the systematic characterization of pathways from genetic and genomic studies of model systems let us define biochemical pathways, and then the ability to analyze human disease tissues in both humans and animals. This gave us a major advance in understanding disease biology. The generation of these large data sets under different experimental conditions permitted the definition of functional biochemical pathways. Expression studies identified pathways underlying disease process, and understanding these pathways was fundamental in letting us make sense of microarray data. Finding 10 genes in the same pathway, each with two-fold altered expression, was a lot better than going point by point. So identifying drugable targets from non-drugable leads. Most genes identified are not tractable targets for drug development in the near term. The use of model organism genetics to flesh out pathways from the initial gene turned out to be very important, and as suggested earlier today, genome-wide interaction maps also proved fundamental for bootstrapping our way to tractable targets for drug development. This simply shows one example of this from Tian Xu's work demonstrating that mutations in the tuberous sclerosis complex genes or tyrosine phosphatases had surprising impact when put into flies on cell and organ size, and the ability to go through these kinds of pathways in model organisms was critically important. Well, the impact of genetics and genomics on drug development has been quite profound. The drugs directed to validated targets identified by genetic and genomic studies have become routine. Drugs directed to known drugable classes identified from genomic sequence, this turned out to be very fruitful for the pharmaceutical industry as well. Advances in structure determination and modeling greatly aided drug design and discovery, and greater diversity chemical libraries played an important role. I would also point out the important role that genomic and proteomic markers of toxicity in vitro played for the pharmaceutical industry. Pharmaceutical industry, one of the major barriers was having phase one, phase two, or even phase three failures due to unanticipated toxicity, and the ability to use genomic and proteomic approaches to predict this toxicity and basically kill projects before they got into the clinic had a very important impact on the pharmaceutical industry and has greatly speeded the number of compounds that the pharmaceutical industry has been able to triage and get into the pipeline. Finally, by 2020, new classes of transcriptional modifiers have begun to have a major impact. Minor group binding transcriptional activators, SIRNA or RNAI-mediated suppression of gene expression has started to find its way into the clinic, and gene therapy, even in 2020, I'm still agnostic about its prospects. Implementation in medical practice. So by 2020, the precise molecular basis of most human diseases has been understood. Remaining questions include what are the boundaries of medicine, behavior, and cosmetic traits? Is this part of the medical armamentarium or not? And does it make a difference? Well, there's a big surprise. Physicians and patients are both surprisingly pragmatic groups. Given tools that have meaningful impact on diagnosis or treatment, they are rapidly assimilated into standard practice. Patients demand these. Physicians want to apply them, and these rapidly overran many of the other barriers that we imagined. Obviously, we require much greater reliance on expert systems for ordering and interpreting tests and selecting therapies, but the results of these still feed into comprehensible disease categories that physicians have been dealing with for the last 100 years, and this provided much less of a barrier than was imagined 20 years previously. We have many more preclinical markers of disease risk and provide opportunities for therapeutic, for disease prevention. And ultimately, one of the major questions that we're still dealing with in the year 2020 is the question of whether all of this knowledge has been much to the good of our development of new health care, but on individual patients has it created more neurosis, rather than having imagined targets that you can worry about on your health. You now have defined targets that you can really focus on. And that has become one of the issues going forward. So I think I'll stop there. Thank you very much for your attention. Stanford. That was nice, Rick. I enjoyed that. Do you really think that the reason that we have the physicians, that it was really whole genome amplification that allowed us to be able to do this, or that it was the fact that the laws finally changed and made people actually put their samples in so that other people could get access to them? It was a sociological problem. So I think it's a bit of both. I think you can help just by making it a non-issue to be able to say, we have infinite supplies of DNA, so we can't use as a reason the fact that it's a finite supply. And I think that will end up having a significant effect. Obviously, going forward, we can require that these samples be made widely available. Well, I just remember in 2005 I was making cell lines, and I had infinite supplies of DNA, and people were doing that, and they still weren't available because of restrictions. I think that's really probably as much a problem or maybe more of a problem than that. I know it's an excuse, but it's the culture of wanting to hold on to the samples. It's hard in almost every study that I've ever seen or been involved in. I absolutely agree with that, and the larger the studies become as we recognize that we need really big studies to do these, I think we will have to insist that samples be generally available or else we will clearly not get the most out of them. I think as taxpayers we ought to demand. Robert Klitzman from Columbia University. Concerning your comment about the overstatement of privacy concerns that impeded things way back in the early years of the century. If you remember also in the 2005 or so, the well-publicized cases of breaches of confidentiality that occurred where people lost jobs and some people weren't able to get married because of course everyone was able to look up everyone else's genetic information on the net. What do you think should have been the privacy regulations that were in place then? Yeah, I think this is clearly a very important issue. So obviously it is very important to maintain privacy and to take every step necessary to ensure that patient confidentiality within the research setting is maintained. There have been I think precious few examples of where breaches of that has actually caused harm in practice. I also think that some of the things that are actually practically a foot now to basically make it impossible to inquire about family history in the setting of research to contact patients as part of family studies without going having your pro-band contact them and have them write you. These are things that make doing clinical research of this sort impossible. And having collected thousands of families and patients by this route, I'm very concerned that we put too much emphasis on theoretical risk to patients over I think quite tangible benefits from the research that we're doing. Obviously trying to, I think in 2005 of course the legislation to protect against genetic discrimination has already been passed and put into law. So some of those issues are less pressing now. But clearly we're always going to have to respect patient protection, patient privacy, but we do need to have a balance between tangible benefits from research and theoretical harms. And obviously Dr. Young's just going to address this. Art. Art Podette of Baylor in Houston. I just wanted to second Rick's comment about there's already infinite supplies of DNA available. It's perfectly normalized in lymphoblasts and I think that that's something that, the technology's there and there's something about the culture that's not ready. I wanted to make another comment though. I really enjoyed your presentation and I thought it was very stimulating. For another perspective too though, that somewhere between now and 2020 it was realized that epigenetic variation had a huge impact on gene expression and disease. That epigenetics was very malleable. You couldn't study the changing DNA methylation that was going on in individual cells in the brain by studying lymphoblasts. And we found out that this malleability of the chromatin and epigenetic factors opened great avenues for therapy as well. I apologize for forgetting about that part. David. Rick, I couldn't agree more that identification of genetic risk factors may stimulate and guide epidemiologic studies to identify the environmental variables. But I wonder if we shouldn't be thinking about things that we could do rather than waiting for the epidemiologists to sort of come along with this if we shouldn't be thinking about proactive strategies to make the epidemiologic community or to help make it come to the realization that these studies really need to get going to have sort of the equivalent of an environmental genome project. Yeah, I think that's a very interesting idea. I think the studies that combine environmental factors and genetic factors obviously are going to have a lot of opportunity for advancing understanding of both areas. And my impression, and you can chime in as well, is that the epidemiology world is very enthusiastic about these issues. And the major issue that we still, I think, deal with periodically is the epidemiologists' desire to both find the genes and simultaneously determine their population impact. And I think this is a recurrent issue of should we be doing population-based studies or should we be doing disease-based ascertainment and investigation. For my money, I think the biggest bang for the buck is going to continue to be doing population-based studies after you have genes in hand and have some idea about what you're dealing with rather than trying to solve both equations simultaneously. But I think there will continue to be debate on that point. I'll just share from the University of Wisconsin. Actually, you have a question, but the previous comment does make me want to just add the following first. And that's the first thank you for the 2005 anti-discrimination legislation because that was the biggest ticket to women's equality that we've ever had since it's the biggest form of genetic discrimination that's prevalent in the United States. But even more, I'd like to thank the scientists here because apparently it was in 2008, according to your estimates, scientists finally looked up from their benches and their state of victimhood and frustration and organized and coordinated to endorse any one of the several perfectly rational efforts to standardize and streamline and make uniform the system for working with large-scale tissue banks, medical records, and patient contacts so that there'd simply be one system that everybody could agree upon. And it was that organizational effort by the scientists interacting with the political and regulatory community that finally achieved that success of 2008 that you mentioned. But the question... I couldn't agree with you more. The question that I had for you seriously was this. Most of the data that you presented was in the context of what seems to me to be individual doctor-patient interactions and the use in that kind of setting. And I found myself wondering how much of an event would be useful for understanding on a population level the patterns of disease and resistance to existing therapies, the demography of it in a sense, age of onset, geographic distribution, and the degree to which you think this might actually get used not so much in the clinical setting, but in the public health setting for infrastructure planning and for public health intervention planning. Yeah, I think that's a very apt point that I did not go into. It certainly will give us a much better definition of what we're up against from a public health perspective in both the near term and the long term. And I think that is very important. Understanding the prevalence of mutant alleles in particular populations has the potential to really help shape public policy and I think there will clearly be a lot of work necessary to define that. I think we'll still be starting to sort those out in the year 2020, I suspect. And I think there will continue to be practical barriers to doing that because of continuing concerns about stigmatization of particular populations. And I think those will be important issues to wrestle with. Jennifer Puck from NHGRI and I may be the only person here who's actually the head of an IRB and I just wanted to point out that many of the frustrations we all experience in wishing we could go back and revisit patients and lots of the troubles with current IRB regulations can be addressed by prospective changes in consent processes and communication with the subject. So in so many cases the subjects really would love to have their samples used in the way that scientists want. It's just a matter of putting these things together with the proper prospective consent to make it happen. I absolutely agree with you. However, I would not back down as I would be interested in your thoughts. Certainly the IRB at Yale is being almost run out of town by the amount of paperwork that they're now being required to do. And of course the impact on investigators. Many physician, particularly young physician scientists are looking at what's happening and deciding that mouse looks like a very good organism to be studying. And I think as a practical issue again getting back to the prior comment about physicians and scientists needing to be better organized to play a role in the decision making process is very important in particularly with regard to genuinely protecting patients who participate in clinical investigation rather than documenting what's been done that doesn't add to protection. Maybe if the rest of the people here served on IRBs more, we could have more light and less heat and less paperwork and I agree completely. Rick, all of us that is North Carolina I think you were wrong in one of your predictions. Regarding the usefulness of identifying common variants in existing pathways versus new variants in new pathways I think you're quite correct in saying that that will help in the derivation of obtaining new drugs but you forgot the large advances in prevention that occurred as a result of understanding genomic variation so that individuals who had variants in a large number of genes that were already known in pathways you could prevent the onset of the disease by prevention rather than treatment and that's always more economical in the long run. I couldn't agree more and I certainly agree by 2020 we're still maybe not quite there but in terms of knowing for the truly polygenic diseases whether we've identified all the variants in order to make very good predictive medicine with genes that have very small effect on the trait but I think your point is well taken at the end of the day if you can identify people who have 25 of those 50 alleles who are much more likely to go on that that might be helpful for prevention. My K-Back, San Diego, this is somewhat of a Rip Van Winkle type question I feel as if I was asleep and woke up and heard your talk in the year 2020. That beats the alternative. Yeah, that's true. It beats any alternative. But I guess the question that comes to my Rip Van Winkle mind is where did the regulation and or legislation come to deal with another parameter in this whole scenario and that is the private sector. Much of the technology that we've heard about this morning and the development and innovation that occurred after 2001 had to do with diagnostics and had to do with predictive tests and it had to do with pre-symptomatic tests which should be distinguished from pre-symptomatic tests certainly in terms of public application and it was the private sector at least at that time that kind of had control of that regulation and the potential harm from the perspective of the public was perhaps greater from that perspective than any other. So I wake up and I'd love to hear what happened. Yeah, so I think that's a very good point. I think one of the things that particularly the recent experience may teach us and Jeff Dewick might want to chime in is that private enterprise is very sensitive to public opinion and if private enterprise does things that end up having adverse consequences that will have immediate consequences for the fate of their companies. So in the near term I don't know what is going to happen in terms of legislation but one would hope that companies are in part kept in line by paying attention to what expectations for their bottom line is going to be. Jeff you want to comment on that? I mean the thing to realize is that to do patient collections whether they're for experiments or for clinical trials even in the private sector requires IRB approval and once you enter into the FDA process for the development of a drug it is completely an audible process and you're subject to all the necessary federal regulations and so I think that and if anything the private sector will not make use of any of the genetic data until the necessary commercial and more importantly consumer protections out there that will enable it to actually be commercialized so I think there's a tremendous trickle down and I think at some levels you overstate the issues in the private sector because they're subject to the same kind of oversight and it can pace deeper penalties. If Dr. Lifton you know violates some IRB maybe he loses his job maybe he gets slapped on the wrist if I do that I'm accountable at a financial level that you cannot imagine so I think I think you have to realize there is a tremendous amount of concern about these things. This really goes back to neuroses my name is Karen Rothenberg University of Maryland your very last point about how we deal with information and I think you're being extremely optimistic in the year 2020 that when we get this genetic information as consumers or even as scientists how are we going to figure out relatively what we're going to change in our behavior to make a difference so just for example let's just think about one thing lung cancer and all of a sudden you can give us a prediction about whether we're going to be more or less likely to have an increased predisposition to getting lung cancer are we going to be more or less likely to then smoke to start smoking to stop smoking I mean we already know what causes lung cancer we can't get the public to stop so when you then add to it sort of having to compare whether we care more about dying from cancer or from heart disease and those could be sort of at odds in terms of how we can deal with changing our behavior or taking certain drugs we see this happening now currently going on and they're not based on genetic information they're just based on very well proven common information already out there so tell us how are we going to get the public to be quote rational based on the perspective of scientists in changing their behavior and the way they live their lives and not be paralyzed by the information but rather to do things and there are people in this audience oh it's clapping your hands but I think that's really critical if we're going to make predictions into the future to know how we're going to manage that information I think these are things that physicians and patients deal with every day now as you point out we already know that if you're a smoker you are at markedly increased risk of lung cancer and of heart disease adding an additional piece of information that you have a particular mutation that makes it even more likely to develop lung cancer than someone in the general population is one additional reason for you to think about changing your behavior but we certainly can't prescribe behavior as physicians and tell our patients that they absolutely have to do this all we can hope to do is provide the most useful information that will have practical implications for individual patients as to how they might best try to maintain their health well-being and try to provide them with the information and rationale and persuasiveness that there's someone who pays attention to their well-being and cares about it but at the end of the day these are going to be decisions that individual patients are going to make and I don't think all of the genetic information in the world is not going to change that fundamental point I'm Ellen Clayton and since Jeff has made this comment about accountability twice I feel compelled to respond to it since I did it the first time the accountability of the market is not the same as the accountability of the political setting or the accountability of the moral setting the market is not concerned with justice it is not concerned about the underserved and I think that we have to recognize that the market does care acutely about public opinion it really cares about certain types of public opinion so as we talk about accountability it is not enough to say that the market will take care of it and that the invisible hand will make all ships rise together we've been down that road and it isn't what's happening and I would say that one of the things that's great about this country and great about our morality is a sense of commitment to all in a sense of commitment to trying to ensure that all get the benefits now I'm not arguing for a communist or a completely level playing field but I am insisting that we at least question the ability of the market to do the ultimate the ultimate distribution without any other sort of regulation the reason we regulate in this market is because the market is not the optimal ultimate optimal distributor at least according to some people so let's just I mean we have to get that on the table but the market is not the only answer okay so I'm Bonnie Pagan University of Washington Seattle one thing I'd like to do is just emphasize one of the comments that you made and maybe rephrase it a little and that is I think we recognize that there's a big pool of basic science information over here and a need to apply that in a clinical setting and right now that pipeline is very skinny and the concerns that a lot of us have is that LC and the LC issues that are being addressed are narrowing that pipeline further and I think you said it very nicely that the balance between the good and the possible detriments need to be weighed and I think it's time for the good to fit into that equation and help widen that pipeline rather than narrow it absolutely thank you very much Rick


Hey guys! A little bit of an interesting video here today. I just turned 29 years old today, and I thought I would share a little bit of this, this little wisdom nugget, this little story to you guys, for any of you who ever have a bad day or going through a bit of a rough time. Obviously after my second diagnosis and surgery thing, my mind was in a whole heap of random emotions and anxieties and different feelings and whatnot, considering it being the second time. To a point where I was kind of wondering if I was going through like an anxiety slash depressive attack, I was going for a walk in Langley one day just to clear my head, and I was like, okay, let's see, what's one way to test if I'm really going through like this kind of this unfortunate feeling. So I decided to walk into the Cascades Casino, which is was right next to me for some reason, and the reason why I thought this is because I don't like casinos too much. I don't know, the whole atmosphere just doesn't make me feel good.  So as I was walking through it, I was having a little bit, I wasn't feeling the greatest mentally. And then as I was leaving, I saw a gentleman fall down, this older gentleman, maybe say late 60s. He's definitely one of those typical stereotype, go and play the slots kind of guy. I saw him fall down outside around one of these pillars. I was coming through the doors on the other side and I noticed him and I could see he was getting up again. I was like, oh, that's good. Now, this is the point I should also say too, if you don't like stories about this, I can understand if you don't watch the rest of this video. But if you do, the reward of it is going to help you. I saw something come out and down this guy's leg. And I was like, Oh, is that what I think it is? And he went around the pillar and then I could see him standing. The dude had totally shot himself mud butt. He thankfully had gray shorts. So it just looked like a water balloon had exploded on his back. But I could see it going down his legs. But the thing was, this dude just kept on walking. He did not stop. And what was even more interesting, it looked like nothing had happened. He just kept on walking. Some people kind of gave him like a side glance, people who are passing him from the front, you wouldn't have thought of anything else. This is kind of the weird part. He was walking in the direction of where my car was parked. So I had to kind of follow him from afar. I wanted to ask him if he was okay. But I know that if I was in his situation, the last thing I would want is for someone to ask me how I'm doing right after I shot myself. But this guy was walking admittedly a bit of a brisk step, but he was walking as though nothing had happened. And again, walking in the direction of my car. So I had to follow him. I think he's going to his car. But no, he's not. He's walking on to the sidewalk. He turns right and he just keeps going. So when I got to my car, I stood and looked and I watched him until he eventually got out of sight.  If he can handle that, I can handle my problems. And that has honestly been a huge, huge source of help, oddly enough for me for the last few months in terms of my anxiety and just my my depressive matter. I kind of have this more mentality. Now if there's an opportunity, I'm going to take it. I'm going to try something new. Obviously I've changed how my diet is. For those of you who watched me about four months ago, you'll notice I've lost some weight. I lost about 30 pounds so far, which is pretty cool. I never expected to have a thin head again. Hell, I'm as thin as I was when I was in high school. That's just my fruit of thought for you guys. If you ever feel like you're having a bad day, if you're having a hard time, and if you feel like the world's up against you, just think of this dude. Mind you, I don't know if he actually had a little bit of a dementia moment in that moment too, because he did fall. I don't think he hit his head, but that could have been the other reason why he walked that off as though it was nothing. But either way, that's just my little story for you guys. That's my little tidbit of advice and kind of a little update about myself as well for those of you who do know me and those of you who are just new to this channel.  It's kind of a odd little thing for myself, but I thought that, you know, there was a good day to talk about this would be my birthday.  Anyways guys, I hope you liked the video. If you did, leave a like, and if you're interested in more, maybe subscribe. Otherwise, see you guys next time.


Hello, my name is Allison Hi, my name is Dylan We've been researching GCP for the last year and a half and we've come with some effective ways that compromise most GCP organizations All the ones we've looked at anyway. These techniques involve moving laterally with service accounts and cloud APIs We have a lot of ground to cover. So let's get to it.  One common thing I've observed is people often compare it to AWS I am but there are some pretty key differences between GCP and AWS I am So let's talk about some of those differences first in AWS We have user identities and those user identities can be exported in the form of credentials Which looks something like this and GCP the equivalent is a service account and service accounts Can also be exported in credentials that look a little bit differently. They look like this And in both cases we have owners of these identities But where things get a little bit different is when you start to ask the question what can my identity access In the world of AWS you basically have a policy that determines all the different things that the identity can access And the person who can create, read, update, delete that policy is the same person who owns the identity So here's an example of what that looks like In GCP though this is where things start getting really different Instead of having a centralized policy for a given identity we have policies for resources So in this case we've got a bucket and a bucket owner and that bucket has a policy The bucket owner controls who can create, read, update or delete that policy And that policy applies to whatever identity the bucket owner wants it to So here's an example of what that looks like for storage What's interesting here is that the owner of the service account actually doesn't have any insight into this policy They can't view it, they can't update it, they don't even know that their service account was given access to this bucket Instead the bucket owner controls this and if the owner of the service account doesn't have IAM list on the bucket Then they won't be able to even see that that policy was granted And I think this is one of the harder concepts it was for me personally to fret my head around in GCP Is if you have an identity in GCP like a user or a service account As the owner of that identity you can't actually know what that identity has access to In fact no one can answer the question what does a service account have access to Instead resource owners control what the policy is for a given resource So you can answer questions like who has access to this bucket But you can't answer questions like how many buckets does the service account have access to Or what buckets does the service account have access to Those questions are unanswerable by design in GCP Likewise we can have other resources like BigQuery for example And we have an owner for the BigQuery and a policy for the BigQuery And the owner of the BigQuery can again grant access to any identity they want However the owner of the service account has no control over this and can't see this One thing you might be wondering is before when I mentioned that the owner of the service account can't fully answer the question What does the service account have access to You might be thinking well if you own an organization can't you just get the IEM policies of all the resources in the organization Well someone outside your organization can still grant your service account access to their resources So when I said before you can't actually answer the question what does your service account have access to It's true you cannot get the answer to the question because people outside your organization can also grant access to their resources We'll come back to that later and explain what an organization is and how it's structured But for now I figured I just mentioned that in case you were wondering As you might imagine not having control or visibility into what your service account can or can't access comes with some challenges And one particular place I think those challenges manifest themselves is in a multi-tenant Kubernetes environment Google has a managed Kubernetes engine that's often shorthanded GKE If you're familiar with Kubernetes you have a bunch of nodes and within those nodes you have workloads In GKE those nodes are powered by VMs and those VMs have service accounts attached to them If we take a look at console we can see a Kubernetes cluster here that's powered by four underlying nodes Then if we hop over to Compute Engine and click on VM instances we'll see the same four instances And if we click into one of them we'll see that we have a service account that's attached to it We talked a little bit about how workloads interact with the service account in our B-side San Francisco talk this year So feel free to check that out But in short anything running on the node can access this identity So it's a good idea to de-scope it and not give it many privileges But let's think about what that actually means We have a Kubernetes admin that runs the nodes and the service account powering the nodes And then we have a bunch of developers that run the workloads on the Kubernetes engine Those developers may be on separate teams and may be in control of separate resources from each other and from the Kubernetes admin So you can imagine in this case we have dev1 and dev2 that have both deployed workloads, workload1 and workload2 Likewise they both control resources In this case we'll say that they both own a bucket And they want their workloads to be able to access that bucket One really easy way to do that is to just give the service account on the node access to the bucket But the downside to doing that is instead of just giving their workload access to the bucket They'll give every workload access to the bucket The developers in this case control this story They control what the service account has access to because they're the resource owners The Kubernetes admin does not control this and cannot see that this even happened So you can imagine in a situation where you have a small team of Kubernetes admins that are trying to maintain a cluster That want to open it up to give many developers the ability to deploy workloads to this cluster It can be difficult to secure because they can't control what the service account attached to the nodes has access to And some developers may want to just give that service account access to resources Rather than using something like Kubernetes Secrets or Vault to pass credentials to those workloads They may choose to just give the service account attached to the underlying node access to their resources But when they do that, they give all workloads access to their resources Not just one workload And so you end up in a situation where a Kubernetes admin who wants to onboard developers into their cluster Ininvertently gives every new workload access to a bunch of resources Even though they can't even see that or have any control over it Okay, now before we go any further, it's important to point out that up until this point I've kind of implied that resources are like these standalone entities that receive single role bindings directly to them And while resources definitely can operate that way, most of the time they're actually bundled together into groupings And there's a role binding that goes to the entire group of stuff So instead of getting a role directly to a bucket, you instead get a role to a collection of buckets So fundamentally, there are four nodes, resource nodes within GCP There's an organization node, which is the parent node This is generally associated with your domain or cloud identity service There are folders and projects All of these different top level nodes are mostly used for IAM And something that's important to note within the resource hierarchy is the concept of IAM inheritance Where wherever you have an IAM binding to one of these top level nodes Your IAM binding is also going to be inherited to all subsequent or child resources within this hierarchy So if I have a role binding at the organization, I have access to all subsequent resources that are created within the environment Same at the folder and project level Generally users mostly interact with resources at the project level That's where services like buckets, compute and general services that you may interact with on a day to day basis are Now let's dig into a few different IAM workflows and try to understand why project level IAM bindings are so prevalent in GCP If we navigate to IAM and we go to grant a member access to our resources What we're doing here is we're actually creating a project level role binding Which will give this member access to all resources within our project If we wanted to create a resource level IAM binding We would actually need to interact with the resource specific API and set the IAM binding there Another IAM workflow where a user is prompted to create a project level role binding is when you create a service account When we create a service account we'll actually be prompted to set a project level IAM binding that will grant this service account access again to all resources within our project So we can see that when you go through general IAM workflows you are going to always be setting a project level IAM binding Your IAM binding is also going to be inherited to all subsequent or child resources within this project Here we can also see something called conditionals This is an advanced feature within the IAM service that does enable you to set more granular IAM policies But also at the project level within your environment So I think that's really interesting that the main IAM button in the UI actually takes you to the project level bindings A lot of people don't even realize that you can do resource level bindings Because you have to actually click through into the resource to see that there are IAM settings there And a lot of people just assume that if they go to the IAM page they get the whole IAM story So when we backtrack a little bit to when we were talking about resource owners and service account owners Realistically what would actually happen is you would have project owners And within those projects you would have resources and service accounts So before when we were talking about role bindings we mentioned this idea of Kubernetes nodes Having service accounts attached to them And developers deploying workloads to the Kubernetes cluster and granting them access to resources But more realistically what that would look like is they would grant that node access to their entire project Because again IAM bindings are typically done at the project level So instead of granting the node access to a single bucket they would grant it access to all buckets within a given project Now this isn't always the case sometimes developers do resource level role binding And it should also be noted that the UI isn't the only way to apply these role bindings You can also apply them via Terraform or via CLI It's pretty common for developers to do it at the project level Because most of their first exposure actually comes through the UI Okay so if we recap to the earlier section you might remember when we talked about service account owners We mentioned that the service account owner can't actually know what access their service accounts have Well it's not really the whole story really what we have as a project owner And then that project owner has a bunch of service accounts in their project And then those service accounts have access to stuff And the project owner doesn't really have the whole story of what their service accounts have access to And so you might imagine how that can start to become dangerous is when I hand over access of my project to someone else I don't really know how much access I'm handing over because again I don't even know how much access my service accounts have in my project So if I hand that over to someone else I'm handing over an unknown amount of access So what is an example of this look like? Well we have a project owner that knows the email address of a different project service account They can then give that service account access to their project through an IM binding And then that service account has access to their project's resources Now one question you might be asking yourself is why you would even need a cross project role binding But when you think about it when you have two projects they're not particularly useful unless they have some way to talk to each other And one common way to do that is through Google Cloud services like PubZub or Storage And so it makes sense that we would want to share some resources between projects But again where things sort of start to become more dangerous is if we share service account access between projects Because again project owners don't really know what access their service accounts have So we're missing out on some important existential questions like how interconnected our projects actually are Because again we can answer questions like who has access to a resource But we really can't answer questions like what does a service account have access to So we came up with a solution that let us sort of answer this question within our own organization We can't actually get the complete answer to the question again because of these things called cross organizational bindings But at least within our org we can get the answer for cross project bindings By just introspecting every individual project that we own and pulling all the IM policies We then took all that information and we made a graph out of it We actually went over to GitHub and we crawled a bunch of IM policies that people either intentionally or accidentally committed And we took all those policies and we kind of compiled this pseudo org generator So let's take a look at one of the graphs we ended up with As you can see there are two different colored nodes There are red nodes and there are blue nodes What the red nodes represent are projects and what the blue nodes represent are service accounts Those are the only two things we're graphing here Then there are two different types of edges There are contains edges and there are bindings edges A contains edge is basically when a service account lives in a given project And a binding edge is when that service account has a role binding to that project Most of the time a service account has a role binding to the project that it's contained in But every once in a while we'll end up with a service account that has a role binding to a different project A cross project binding So in this case we have a service account that's contained in project number 67 And it has a role binding into project number 57 If we zoom out we get the view of the entire organization We have all the different projects here in a map And we have all the relationships of the service accounts within the org that are contained within these projects Now we're not looking at organization level bindings in this graph Or resource level bindings We're only looking at the project level bindings And we're mapping these relationships So because we base this off of real IAM policies that we're able to pull off GitHub We can say with some level of confidence that this is an accurate representation Of what a sufficiently large company might look like We can also say with a little bit of personal experience Based on the large companies that we've looked at This is an accurate representation of what a sufficiently large company looks like Now again most of the time a developer is just going to be the owner of a single project And they won't really see the whole picture All they'll see is sort of tunnel vision for the one project that they have control over And so they'll see the service accounts that belong to their project And they'll see what has role bindings into their project But they won't know where their service accounts have role bindings out of their project And so when they hand off access to their project to another developer They won't actually know how many additional projects they're handing off And they themselves may not have a good understanding of how many projects That they have access to through their service accounts One other interesting thing that we found here Is that there are certain projects that have seemingly disproportionate Large numbers of role bindings and resources in them We found this was a pretty consistent story At multiple companies that we looked at And so in the center here you can see there are a bunch of projects That have really tightly bound role bindings And then at the bottom we have smaller projects That only have one or two service accounts That may not be connected to the broader web And then we have a bunch of projects that have no service accounts What we found is that most of the sensitive data Or sensitive workloads are in the interconnected projects Where most of the development is happening And so it makes sense that it would have most of the IEM role bindings Connecting it with other projects So when we first started building these graphs We were thinking to ourselves Oh gosh, these projects are supposed to be isolated boundaries Are they really this interconnected? And the more we dug into it And the more we thought about how project owners Can't actually see the role bindings Their service accounts have been granted We realized this is a problem that's really remained invisible And it really takes this org level introspection to even see it Now there's one final piece here that we haven't talked about yet And that's when a developer actually does hand over Access to their project to another developer Pieces of that might be okay It might be okay to share storage for example But things start to become really dangerous to share access to service accounts Because again, that's where the problem is hidden Where the owner of the project doesn't actually know What access their service accounts have And so if we share that unknown access That's where things can start to go astray So we'll come back to what roles and permissions Are actually required to hand over that level of access And we'll talk about how common that is And so far we've talked a lot about roles And mentioned that some are more dangerous than others So now let's dig into that a little bit more Within GCP there are three distinct types of roles that you can use Primitive, which have been around since before Cloud IM that we know today Predefined roles, which are curated by GCP And service specific And custom roles that enable developers to specify Any permission that they would like That is supported to fit their services needs Let's focus on primitive roles Within primitive roles, there's an owner role Which provides all of the different permissions That are available within the platform An editor role, which closely resembles the owner role But excludes a few different things for administrative capabilities And that just might not be supported yet One thing in particular that's excluded Is the ability to set project level role bindings And the viewer role, which is exactly what it sounds like It allows you to view resources But not perform any state changing actions How are these primitive roles used? Well, earlier we saw that when you go to Cloud IM through the UI These primitive roles are what are first suggested to users There's another way that these primitive roles Manifest themselves within your GCP project And that's through default IM role bindings Whatever identity creates a project Will automatically be granted a project level role binding Using the owner role So we know that the owner role Contains all of the different permissions that are available But what about the editor role? Well, the editor role contains at the time of this talk 2,576 distinct permissions That's a lot This means that with the editor role You can, for example, access all buckets All databases, all VMs And much more within your project Out of these permissions that we talked about earlier Which of these roles actually enable a user to manage service accounts? Well, both the owner and the editor role do While the editor role does not enable you to create new service accounts Or apply project level role bindings for service accounts It does allow you to manage service accounts in two different ways And that's by creating keys or credentials For a given service account that already exists And by associating a service account with a resource So if a user can create a resource Specify a service account GCP will go and check If this user have the IAM service accounts act as permission On the service account that they're attempting to associate with the resource If so, it gets attached And then that user can interact with GCP services and APIs As that service account identity and its associated role So how common are these IAM roles in GCP projects? There's another way that GCP creates automatic role bindings for identities And this way is a little bit different When you enable a specific service such as Google Compute Engine It will go and create a default service account in your project And then grant that service account a project level role binding Using the primitive editor role that we chatted about earlier This also happens with another service When a user enables the App Engine service A service account called the AppSpot service account Is created in your project and also granted a project level editor role binding Now as we discussed earlier That editor role contains a permission that enables identities To associate service accounts with resources So that means that both of these default service accounts The Compute Engine and the AppSpot service account Are able to associate any service account within its GCP project to a resource So where are these service accounts used? The default compute service account is associated with GCE VMs by default So whenever you create a VM The default compute service account is automatically associated with the VM There's one thing to note about service accounts And the way that they are authorized to interact with services from a VM There is the role that they have as well as something called scopes And scopes define from within the VM What services and APIs can that identity interact with Regardless of the role binding that they have By default for VMs scopes are restricted to only a few Particular services like storage From what we have observed Developers will commonly open these scopes up So that they can interact with many different services And how are the AppSpot service accounts used? Cloud Functions are Google serverless offerings Which are similar to AWS lambdas They're meant to just be lightweight ephemeral small chunks of code That run fast and exit once they're done If the App Engine service is enabled within your project When a developer goes to create a cloud function That default AppSpot service account with an editor role binding Will be associated with cloud functions by default When you create a cloud function You actually do not have the ability to specify to set it without an identity You always have to associate an identity with the cloud function So if you don't know to create a new service account And associate with your cloud function You'll always be using the default AppSpot service account That has that editor role binding Cloud Functions do not have scopes And get all the permissions of the editor role And coming back to the VMs A lot of managed services leverage VMs as their underlying infrastructure Things like GKE, Dataproc, Dataflow They also get this default compute engine service account associated with them In AWS when you spin up something like a VM or a lambda It defaults to having no access There are no roles attached But in GCP, things default to having thousands of permissions Earlier we talked about cross project role bindings The ability to leverage service accounts in a project To get access to other service accounts And potentially move laterally across GCP projects We talked about developers potentially not knowing what access their service accounts have We mentioned the idea of handing off access And what this realistically looks like Is the developer applies a role binding with the act as permission Like the editor role Let's look at what that could look like Now it's demo time To help understand how to exploit the act as permission To start out, we need a base identity There are a number of different ways to get a base identity One way for example is you could Oauthfish a developer that has project level editor access Another way is maybe a developer accidentally uploaded a service account key To github or payspin And that service account has a editor level role binding Because the primitive roles are the first thing that are suggested to you on the IAM page Or maybe the most likely Maybe the base identity comes from exploiting a service And because most services run with project editor by default Maybe that's how you get your first foothold In any case, in this case, we've simulated this By just starting with a service account credential We can see this credential here And we can see that it starts in the project BBS2 Next, we'll run the list operation on the G-Sploit tool We can see that there's no output The reason there's no output is The list operation lists all the service accounts that you've managed to take control of And it doesn't count the base identity We'll run the gcloud command projects list on the base identity To see what project we have access to It looks like we have access to BBS2 Next, we'll try and act as exploit on this project And we'll target every service account in the project Let's unpack what's happening now Keep in mind the editor role has two ways to take control of all the service accounts in a project The first is through creating tokens And the second is through provisioning resources There's another role that we haven't talked about yet And that's the service account user role This role is also pretty common And is often given to users in service accounts that are meant to provision resources Because some things like cloud functions require service accounts to be attached to them This is the role that's usually granted to do that So because the service account user role and the editor role both have the act as permission We'll use that to take control of the service accounts Because it casts a little bit wider of a net than the token creator permission Which is only in the editor role So what G-Sploit is actually doing under the hood here Is first it's running the service account list operation To get a list of all the service accounts in the project And then it's spinning up a cloud function for each one of those service accounts Then we keep a database of all the cloud functions we've harvested Each which has its own underlying service account attached to it This gives us access to all the service accounts in the project Through the cloud functions that we spun up We control the code that lands on the cloud function So we'll just deploy code that allows us to run whatever gcloud commands we want It takes about two minutes to spin up each cloud function So we'll just speed through this really quick And now when we run the list command again We can see all the new service accounts that we now have access to One of them says owner That service account actually has an owner level role binding to the project that we started in That means we now have full control of the project through this service account If we wanted to we could use this service account to add ourselves as owners to the project So just to pause and think about that for a second What that means is if you ever have a service account that has editor level access And another service account that has owner level access The editor level service account can always privilege escalate itself to owner That's the same with developers If you grant developer editor level access to a project But you happen to have a service account in that project that has owner level access That developer can privilege escalate themselves to owner through that service account Okay, let's take another look at those service accounts that we have There's one here that's kind of interesting that says do nothing It might not sound interesting, but keep in mind that the developer that created that service account in this project Although they didn't intend to give it any role bindings Again, the owner of the service accounts can't control the role bindings And so it's possible that a different project gave it a role binding So let's run the project list command from this service account that we've compromised Something interesting here that the base project, BBS2, doesn't actually show up when we run this command This is because the service account has no role bindings there The developer didn't want it to have any role bindings But BBS3, this new project we haven't looked at shows up What happened here is the developer in another project granted this service account And editor role binding into their project So let's run the act as exploit one more time This time from this do nothing service account into BBS3 And see how many service accounts we can harvest in BBS3 Again, this process takes a little while, so we're gonna fast forward through this And now we can see a whole bunch of new service accounts in the BBS3 project Service accounts that we didn't have access to before That we were able to get strictly through lateral movement There's a couple of service accounts in here that look interesting There's one that's labeled networking that maybe controls networking for the organization But probably most interesting is this one that's labeled organizational admin If while you're moving laterally through projects You happen to land on a service account that has an org level binding Through inheritance, you get access to the entire org that way So to recap, we started with a base identity in BBS2 that had act as on the project We then used that permission to gain access to every service account in this project Via cloud functions One of the service accounts in BBS2 had an owner role Which allowed us to elevate privileges in the BBS2 project A different service account had a role binding into BBS3 This allowed us to use act as to take control of all the service accounts in BBS3 One of the service accounts we found in BBS3 had an organizational role binding And this allowed us to take control of the entire org So we talked about when you provision resources When you attach service accounts to those resources GCP will check to make sure that you have the act as permission first Before allowing you to provision the resource Because some APIs like cloud functions require that you have identities to power them This leads to a lot of people getting the act as permission Well, it turns out that some APIs will actually allow you to provision resources With a service account attached to them without the need for the act as permission These include the data proc, data flow, and composer APIs Let's talk about the data proc API The data proc API is Google's data processing API Among other things, it includes Managed Apache Hadoop and Managed Apache Spark When you spin up a data proc cluster, like a lot of things in GCP It will default to using the default compute engine service account This means by default your spark jobs will run as project editor You only need the permission data proc cluster create to spin up this cluster You don't actually need the act as permission on the default service account Because of this, anyone who has the data proc cluster create permission Can actually make use of the default editor service account Put it other way, service accounts that are only intended to be able to spin up Data proc clusters can privilege escalate themselves to project editor And then they can make use of that act as permission To take control of the rest of the service accounts in the project We built support for this into G-Sploit So let's take a look and see what it looks like If we take another look at the list of service accounts we've compromised There's one here that says data proc Let's run the gcloud projects list on this service account And see what projects it has access to Looks like it has access to a bbs4 Now let's run the data proc exploit on bbs4 Through the data proc service account We have to spin up a whole data proc cluster to do this And that takes a little bit of time And then we delete it afterwards so that we're not built too long So we'll fast forward to this part But at the end of it when we run gcloud list again We can see a new service account has been added And that's the default service account in the bbs4 project We were able to get this service account by spinning up a data proc cluster in bbs4 And then running a spark job on that cluster Which enabled us to grab the credential off the instance Because our data proc service account credential Had the ability to spin the cluster up It also controlled the scopes for that cluster And so we just defined the scopes for this cluster to be wide open Next since we have a default editor service account credential at this point We can run the act as explained on this project We'll again fast forward to this process And finally if we run the gcloud list one more time We can see a whole bunch of new service accounts that we now have access to in the bbs4 project So just to recap Some APIs in GCP do not require the act as permission To spin up resources and attach the default service accounts to them The identities that can spin those resources up Can also control the scopes So effectively in cases like data proc and data flow And Composer Any identity that's granted permissions to those APIs Can privilege escalate themselves to project editor One last thing to note here Is because this data proc role binding was actually cross project This allowed us to again compromise the new project bbs4 And because the default service accounts are in every project This allows us to take control of all the service accounts in the new project Google has a new feature in their asset inventory API Called the IEM Analyzer We worked with Google on this feature And one of the user stories actually came from us We came up with a list of dangerous roles and permissions That can be used to take control of all the service accounts in the project These can be seen here We won't demo data flow and Composer But you can think of them as working the same way as data proc Using the IEM Analyzer and the dangerous permissions that we were able to find Were able to run a bfs search on a base identity Without the need to spin up expensive resources exploiting services As you can see from the output here We get the same list of service accounts from the same base identity as we did exploiting things Except this was much faster We didn't have to spin anything up You need an org binding to use this So this is a tool for defenders to be able to get quick answers To how an attacker might be able to move laterally through the organization If we cut back to our mock graph Let's move into a seemingly innocent base identity This service account, guadvcl Was meant to only run spark jobs in its base project 14 It only has the data proc editor role Now we'll run a bfs search from the starting identity And highlight the path in blue As you can see this allowed us to compromise all the service accounts in the starting project Through the default editor role on our spark job Most of these service accounts have benign roles Like storage or pub sub And most of them are not cross project That said, some, like this one Have dangerous role bindings that are cross project In this case, the Dataflow developer role These allow us to take full control of service accounts in different projects As we start to zoom out, we can begin to see the whole picture We've managed to compromise most of the service accounts in the org With a few notable project exceptions That just don't have any dangerous role bindings to them We're only looking at project level bindings in this graph So if any of these service accounts have org level bindings It's not reflected here So we just saw some really interesting techniques Around privilege escalation and lateral movement But we also wanted to provide a way to detect this So we fingerprinted this tooling And we'll be releasing monitoring and alerting To detect the behavior of this tool in your environment I think one of the nice things about doing security work in the cloud Is how much help you get from your upstream provider If we were doing work on a web application or a binary We'd kind of be left to our own vices to fix the problems we found But because we had a close partnership with Google We were able to work with them to roll out some new features That help with the security story of some of these problems One of the people that helped us do that Is a security engineer named Bakunov And we gave him an invitation to do a brief cameo And talk about some of the new features that we helped Google roll out Hello, Black Hat I had the privilege of working with Allison and Dylan As a result of our collaboration We at Google Cloud launched several features That helped customers address concerns On the prevention side of things We now have an org policy constraint That prevents the editor grant To the default service accounts for Compute Engine and App Engine And we advise customers to turn around We recommend that customers create Custom service accounts With the necessary set of permissions On the target resources As opposed to the broad project level editor grants Allison and Dylan Briefly touched upon the investigative IAM Analyzer tool As you saw, we built IAM Analyzer To be able to address the use case Of finding resources Which are granted access to any specific identity The other investigative feature available Is the IAM Recommender It uses machine learning to evaluate The permissions granted to an identity Against actual activities Performed by the identity It's a great way to find overly generous permission grants And to identify the actual permissions That are needed for the workload I spent many years working with all Major cloud providers And this statement is generally true for all of them Starter cloud UIs Those flows are optimized for ease of onboarding And so the fundamental challenge For large organizations Is to make available Samely secured defaults As well as preventative guardrails For their developers Those are usually in the shape of Cloud foundation code bases Such as infrastructure code samples That are built with security in mind Policy as code evaluations As part of the build and release pipelines And preventative controls exposed by the cloud providers Such as org policy constraints On GCP And the accuracy of those Starter UI flows on the cloud providers Or Stack Overflow code snippets We're gonna end up in a bad place If you're a Google cloud customer And are looking for guidance in this area You should try to engage our account team So that we can help out Alison and Dylan, on behalf of Everyone at Google cloud We are very grateful for the collaboration On improving our customers' experience On the platform and for the opportunity To have a cameo appearance in this talk 2021 happens in person And we can share stories in the face-to-face setting Until then, please wear face masks And don't forget to turn on two-factor authentication Wherever possible Thank you Thank you, Bach. We also wanted to provide some context And a little bit more insight And let you know a few of the limitations Or constraints to these tools So one of the main limitations to the organization policy Services you actually have to have An organization resource Either through cloud identity or G Suite To use the organization policy service If you only have projects You won't actually be able to leverage any of the constraints That are available Another limitation within the organization policy service Is that constraints are not retroactive So when the policy is applied All resources will be affected by the policy Or evaluated by the policy After it is enabled But existing resources will not be modified To match or meet the requirements Of a given constraint Another thing to note is that for the new And grants for default service accounts That constraint will only Enforce that when the APIs are initially enabled For new projects that the default Service accounts are not granted At the time of the APIs being enabled But there is no enforcement mechanism To ensure that the default service accounts Are not granted a Project level binding or other binding There's also no way to restrict The cross project Bindings that we talked about previously Where if a user knows the name of your service account They could still give The service account access to their project Or project's resources So the IAM recommender is very powerful Some of the limitations on the tool Is that you have to have a 90 day period Where the policies or behavior Of a given identity are evaluated So that you can have a recommendation be made And there may be more IAM bindings That you may not be aware of Like the cross project bindings The IAM analyzer can provide a lot of context For the IAM bindings or associations For a given identity And in order to use this Auditing tool you have to have Administrative capabilities in an organization To be able to see the policies That are being analyzed So in order to use this tool to the fullest extent You need administrative capabilities In your organization as well as Within G Suite if you want to Expand group membership to know Who has access to a given service account That is in a group How Kubernetes workloads have access To the underlying service account That's attached to the node And the suggested way to harden Your clusters is to use a service called Workload Identity And Workload Identity allows you to Associate a Kubernetes service account With a cloud identity And this is how you can harden your cluster As well as have a one to one mapping Of Kubernetes service accounts To cloud identity service accounts We brought up earlier to ensure Project level role bindings or other Role bindings after the Disable automatic IM grants for default service accounts Constraint is enabled That you require additional tooling And to demonstrate a way that you can Enforce these configurations We will be releasing a Terraform Enterprise Sentinel policy set that can Demonstrate enforcing that default Service accounts are not granted project level Role bindings or that roles That enable service account Takeover or management of service accounts Cannot be applied at the project level Sentinel policies are Terraform Enterprise Policy configuration language That enable you to Either restrict or alert On specific configurations in your runs So just to recap Some of the key takeaways IM and GCP is very resource centric Meaning that if you are a service account owner You may not be aware of the configurations That are associated with that service account Or how it may be used across a GCP organization This can lead to projects being interconnected In many different ways that you may not be able to see Role bindings are often done at the project level And can grant more access Than a user intends to A lot of managed services and general resource Provisioning operations Can hand off access to Your project's resources and IM That you may not be aware of This kind of access that's granted through resource Creation can lead to Privileged escalation and lateral movements Within your environments Another thing we covered is that default service accounts Are granted administrative roles Within your project automatically And that's with the editor role Unless you're using the disable automatic IM grants For default service accounts organization constraint Reduce usage of default service accounts Where possible by creating Service specific service accounts With IM roles that are scoped to your services needs There are a few new cool tools In the platform that have been released To assist you in understanding Who has access to your service accounts Such as the IM analyzer And also be really helpful for understanding IM dependencies and access Within your environments


Hello, I'm Rebecca Murphy and I'm a developer at Boku and in this video I want to talk about how you can use objects to reduce the repetitiveness of your code Let's take a look at an example of some repetitive code that we can clean up using an object So this is a simple function and what it does is it uses a selected location Probably selected from a select drop-down or something like that It uses a selected location and then sets a maps center and sets a maps zoom level Depending on which location was chosen And we can see when we look at this that this is some pretty repetitive code And it's basically three if statements that do something slightly different depending on which location was chosen But the basic contents of those if statements doesn't really change all that changes is the latitude and longitude For the location and of course the zoom level So we can clean up this Function by using an object. Let's take a look at what that would look like We'll recreate our function Down here And of course the first thing we want to do we are still going to need that selected Which location was selected? So we'll grab that The next thing we're going to do is create a locations object And that locations object is going to have three properties on it It's going to have Ireland as a property and We'll assign that an object. It's going to have Claire as a property and assign that an object It's going to have Dublin as a property and again, we'll assign that an object and Inside each of these per location objects. What we're going to do is enter the latitude the longitude And the zoom level for the location And so we'll grab that Copy it down to here and to here and Then we'll take the data from up above and move it into These objects So now we've created a locations object that contains all of that information that changes Inside of those if statements and all we have left is what doesn't change inside of those if statements So let's grab the content of one of those if statements and we'll pull it down to here and adapt it to what it needs to be now that we have Removed all of that location information out to the out to the locations object So the first thing we need to do is it actually get you know Assuming that someone has chosen Ireland as the location in the in the select menu We need to actually get this object So the way that we'll do that is say our location equals locations and then we'll look up the selected location In that locations object so we'll do that using bracket notation and This will this will let us look up Ireland or Claire or Dublin Next we'll say that var Center equals New Google Maps lat long and then we'll get the latitude and longitude From that location object So again if the user had chosen Ireland then location dot lat at this point points to this value And location dot long points to this value So now we want to set the center on that new center and finally we want to set the zoom to The zoom property of that location object. So that in this case would be six if a user had chosen Ireland This New function is it has the same functionality as the function up here But it has a few benefits number one We aren't repeating the same code over and over and over again And that has payoffs as far as maintainability and as far as your sanity Especially if you ever have to change that code, you don't want to be changing it in three places The other benefit that we got here is that it becomes really easy to add a new location We don't have to write a whole new if statement in order to support another location We just have to add another property to this locations object and pass in that that information for that location and You can even imagine a case where you might get this locations object from the server So it doesn't have to be hard coded into your JavaScript anymore. It's something that could change So you get a lot more flexibility by using an object for this purpose In addition to the benefits that you get just from having more dry. Don't repeat yourself code Thanks for watching I'm Rebecca Murphy and this was a bokeh training production You