Kevin Greene -- Shifting left

0:02Chris RomeoWelcome to season 3 of the Application Security Podcast. In this episode, Robert and I interview Kevin Greene from MITRE. Kevin wrote an article recently about shifting left in the world of software, and specifically with secure DevOps. So we talk about that article, and then we also get into this idea of codifying intuitions, which is another way of thinking about the security mindset. And Kevin talks to us about a few new projects at MITRE that will help you as you are building out your application security program and working with developers and testers. These are the CAWE and ATT&CK. So we hope you enjoyed this conversation we had with Kevin Greene. The Application Security Podcast. Here we go. Hey, folks. Welcome to this episode of the Application Security Podcast. This is Chris Romeo, and Robert is with me as well as my co-host. And in this episode, we are joined by Kevin Greene.

1:27Hi, everyone.

1:28Chris Romeofrom the MITRE Corporation, actually. And Kevin, thank you for being here today.

1:32Kevin GreeneHey guys, thanks for having me and happy New Year.

1:36Chris RomeoYeah, definitely. Happy New Year to you as well. And Kevin, I have to— I chuckle now. I remember when you and I actually met, you might not remember this, but we were both out at AppSec USA a couple years ago in San Francisco, and it was during the opening. They have this opening kind of social event And you and I were both kind of hiding from a social event in the hotel bar off to the side, and we happened to sit down next to each other and strike up a conversation there.

2:02Kevin GreeneNow, I remember. I remember.

2:05Chris RomeoWe were both being antisocial to some degree at that time, but it was great to get to meet you there. And then this conversation kind of came right out of that. So, Kevin, we always start by asking our guests, what is your security origin story? All great superheroes have an origin story. It's at the beginning of the comic book. In the world of security, what's your origin story? How'd you get started in this stuff?

2:28Kevin GreeneAs Biggie Smalls would say, it was all a dream, right? But no, no, I started, you know, I kind of started organically. I was working at Verizon, well, at the time it was Bell Atlantic, and after graduating from NJIT, in New Jersey. I moved down to Maryland, Silver Spring, Maryland. I started working, you know, as an analyst right out of college at Bell Atlantic at the time, Verizon. And I was getting my master's degree, distance learning from NJIT, because Bell Atlantic had a facility where you could do distance learning. And I always was interested in security and trying to advance my career and so forth and so on. So I would I would come in at night. I would work a full shift. I would come in at night doing change controls. At the time, change controls were at midnight, a little after midnight. And I would watch the guys do firewall updates and so forth and so on. It was a guy named Joe Morris. He was really big on proxy firewalls and stuff like that. So I kind of learned from that perspective and started getting into firewall stuff. Around that time, It was around the big boom of the dot-com world, so I went to go work for a really small startup company. They were managing firewalls for— at the time it was called PSINet, which was an ISP provider. And then from there I went to E&Y, Ernst Young. And at that time when I was at Ernst Young, we were doing pen testing. That's when pen testing was really, really big and really started out.

4:06Okay.

4:07Kevin GreeneUm, we call it ethical hacking at the time. And that's around the time where, you know, the guys with Foundstone was at E&Y, Stuart McClure was there, George Kurtz was at E&Y around that same time. So I kind of— that's kind of how I started. And then eventually, you know, I wanted to evolve my career and kind of always wanted to pride myself on being well-rounded, you know, really good at different things because I want to do more on consulting side. And what E&Y gave me— Ernst Young, I should say— E&Y gave me the opportunity to do that. And then I just started, you know, following, you know, read a lot about where the market was going, and I got into AppSec, and I wanted to be in a position where I can, you know, evangelize and guide organizations in how to build AppSec programs, formalize AppSec programs. And then eventually got into R&D, went on with the DHS S&T Cybersecurity Division And I was running a software assurance R&D program, which really opened my eyes up to a lot of things that I, I took for granted. A lot of times we take certain things for granted that certain things exist, but they don't really exist until you really test them out and validate these things. And I think working with some really, really smart minds in academia like Bart Miller, Dr. James Hill, Henny Sittma from Kestrel, and there's a number of other folks It really opened my eyes up to a lot of different things and really gave me a really good idea of where the state of the art was in terms of state of the art, in terms of tools and technologies, as well as state of practice. And, you know, I tried to fund really, really good sound R&D topics that really can advance not only state of practice but state of the art.

5:43Chris RomeoSo you had an interesting kind of switch there between the private sector and then being able to go in and work in the government space. So, I mean, what is the difference? Is there a big difference? difference in how security is perceived and understood from the government space versus kind of the private sector that you worked in?

6:04Kevin GreeneWell, I think so. And primarily because of FISMA, uh, the whole certification accreditation process, and the fact that, you know, I always say, and I wrote an article on Dark Reading about the difference between security and compliance, and you could be secure and not compliant, you could become— be compliant and not secure. So I think a lot of times that heavy weight in terms of doing those mundane tasks, very, very manual, very rigorous in terms of these paper drill exercises, sometimes get in the way of really doing what's best. And a lot of times if you only got so many hours in a day, if you spend a lot of time trying to be compliant, you lose cycles and resources in doing some of the necessary hygiene things. that we see that are so essential to protecting federal networks and systems and applications. So I see that's like something that has to be done, but I think organizations struggle, agencies struggle in trying to strike the right balance and to comply with some of the federal mandates that they have to comply with.

7:11Chris RomeoYeah, and it seems like everybody seems to still be struggling at this point. We kind of focus in on the world of AppSec and looking at it through that lens, but It's hard to find somebody who's really killing it right now where you can go, you know, that organization right there is really doing a great job with everything because we all know the next vulnerability is a week or 2 weeks away that we probably don't even know about today. So, that's the fun in what we do.

7:39Kevin GreeneRight.

7:39Chris RomeoSo, you had a recent article here on Dark Reading where you were talking about this idea of shifting left. And so, what I want to spend the bulk of our time here today is really understanding, with you kind of explaining what does that actually mean. A lot of our listeners are relatively new to the world of AppSec, and they may not have ever— they may not even really truly grasp this concept. So, let's start with this idea of shifting left. When you say shifting left, Kevin, what do you actually mean?

8:06Kevin GreeneWell, you know, well, first of all, shifting left, I mean, you know, in industries, you know, you have to be somewhat think about things in, in a realistic way because a lot of buzzwords, a lot of different jargons are always thrown around and people don't quite understand it. But, you know, I thought it was very necessary for me to, um, especially because, you know, working in different, different realms of AppSec and software assurance, you know, I have a different perspective on, you know, where, where the gaps exist. Not saying that my way or my view is the perfect way, but I think I have a unique view coming from the R&D side, coming from an operations side, and coming from a program side as well. So shifting left to me is fundamentally the way we think about security. It's a mindset. Now, it's not a catchy phrase that we often hear— build security in, shift left. Those are all catchy phrases, but at the end of the day, what I really wanted to get across in the article is it's a mindset that has to be pervasive throughout the software development lifecycle. And security must be at conversation, must be the seat at the table, uh, and must lead the way to a certain extent. Because at the end of the day, when we build requirements, we have to, we have to have security in the conversation so we're building good security requirements so that we can build good design, so that now we can take the design and implement it correctly in software and in code. So that's kind of my my focus is shifting left. You know, obviously with the whole DevOps or secure DevOps phenomenon that's going on, a lot of what we hear is continuous integration, CI/CD pipelines. Well, shifting left is moving further left from that, even from that process. I think we were on— I was on Twitter maybe a month ago, and my buddy Jim Manico said that you can't test— you can always test security in, And to, you know, you can't test security in because oftentimes, um, 50%, I should say, of security issues come from design and design architectural issues. So if 50% of actual security issues come from design, then how are we addressing design? We have to move further left. And I think, you know, we start from beginning and build the right mindset where there's a shared responsibility across not only the product team but developers, security architects, operations folks, I think we'd do a better job at, you know, one, reducing the attack surface and also reducing risk that's associated with poorly developed, poorly designed software.

10:40Chris RomeoYeah. And Jim is a good friend of the show. He's actually been on— was on 2 times last season to talk about different stuff with OWASP Top 10 and then the Proactive Controls Project. And he'll be back with us again in a couple of episodes to talk about this OWASP Cheat Sheet project. So he's a great one to quote and a great resource for us in the world of application security.

11:02Kevin GreeneRight. So I was motivated by so many issues that we see in industry regarding to everyone wants to do DevOps. And I think over a period of time, we're moving faster, we're building faster, but is security keeping up? I think that has been One of the biggest challenges we've seen is security keeping up with the rate in which we're developing software. We're moving at a very, very fast pace. So with these rapid release cycles, that's part of the whole DevOps movement. So security has to be at the forefront of everything that we do.

11:42Chris RomeoYeah, and one of the big challenges that I've seen in working with different organizations that are attempting to move into this DevOps kind of space, and especially with teams that are established in the world of DevOps before they start to think about application security, is really the— it's just the speed at which they're doing things. They're really— so, what have you seen in your travels here as far as what are the challenges that people are putting up or the, you know, what are the excuses that folks are giving for why they can't shift left? Yeah.

12:21Kevin GreeneWell, one of the biggest fundamental things I think is people just don't know how. They don't have a good strategy, and that becomes the crux of the problem. And once the train gets moving, you know, it's very— and it gets some momentum, it's very hard to slow it down.

12:39Chris RomeoYep.

12:40Kevin GreeneSo from the onset, I think not having a really, really good sound strategy is one of the biggest issues that I see that, you know, you set yourself up to fail when you don't have a good approach, a good plan, a good strategy in place on how security should be governed throughout the entire process. The other thing is, you know, tools just don't perform well. I mean, we start talking about AppSec tools, specifically static analysis, and even some of the web application security testing tools, they just don't perform well. The coverage areas is very narrow to a certain extent. These tools have not kept pace with the rate, the rate in which modern software is being developed. So people get frustrated with the tools. These tools generate a lot of false positives, and because they generate a lot of false positives, developers get frustrated because obviously they have to spend so much time doing triage, finding the actual security vulnerabilities that really matter, you know, amongst a, a, a wealth of false information. Um, so they take the tool out the tool chain and stop using it. And now we're building software and we don't have the proper tools to provide the necessary assurance levels that our software can be trusted and that we did a good job at testing it for potential weaknesses that can expose vulnerabilities in software. So I see that as a a recurring theme no matter where I go, uh, is one, not having a good plan approach, and 2, we want to move fast, but automation is a big part of it. But how do you automate security testing tools when the tools don't perform well? So I think that has been, you know, a core, a core problem, um, in terms of trying to, you know, shift left. But even beyond that, you know, people just don't communicate well in organizations, whether it's the product team with the security team, these silos, these barriers. You know, you got to go in this thing all in or it won't work. Meaning you can't wink wink, give a wink wink and nod and not be fully committed to building the necessary collaboration and communication that will break down those silos so that security is really a shared responsibility. So I think those are some fundamental issues that I see are some of the struggles that we get when we try to shift left.

15:04Chris RomeoYeah, and I'm going to guess based on that, a couple of statements you made, that you're not super popular with the tool crowd. Is that based on just making that? And I agree with you, I don't think you're wrong. I'm just saying they're probably not inviting you to their open houses. No.

15:24Kevin GreeneYou know, from an industry standpoint, I think I'm— I have pretty good relations— relationships with Chris Wasopoulos, folks from Sigil, folks from HP. I mean, I have pretty good relationships with those guys. I just think from where I'm looking, from my perspective, and where I've been the last 5 and a half years, you know, I— and working with some really smart folks in computer science and academia, I mean, there's a lot to— there's a lot of improvements that needs to be made from the static analysis tools as well as some of the web application security testing tools. And one of the biggest problems is when you buy a tool, you don't know what the tool can and cannot do. You don't have any ground truth in terms of what the tool can actually cover. So I think from the start, I think that's a big problem. So if I'm— so it becomes a problem of what tool is the right tool that best matches my software assurance needs.

16:26Chris RomeoYep.

16:26Kevin GreeneAnd without having any really good insight into that, you could potentially buy a tool that's not the right tool.

16:32Chris RomeoYep.

16:33Kevin GreeneSo one of the things I was trying to do with my STAMP project, which is Static Tool Analysis Modernization Project, when I was at DHS, is really try to remove those barriers, create a little bit more transparency in that process, and have a way to provide labels, I should say, and those labels provide the key attributes and characteristics of the tools. Basically, here's the sweet spot of the tools. So now when people want to go use Static Analysis tools, they can now select the best tool that matches their software assurance needs.

17:04Chris RomeoYeah, I think you were right on in that approach. I've seen so many different companies that have tools and they're just not even using them. They have them so that they can say, hey, yeah, we have that tool, but they're not actually scanning any of their code with it because they can't make it work because they didn't get the right tool to begin with to do the job. So, yeah, that's a great approach you took there, and that really does help the industry. So, I want to kind of ask a question here about— there's a term that you used in the article, and it was codifying intuitions. And so I'm fascinated by what you kind of mean by codifying intuition. So would you unpack that a little bit for us and give us some perspective on what that means?

17:53Kevin GreeneSo sure. Another colleague of mine, David Molnar, who's a security researcher at Microsoft, they have a video that I was watching, and the video talked about what can security learn from AI, artificial intelligence. And I heard this term codify intuition, and as I started watching the video, I was like, wow, okay. But the way in which they were using it, they were losing— using it more from the adversarial side, more around APT and how machine learning can help, uh, provide, you know, some, some, some traction, some gains, and help solve some issues that you see on that side of of the problem space. So I began to think and ponder, like, wow, what if we leverage the same concept? And I was motivated by that as it relates to software development, but more so where the article talks about is more on the DevOps side. And one of the unique things that, as I was researching the whole concept of intuition and the whole notion of what it means to codify intuitions, I should say, I came across something that Einstein had mentioned in one of the things when he started talking about intuition. And what he says is, you know, our intuition is basically the outcome of earlier intellectual experiences. So then I said in the article, you know, so many of us build software, break software, fix software, whatever the case might be. These are things that are part of us. We are learning as we are breaking, building software. These become part of our intellectual experiences. So why can't we take those things and relay it to the way in which we develop software? So I kind of said, okay, you know, this is a, this is a very unique concept that I want to kind of, you know, start evangelizing around the whole DevOps space and specifically around shifting left. And the way we think about the problem space, complex problems, you know, requires some creativity, some curiosity, and our intuition has to lead us. Our past experiences, which is our intuition, have to lead us to building better software. So how do you codify that into the process early and often. And one of the things I mentioned in the article is there was a researcher that was part of the talk and he is currently, I think he's at Georgia Tech, I believe. And he was talking about, I think he interviewed a known hacker, Um, Jung Wong Lee, I believe. I'm hopefully I'm not mispronouncing it. Um, and he asked them like, how do you find exploitable vulnerabilities? And, and part of what he said was his intuition leads him to find some of these exploitable vulnerabilities, basically his past experiences. I said, wow, if that can happen from the attacker adversarial side, why can't we then, you know, transform that into doing it doing it early in the process, be more proactive how we address software development, especially as it relates to DevOps. So that's kind of how that concept came about. I was looking at a video from a Microsoft presentation I thought was very unique and interesting. I wanted to kind of put a twist on it from, from the whole software development side. I like that because I was thinking in looking at the article as well that, you related that also to threat modeling and architecture and design and thinking through intuition and applying that. And I've done that myself in thinking about threat modeling and using my past experiences with development architecture and thinking about how do you then apply those things to software security or thinking about security in the software. I like that tie-in. That's a—

22:01Yeah.

22:02Kevin GreeneIt makes sense to me. I like that. Because think about it, I mean, you know, most hackers, you know, they, they, they've seen something somewhere, or they came across something somewhere that leads them to try something. And not knowingly, they, they don't really equate it to their past experience, their intuition, which leads them to do the things that they do. So I just think, you know, You mentioned threat modeling. I think threat modeling has been the one capability that's been undervalued, underappreciated, and I do see it, as I mentioned in my keynote at DevSecCon, is that threat modeling can now become an engine and really improve the efficiency of how we do testing. And I've kind of alluded to that in the article, because, you know, a lot of times these tools don't have context that is needed to really make sense of the data that they have. So if we can now pivot the tools into areas of the application that are sensitive, then we can be more— we can guide these tools to be more efficient in your testing. And that's kind of the whole notion of what I mentioned in terms of, you know, the, the role in which I think threat modeling is playing. But specific to the article, you know, if we can potentially leverage user stories and kind of, you know, this all ties into a certain extent to threat modeling, use user stories, right? And then develop the right abuse and misuse cases to validate those user stories. Uh, we have a better idea of how to build the functionality that's being requested securely. We want to do it securely, right? So that's kind of how I see, I would like to see, you know, certain organizations or organizations in general approach shifting left and really using this method. You know, each time a product manager have new features and functionality, I think the whole team needs to think about it. from a security perspective and use the user stories and misuse and use cases to really model threats for those new features and functionality that needs to be added.

24:24Chris RomeoYeah, that sounds like really good advice there. And Kevin, so kind of as you were closing out the article here, you had a couple of different activities that you described, practices and standards that you described people take a look at here. to help them with the threat modeling and the whole shifting left kind of idea. The first one, I'll be honest, I've been around AppSec for the last decade or so, and I wasn't aware of the first one. So the first one that I saw on this list here was Common Architectural Weakness Enumeration. So I'm certainly familiar with CWE, Common Weaknesses, but I hadn't seen the CAWE. So can you tell us a little bit about what that is and how folks could use it?

25:05Kevin GreeneSure. That was something that I initially funded when I was at DHS S&T as a program manager. I wanted to really understand the impact of design decisions in terms of security. What role does design decisions play in introducing vulnerabilities to the development process? Right. The common— the CAWE, Common Architectural Weakness Enumeration, basically is a way to help developers think about the consequences of their development activities or refactoring decisions on the overall design of the system. So over a period of time, if I have a design and the security patterns that are part of the design and the developer has to implement those security features and tactics into code, if they're implementing the design wrong in code, over a period of time that design erodes, which creates an exposure of the attack surface, which creates vulnerabilities. So that was the whole notion of the reason why I initially funded some work like that, but I do think that because we are looking from the design perspective, there's ways to codify these things into user stories and use CAWEs to do that.

26:31Okay.

26:32Chris RomeoAnd you also talked about, you know, with user stories, how you can use CAPEK and the AT&T and CK kind of from the codifying intuitions perspective here. So, I think our listeners and, you know, I know I'm familiar with CAPEK. AT&T and CK was a new one that I hadn't seen either.

26:53Yeah.

26:55Kevin GreeneSo KPAC and ATT&CK are basically work products from MITRE. KPAC really focuses on weaknesses types and their attributes across the kill chain. ATT&CK focuses on platform-specific observed adversary tactics and techniques, basically focusing on characterizing, describing post-compromise adversary behavior. So that's kind of The brief definition of both. So if we can use KPAC, basically is essentially the weakness types and their attributes across the kill chain to develop really, really good misuse and abuse cases, and then also leverage ATT&CK to really look at the post-compromise adversary behavior, then we can determine whether or not you know, the extent to which whatever we're trying to build, the impact it has on security. So that's kind of the whole notion of using CAPEC and ATT&CK to really build really good, you know, misuse cases to see, to see if whatever is being offered up can be abused in a way that compromises security before it's actually designed, right? So that's, that's kind of the notion behind that. No, so one of the things that I think is important to look at is, you know, what's the impact of authorization, authentication? Like, what are these different type of things that are very vital to security? Or what are the trust bounds of the system? And how can, you know, a service be abused or misused to gain unauthorized or elevated privileges So it's looking at these type of things before the system is even developed to give people a better sense of what additional security needs to be in place, what additional security controls need to be in place, and what are some design decisions that need to be made up front about whatever functionality features that needs to be developed. Did that make sense?

29:00Chris RomeoYeah, that definitely makes sense, and that helps me to understand how ATT&CK— and plus I know now that I'm supposed to say ATT&CK and not A-T-N-T-C-K. So that helps me to sound cooler in the AppSec community as well. But it definitely helps to understand how those 2 fit together. And it almost seems like somebody needs to build a tool that includes both the CAPEK and the ATT&CK together and allows you to model your design against those 2 data sources. Sounds like, just to me, sounds like that'd be a really cool type of technology innovation to help engineers or software developers be able to see the impact of the decisions that they make.

29:38Kevin GreeneWell, one of the things that MITRE is doing now is building a unified ATT&CK framework to allow tool vendors to leverage this to do these type of things. So, you know, think of it as being tool agnostic, and any tool can potentially leverage this framework to either, you know, build on top of it, build, you know, use the synergies that's part of the framework, to really look at the different risks and threats that are associated with systems, applications, and networks.

30:12Chris RomeoOkay, yeah, that sounds cool. I look forward to taking a look at that when it's— is that something that's out now or that's something that's in development?

30:19Kevin GreeneThat's something that is out now. You can go to https://capec.mitre.org And you can get information there. And I think ATT&CK is the same, attack.mitre.org. And you should get information about both of those really, really unique and really cool work products that we've developed through our sponsors.

30:47Chris RomeoOkay, awesome.

30:48Kevin GreeneAs well as, and I should say, as well as community involvement.

30:51Chris RomeoYeah.

30:52Kevin GreeneDon't wanna leave out the community.

30:53Chris RomeoYeah, the community is huge in anything. It's hard to do anything that's, doesn't have community involvement.

30:58Kevin GreeneThey're very vital to allowing some of these projects, some of these community things to really be vibrant and have a lasting impact in the community. I mean, obviously adoption is important. Tech transition is very important. So the community becomes very vital to to allowing these things to grow, organically grow. And we need feedback and we need the community to continue to do what they do to support these work products so that we can, you know, help improve software assurance practices. Yeah, cool.

31:40Chris RomeoWell, we'll put a, we'll put a link to the Dark Reading article in the show notes here so our listeners can go and read the full kind of explanation. But Kevin, thank you for taking the time today to take us through through this conversation of shifting left and DevOps and codifying intuitions. Lots of really good stuff here, and I know our listeners will appreciate it. I know Robert and I both appreciate it. So, thank you for taking the time today.

32:04Kevin GreeneHey, Robert and Chris, it's been a pleasure. Chris, it's been a minute, and I'm glad you have me on. I enjoy what you guys are doing. Continue the good work and much success in 2018.

32:25Thanks for listening to the Application Security Podcast. If you enjoy the podcast, please do us a favor and visit the iTunes Store and give us a 5-star rating. Our intro music is 8-Bit Kung Fu by Born and TJ, and the outro is Southern Delight by Stefan Kartenberg. You can find us on Twitter @AppSecPodcast or on the web at www.appsecpodcast.org.