How to launch a career in application security

Chris Sienko: Hello and welcome to another episode of CyberSpeak with InfoSec Institute. Today's guest is Dan Cornell, the Chief Technology Officer at Denim Group. Dan's had a diverse and interesting background in all things tech, but his primary specialty is web application security. We're going to talk to Dan today about his career journey, and some of the steps you can take today to enter a career in ABSEC.

Globally recognized application security expert, Dan Cornell, holds over 15 years of experience architecting, developing, and securing web based software systems. As a chief technology officer and a principal at Denim Group Limited, he leads the technology team to help Fortune 500 companies and government organizations integrate security throughout the development process. He is also the original creator of ThreadFix, Denim Group's industry leading application security program management platform. Cornell was Principal Investigator as Denim Group researched and developed the hybrid analysis mapping technology that lies at the heart of ThreadFix, through a small business innovation research contract with the Department of Homeland Security's science and technology director. Dan, thank you for being here today.

Dan Cornell: Thanks for having me.

Chris: Great. Let me start out today by asking you a bit about your professional journey. How did you get interested in application security as a practice or a vocation?

Dan: I'm a software developer by background. I have a computer science degree from Trinity University, where, as a liberal arts university they train you to learn new things. But a big part of that computer science education was vocational training to be a professional programmer, or TO go on to grad school. But my role was more to become a programmer. So in the mid to late '90s, I did a lot of early work with server side Java, doing development of E-commerce sites, work flow systems, things like that. In the early 2000s, doing some work with early versions of Microsoft's ASP.net web framework.

But I'd always had an interest in security, and so following along with the research that the folks at the Loft were doing and then commercialized in Loft Heavy Industries, as I said, we were doing development of e-commerce sites and so when you're dealing with credit card information, that's a concern that you had. So security was always something that I was interested in.

Then in the early 2000s, I met, who is now one of the other principals at Denim Group, John Dixon. John Dixon, his background is-

Chris: Former guest on our show, I should point out as well. We talked about hacking the mid-terms.

Dan: Very good. Yeah.

Chris: Wild one.

Dan: But John's background was as an Air Force information warfare office, intel officer. His career followed a much more traditional information security background, [inaudible 00:02:44] Air Force, and tried data systems, KPMG information risk management and I met him through some contacts and we got to talking and he said, "I see what you guys are doing in the application development space and I have a background that is very traditional for the security space." And as we got to talking, the conversation became like the really interesting things that were happening in the security space had a lot to do with applications.

So you look at organizations and hopefully everybody's got a firewall and they've locked it down. But they poke holes in the firewall or it's AD and 443 web applications. And so from an attacker's standpoint, that started to be a very attractive attack vector. So in the conversations, John said, "I see the application security challenge, but people with my background that make up the installed base, if you will of the professionals in the security industry, don't know anything about development. If we did coding, it was in COBOL or FORTRAN, way back in the day.

But most of the people in the security space come from either John's background from the military and from an audit's standpoint, or from a systems administration background into penetration testing and things like that, but they don't necessarily know about web application development, they don't know about integrated development environments. They don't know the lingo, they don't know the tools and that's a real challenge.

So that is what led to Denim Group's application security practice, is essentially saying from a chocolate and peanut butter standpoint, what if we took the risk management focus of information security and applied that to the discipline of application development and software development. So that's really how my interest got weaponized or professionalized or however you want to look at that.

Chris: Okay, let's go back and sort of be very granular about how you got to the point where meeting John, you had the skills and background that would say, "Hey, let's get together and collaborate." So going back to college, or your studies and stuff, what were the classes, the degrees you got? What were the activities you were doing right out of college? What were the steps along the way to get you from X, Y to Z?

Dan: Again, a pretty standard computer science education at a liberal arts university, so a lot of algorithm design, data structures. I took electives in networking and I've had a particular focus in undergrad on graphics and simulation activities. That's what I wrote my undergraduate thesis on. But also taking classes in discrete numbers and in theories, some artificial intelligence theory and things like that.

So what I consider to be a pretty well rounded liberal arts, computer science background. But it was interesting because we... security was never really mentioned. It was always something that was considered to be a separate thing. The only times that we talk about security, we figured out ways that you could use mis-configurations with the X-Window systems and the computer network could put funny windows on the professor's workstation.

We also learned in networking class that you can Telnet to the mail court and fake emails as if you were a professor, but that was really the limit of what, from an undergraduate standpoint at the time, was available from a security focus. What I'd seen later is certain universities had security classes but they were very focused on cryptography and the math associated with that, which is, I think, very comfortable for academics and for people who are interested in that and it's obviously an important branch of security, but there wasn't a lot of focus on the practical aspects of information security, at least not in a broad-based way.

So graduating from school, I had started a business with Sheridan [Chambers 00:06:44], who's one of the other principals of Denim Group and another fellow and we did a lot of, as I said, e-commerce development and server side Java workflow system development. We also did some web hosting and so we were managing a number of Linux servers and security was a concern there, but in retrospect we probably did a bad job.

We weren't great systems administrators. We were excellent coders, we were poor at systems administrators and we were abysmal security architects and engineers.

Chris: Was that just because no one was good at the time? Or, was it just a learning curve on your part?

Dan: Certainly the world was much less mature.

Chris: Right.

Dan: And again, our primary focus was we need to write these e-commerce systems. We figured out we could make a couple of extra bucks if we host them, and if we host them like, "Oh well, we also need to do patching and let's turn off some ports and make sure we have a firewall." So the security was like several layers out from our primary concern, which was, "Well, we can make a whole lot of money writing these e-commerce systems for people. That's our main focus."

So really it was something where, we never got to a size where we needed specialized security folks and it was a startup, so everybody was doing a little bit of everything. So that was also again, kind of fed what was an ongoing interest in security, those were some of the responsibilities that we had. We're securing the systems that we had and that our customers were on.

Again, that led to those discussions with John Dixon down the road at Denim Group. We'd sold that previous business and gone on to do other things and Sheridan and I started Denim Group and then John joined up very shortly thereafter. We were still doing application development, but also alongside that, working with organizations, helping them with the application security.

Our background, it was interesting coming into the world of security from a software development background. I think that that has helped me from a career standpoint, helped the organization, because we understand what software development looks like. We've done waterfall software development, we've done Agile software development, and now as we see organizations transitioning to DevOps, it's a very natural thing for us to understand as well, because we understand the challenges that software developers face.

So that's something I think has been very helpful for me to be much more pragmatic because security is obviously an important thing and from an application security specialist's standpoint, that is a very important thing. But I think it's also important to be able to take a step back and look at things from the perspective of the developer to say, "Security's important but there's a lot of other things that's important as well, and in a lot of cases, more important."

Chris: Right. We've been hearing that pretty regularly amongst industry leaders and so forth, that it's always going to be more helpful to you to know all the steps along the way. All of the different possibilities, not just how to plug the security into whatever you're working on. You need to know the thing that it's being plugged into.

Dan: Yeah. If you look at the bulk of... a scenario I like to throw out to people, more security purists, is if you look at two software developers and one of them delivers all of their code on time, on budget, meets the deadlines and delivers whatever innovative functionality, whatever your organization's promised to customers. If you look at that software developer, but maybe they didn't pay any attention to security and you contrast that software developer with a developer that builds everything with perfect or near perfect... focused very much on security and the secure aspects of the system, but misses all their deadlines and never delivers functioning software. What are the career arcs of those two developers going to look like?

I suspect that one is going to have a long and fruitful career and one of them is probably going to have to find other work before-

Chris: Get left behind, yeah.

Dan: Right. Obviously, the reality is a blend of those things, but I think that it's important for security professionals to recognize that security is very important. If you look at organizations that are undergoing digital transformation, it's critical for security to be a valuable risk management resource, but you also understand that you have in the spectrum of things that developers do, security is only one, right?

At the end of the day, that team needs to be delivering value and to the degree that you can, as a security professional, provide risk management and advance that value, you're going to find yourself to be more sought after by people in your organization.

Chris: Because we're helping to try and educate people to become more sought after and because I know many of our viewers who watch these, might have only minimal IT or cybersecurity or security experience. Can you walk me through the day-to-day activities of an ABSEC specialist or other?

Dan: There's a number of different roles if you look at applications security. There are roles where an application security person is going to help the team that are building software. There are roles where someone in applications security is going to be testing the security of software. And there are roles where the application security weighs in on the ongoing running of software. Some people break those up into builder, breaker, defender. That's one way to look at it.

I don't know if, from a software developer standpoint, I don't know if that many software developers wake up in the morning, get out of the bed and say, "Looking forward-

Chris: [crosstalk 00:12:17] Put on my breaker hat -

Dan: [crosstalk 00:12:18] building. But if we look on the... I think what is most common that people think about in applications security space or in security in general is security testing. So the breakers. So the day-to-day activities there may be doing security code reviews, so using automated tools to scan code. Looking at the results that come out to remove false positives or re-characterize those results and doing manual review of code for security weaknesses to find the kinds of vulnerabilities that the scanners just aren't able to find.

Or, doing dynamic testing of applications, web applications, web services, mobile applications where they're, again, potentially using automated scanners, cleaning up those results or, using things like web proxies to make fake requests to web applications to see if they can make those applications behave in a way that they're not supposed to.

Again, so doing testing of dynamic or running systems. So from the breaker side, that's again, running tools, cleaning up tools, doing the manual testing and then characterizing those results to communicate to the development teams because at the end of the day, and this is one of the really interesting things about applications security. At the end of the day, the developers have to do something typically to make the software more secure.

So that's really important is to understand as a person doing testing, you have to be able to communicate with those developers to let them understand, "Here's the risk, here's what the problem is, here's why it's a problem, here's the risk and here are the things that you need to do in order to be able to fix that."

So that's what, from a breaker or a tester side of things, those are the typical activities. From the builder's standpoint, it's a question of, "Hey, how do I help these software developers while they're building software to help them avoid introducing problems?" This is an area that I think is really important and is often overlooked.

A lot of organizations look first and say, "We've got all this software, let's break it." Again, that's a natural entry point, but if you look at from a value standpoint of over time, if you can work with development teams and maybe you're helping them build threat models. So to understand, "Hey, developers. Let's talk about the architecture of the application that you built or that you're building. Let's understand how the pieces fit together and let's overlay some security concerns on there, so that we can plan for mitigations for those risks. What do we need to encrypt? Where do we need the authentication and authorization? How do we plan early on to build security into this software?"

We've seen a lot of organizations adopting what we call a security champion's model, where they embed a developer in a team or spread across teams to act as the voice of security for those development teams. So if the developers have questions, "Hey, I'm thinking of transmitting this data, is there anything that I need to be concerned about?" Or, "We're about to connect to this system, what do we need to worry about?" They've got a local resource that can provide answers and potentially reach into a central security organization for additional information.

So that's a pattern that's worked very well because it provides to the developers a resource they can use and that helps to allay their frustration. There's nothing more frustrating as a developer to build the system, with no one having mentioned security the whole time [inaudible 00:15:35], then you get dinged later on and they're like, "Oh, your developers must be stupid because look at all these security problems." Well you haven't trained them to do this correctly. They had no resources available, no recommendations. It's kind of like an unfunded mandate dropped on people after the fact.

So from a building standpoint, which I think is a really exciting area, that's the type of day-to-day things that you might be doing. From a defender's standpoint, again looking more operationally, you may be operating protection technologies, like a web application firewall, a real time application security protection, looking through logs, watching for potential attacks and helping to defend against those. So that's again, more of an operational... for things that are run in production.

So that's how I view the main roles that you see in the application security space, which is cool because there's... I don't know if there's something for everyone, but there's something for people with a lot of different backgrounds. That's operational, systems administration type of work transitioning helping people defend. Whether that's someone from a network pen testing background, looking to test the applications. Or, whether that's someone from a development background saying, "How do I expand my expertise in the security area so that I can be a resource to people that are building software?"

Chris:

I suppose it depends on the size of the organization, but I'm assuming that these three roles, the breaker and the defender and the builder, tend to be different people, or is there a lot of fluidity in terms of one day I'm doing this kind of thing, one day I'm doing another kind.

Dan: So that really is going to depend on the size of the organization and the size of the application security team. I think that in a lot of organizations, if you looked at a histogram of size of security team, I think that zero is probably going to be the most popular number of the size of the application security team. [crosstalk 00:17:25] one-half of FTE to full-time was probably going to be the next most popular one. It's going to drop off pretty quickly.

Chris: Sure.

Dan: So in a lot of organizations, we talked to people that said, "I've been hired on and it's my job to spin up or startup this application security program. I've got all these things to do. Do I want to start by testing some stuff? Do I want to start by retesting developers? Do I want to look through some logs and see if we have some existing problems?"

Again, in a lot of organizations, that's going to be one individual that has to split their time between those types of roles. Or, concentrate in one at the expense of another. In large organizations, you start to see more specialization. "Hey, we've got our red team, we've got our web [inaudible 00:18:09] over here, we've got our mobile red team over here. And we're starting to roll out security champions and we've got this level of penetration across our dev teams."

Again, it's going to depend on the size of the organization, the size of the security team and then the size of the app security team.

Chris: Folks of our age I suppose, you said when you went to school, there weren't really security classes to be had, or not as much. But what do you believe... do you think that certifications, are there certain certifications you think that interested ABSEC aspirants should pursue on their path to becoming an ABSEC professional? Do you believe there's a role for professional education and study and learning the ropes of security? Or, is it still a trial and error kind of situation?

Dan: So I will expose my bias. I am personally not a big fan of security certifications.

Chris: Okay.

Dan: So filter my comments through that bias. I think if you look at the security industry, I think there are some that, especially if you want to advance through the ranks in security, you'd be looking at things like the CISSP, that are more generalized security certifications, but that I think are viewed in a lot of organizations as table stakes to mid to senior level security roles. So, that's something that's out there.

There have been some application security certifications that are out there. Again, it's something that I haven't looked deeply into because it's not something that I view as really centrally important. One of the things that we've found to be valuable in hiring people for application security roles is looking for folks that have a background in software development but then have gone on to get a Masters in Cybersecurity.

A master’s degree in cybersecurity, that's just something that we've found to be helpful with our culture and with our organization. That's a background that we've found to be helpful. Again, other organizations, their mileage may vary because we're looking for folks from often a security testing side of things, and that's just a demographic or a resume pattern that has worked well for our hiring.

Chris: So, that's sort of a step process. You do the original education and then you just go out in the world and learn some stuff, but come back for your Masters once you have the fundamentals in mind and then you concentrate, once you have the tools and then refine them. Is that what I'm hearing?

Dan: Yeah. Just looking at credentials or background, the most successful people that we've found and the application security space come out of a software development background. So what we've found is that it's easier to take a software developer and teach them about security than it is to take a more generalized security professional and to teach them about application development.

Dan: So I look at my background growing up, as a kid I did a lot of programming and that was something that because I was really cool-

Chris: Same.

Dan: ... [crosstalk 00:21:12] up through school and got my computer science degree with my math minor. [crosstalk 00:21:17] I was cool in college, too. I continued to be cool, but that was something that I spent a non-trivial amount of time on growing up. So if you look at the hours under my belt that I have coding, even before I started undergrad, and it's not that I was the master wiz kid coder, but it was something that I was familiar with and I knew. It was something I spent a non-trivial amount of my four year degree doing.

Very much time on our startup development e-commerce sites and things of that nature. So if I look at the level of proficiency in development and the understanding of the development process, a lot went into me gaining that. So, to say like, "Oh, let's focus in on the security aspects of that and someone teach me about authentication authorizations, someone teach me about some crypto engineering and things of that nature, that's a smaller syllabus that you've got to chew through, as opposed to if you've got someone who has a lot of experience with security. And you're like, "Okay, let's write 'Hello World'".

Okay, how do you get from Hello World to modern, cloud-based application stacks? There's a lot more steps along the way. So that's something for application security professionals, it is tremendously valuable to have background in application development, just we found that takes a lot of time to gain that experience.

Chris: Okay. So let's break down the raw activities. What hands-on work activities should you be really good at and enjoy doing every day if you want to be in ABSEC and so forth? What would something like you're going to be doing this every day so you better be really good at it?

Dan: Right. Especially for security testers, you'd better be really interested in breaking stuff, right? And how do I make this system behave in a way that it's not supposed to? At the end of the day, it goes back to the MIT hacker ethos of a clever solution to a problem, especially when applied to security, when the problem is "How do I get this information that I'm not supposed to have? How do I make the system do something that it's not supposed to do?"

Certain people have that interest and other people don't. That's been an interesting thing looking at taking QA people, people with a QA background and trying to move them into security. Some folks just really have a desire to figure out how do the pieces fit together and how can I make them do things they're not supposed to do?

So for the security testers, it's that kind of problem solving and that willingness to look at things in a different way in order to get things to break. From a builder's standpoint, I think it's important to have a focus on education. It's very helpful to like to teach people. And to understand concepts at a level where you can communicate them to others, because that's a big thing you're trying to communicate to these developers. Or, to get them to understand and to learn a new thing. To say, "Hey developer, you're a great web developer. Let me teach you about some things that you may not know about. Let me provide you a new perspective, a new way to think about these things."

So from a building standpoint or a developer support standpoint, I think really liking to educate people and interact with folks in that way is really important. I'm less familiar with the skillset for the defender type stuff. I think they probably need to look at log files and again, solving problems. To look at patterns in data to find out, what are we seeing here? And how do I connect that to potential malicious activity?

Chris: Right. Pretty much everyone I've talked to in the career track field says communication and the ability to communicate your ideas is going to be crucial. I think that always needs to be reiterated, that you can be as slick as you want, but if can't get other people to get onboard with your ideas, or tell them where they can change or whatever, it's all going to be for nothing.

Dan: Well especially in security and in application security. Whereas a tester, you have to communicate... the metaphor of you've got to tell people that their baby's ugly, right? Like, "Hey, you developed this software where you're very proud of it, you hit it on time, on budget. Here's how I can make it do a whole bunch of stuff it's not supposed to do."

That's something that we've seen a lot of challenges with looking at other people in the field where the relish in breaking things is fantastic. Sometimes you need to split that role of the people that are breaking stuff with the ones that communicate why things are broken.

Chris: Why it's broken.

Dan: Again, coming from a testing standpoint, you do have to be looking at [inaudible 00:25:55]. Like here is a problem, here's why this is a problem, here's why this can happen in production and the impact that that will have and the risks associated with it. Because again, when you're looking at people fixing security vulnerabilities, if I'm a developer fixing vulnerabilities, I'm not building new features and I'm not fixing other bugs.

So as a risk management professional, you need to be able to communicate to the developers and, most importantly to their management, to the line of business to let them understand, of all the risks that are out there, here are the ones that we consider to be very serious, where it makes business sense, where there's value in fixing these to manage risk, as opposed to greater value in building a new feature or supporting a customer a certain way. Because at the end of the day, you're never going to be able to fix everything.

And smart businesses will view this again through a risk management lens. You can't eliminate risk, you have to manage risk and at the same time, your primary focus is not to have great security. You want to have security that's good enough so that you can bring innovative products to market and not suffer undue damage while you're doing that.

Chris: Right.

Dan: So communication is critical for security folks and that's something that I think is tradition and that a problem with a lot of folks in the industry, in security the focus is so much on the risk management, there's a lack of the communication skills to put the things that you're worried about from security in the broader business context of, "Hey, I'm willing to accept some of those risks because we need to move faster and we're willing to take some lumps along the way because if we can be the first to market with this, then there's going to be a lot of value in that." Or, not delivering this to the customer is going to have a financial impact that we know about as opposed to an unknown risk or a more vague risk of loss if there is some sort of security incident.

Chris: You mentioned that a fair number of companies might, if polled, would say, "Well, we have zero people in ABSEC or we have point five, or whatever." What type of companies, organizations or industries tend to require a specialist in application security. Do most companies have ABSEC teams? Or, I guess what industries would... if you want to get into it, where should you be looking?

Dan: Right. Again, looking at this from a risk management lens, it's really a question of how much value does your organization derive from software? And from the applications that you're developing? And how much risk are you exposed because of that?

So if you look at... the really early adopters were the folks in the financial space, the banks because when they have problems they lose money. That pain of losing money is great or driving behavior change.

Chris: Mm-hmm (affirmative).

Dan: Where you see less so in other industries where there's a less direct thing. So when we look at organizations, the organizations that we work with, again the banking, insurance, financial services, those folks both feel the pain and have regulatory concerns and so they have a focus on application security.

What we also see are a lot of organizations that are smaller and growing but again, where they're deriving a lot of value from software and applications. So if you look at a lot of startups, well the entirety of their value is this app and the associated services and the social network or whatever that might be associated with it. So those organizations also tend to have applications and security teams because again, the risk to them is if someone is able to steal our data, that's [inaudible 00:29:38] do whatever, that has a large impact on us.

So really what it comes down to is a question of how much value does the organization derive from the software they're developing and looked at through the lens of scale of the organization, application count, as well as the regulatory compliance. What I think we'll see is, I think it was Marc Andreessen's essay about how software is eating the world, right?

So more and more companies are becoming software companies, right? That's a requirement. And as we see that infrastructure starts to be defined as code, as we see the world get much more code-centric and the skill of coding being more required, I think that's why we're seeing a tremendous increase in the demand for application security professionals, because the world as a whole, is deriving much more value from software and is exposed to much more risk from software. So that drives a demand for more of a workforce that can help address that.

Chris: So for the benefit of folks who are watching or listening to this podcast, who are thinking about changing career paths who are not maybe on a security path, or a software development path, what is one thing they could do in their current position that they could change that could move them one step closer to achieving this? Because sometimes it seems impossible like, "I'm not anywhere in this, but I don't know where to start." So where would you start?

Dan: I guess there's two parallel tracks, there are a couple of things that people could do. One thing that I would recommend for a lot of folks is to learn, at least to some degree, to do some coding. Not everybody's going to be a software developer. I don't necessarily know that everybody wants to go through some sort of coding bootcamp, although that is a route to learn some of that stuff. But there are a lot of resources out there to at least learn some scripting.

"How do I use code to make stuff happen?", just to understand the pieces and how it fits together. And again, that's something where... it's a long road to gain a tremendous proficiency there, but it's something that a lot of people in IT can, at least, understand how the pieces fit together and how things work.

Fortunately, there are also, for people that are interested more in testing, there are a lot of resources out there. So if you go to, for example, the Open Web Application Security Project or OWASP, it's an International organization. It's a non-profit. They do a number of things. They run conferences, which are fantastic. They run local chapters, which is a great way for people to get introduced and a free way to some talks and some resources about this.

They've got a lot of materials like documentation that they've published and they also had some tools. So they have a tool called OWASP ZAPper, the Zed Attack Proxy. So that is an attack tool that does dynamic web application testing, both automated and supports manually. There's great documentation around this, there's a great supportive community. So there's a free tool out there, multiple free tools, but that's an example of a free tool that anyone can use to start doing testing.

Now, you've got to be careful what you test. You don't want to go to your local bank and start testing their site. They might not be thrilled for the help you're trying to give them. Fortunately, there are a number of intentionally vulnerable web applications and other applications that are out there that OWASP has the old school on this one called Webgoat, there's a newer one called Juice Shop, sorry. So those are web applications that have known vulnerabilities in them where you can go and do testing against those applications and get a feel for what does a testing process look like?

How do I solve this puzzle. I know there's some vulnerabilities in here. How can I get data out of the application I'm not supposed to be able to? How can I make orders I'm not supposed to be able to and so on and so forth. The great thing is there's a lot of freely available resources out there where you can practice and build skills in a safe environment.

You also see a lot of organizations now expose bugbots. So maybe your local bank is a great place to go and do security testing, if they have a bug bounty and if you abide by the terms of that bug bounty. So that's also an area where people that are interested in this can practice their skills and also potentially earn money, rewards, recognition and things of that nature.

So that's a great thing is as the industry has needed more talent, there are resources available or people to learn both these at chapter meetings as well as documentation and tools. And organizations shifted the way that they handle bud discovery, bud disclosure to make that a lot more friendly to non-malicious folks to get involved.

Chris: I was going to ask if there were such a thing as freelance ABSEC people, but it sounds like bug bounty would be kind of a good way of developing your portfolio without being in an organization. Is that?

Dan: That is probably the freest-lance way to get it. That is a gig economy.

Chris: Yeah, are there freelance ABSEC people who come door-to-door to organizations and say, "Let me test your applications?"

Dan: That's a good, that's not a model that I know much of all that these days, certainly in the past there have been folks that have gone to organizations that, "I've found these security flaws, do you want to pay me as a consultant to tell you how to fix them?"

I don't recommend that because to discover those things, you're probably on the wrong side of one or more laws. And the organization can react by saying, "What a great idea." Or, they can react by saying, "Let me call my friends at the FBI or the Secret Service."

Chris: Release the hounds, yeah.

Dan: Exactly. But that's the great thing about the bug bounties is they had legitimized that type of testing, or provided a path for individuals who are interested in that. So again, that's a great way for people to get in to build their skills inside of a framework where they are not going to get themselves on the wrong side of the various, or very large organizations or the law enforcement arm of whatever country they're targets are in.

Chris: Bad way to start your career. So in the future, how do you think a career in ABSEC is likely to change, based on up and coming technologies or new hacker strategies or increased threats? Where is all this going in the next five years, say?

Dan: The big thing that we've seen and our practice is the cloud and associated technologies, in DevOps and associated culture changes. CIDC pipelines, like the way that software is developing and gets deployed and is managed is changing very much and that's making the world much more complicated, but it's also making the world, to me at least, a lot more interesting. So I think that application security professionals again, are going to have to have a strong understanding of let's look at these organizations that are adopting DevOps and that are making this culture change, say "We're going to break down the barriers between development and operations."

Well, let's also break down the barriers between security and see how we can get security included in this cultural shift. Again, so security can provide risk management services to these organizations and figure out how are you changing the way you're developing software? How do we integrate security more integrally into that?

On the deployment side, understanding that application... when I was managing servers, we had a Linux server and we would install a new build to the website on there. Hopefully the mail server stayed up and things like that. It was all bespoke. All of our servers, the way I've heard it characterized is like, all of our servers back then were pets. They had names. We named ours after viruses. So we had Motaba and Hanta and Ebola.

We were all dudes that were just graduating from college and we thought that was neat. Hopefully your servers aren't pets. Hopefully they're cattle, right? We're just going to spin up 20 new things in AWS or Azure while we need them, then when we don't need them, we're going to drop them down, right?

So I think also understanding that the deployment model is changing and with it, the security... it's no longer a question of, "Oh, I've got this server. Have I scanned it with a Nexis or a Nexpose or something to look for ports." It's a question of I've got this flexible infrastructure spread across one or more clouds that is allowed to communicate in certain ways. Have I configured all of my cloud servers, have I configured my cloud storage, have I configured my Z, Y, Z as a service? How are all these pieces interacting?

That's where a lot of the challenges are now. That's where we're working with organizations now to figure out, "Hey, this cloud transformation is happening, right? The agility value is too great. The cost savings, whatever, too great. We're going this way. How do we make sure that we get all the stakeholder that are weighing in on the security of the system? How do we make sure that they're all working together in a way that is seamless?"

So that's a real challenge that we're seeing now. Having a lot of fun working with organizations on is, "Let's look at," it's not just about the code, and it's not like old school infrastructure, although parts of it are still old school infrastructure, but it's also being deployed in these cloud environments and those have configuration settings and capabilities and it's really being able to look at the system as a whole and say, "Here's the risk that we see across this stuff, both from the network infrastructure, from the code, from the cloud."

That's what we're seeing a lot of the motion and where we're having a lot of fun working with organizations. So that's the next step that I think a lot of these app security professionals are going to be asked to do. Again, that's where it helps to have a development systems design coding background, because I think folks like that have a better background, or initial capability to say, "Oh, I see how these pieces are fitting together and maybe I don't understand this stuff exactly but I see how the pieces fit together." [crosstalk 00:39:47] go and learn more about the security implications of what we appear to have plugged together here.

Chris: Okay, as we wrap up today, tell me a little bit about ThreadFix, the Denim Group's web application security management platform.

Dan: Yeah, so what ThreadFix does is it lets organizations manage their application vulnerability and management program. What it came out of was a situation where we were working with a financial services organization, and the member of the security team needed to do testing for a web application line of business, fired up a scanner, configured it, ran it, generated a 300 page PDF with a color graph on the front page, went and handed it to the development team and said, "I'm from security, I'm here to help. You guys must not be very good at writing software because there's 300 pages of the stuff for you to fix."

And the question was, "Okay, which of these do I need to fix?" The guy says, "Well, this is security. It's the most important thing. You need to fix them all." I said, "Okay, well how do I fix them?" Like, "I don't know. I think there's some stuff in the report about that."

So that report gets dumped in the desk-

Chris: [crosstalk 00:40:49] later. Yeah.

Dan: Well, this security engineer [inaudible 00:40:54] they were doing perimeter web application scanning with a scanning service. Ran the scan, generated a 200 page PDF, different color graph on the front page, went to the same developer and said, "Hey, I'm back. I've got some more security stuff you need to worry about. Oh, by the way, what'd you do with that last report that I found or that I gave you?"

And the developers says, "Okay, how is this different than what we saw before?" The answer is, "I don't know, but again you need to fix all this stuff." So the developer went up through his management structure and said, "Hey, the security team came around again and this time they're actively wasting my time. But I've got these features I promised the hot shot VP, promised them to an important customer, I've got these performance bugs in production that are getting customers aggravated. All this stuff I need to do, can you give me some help with this?"

So a rock got dropped on the security professionals that you shall not talk to another developer until you can come to them with a single list of the problems, an explanation of why those problems are so serious that we need to stop doing other work in order to address them, and you need to tell them how to actually fix this stuff explicitly. You can't be wasting their time.

So the security engineer goes and pops up Excel and starts cutting and pasting things, trying to line them up. So we watch this interaction and no one was acting in bad faith, right? The security engineer was doing his job. He was trying, he would say, "I need to make the website secure. This is the way I'm going to do it."

The software developer is doing his job. I need to deliver these features and functions on a certain timeline, but the way that they were interacting was bad and the way that the tools were interacting was bad. So we built ThreadFix to address that data management problem and that communication problem.

So what ThreadFix lets you do is it lets you lay out, here's all the teams we have worldwide developing software and all the applications that you're just responsible for. You load in the results of all the testings. We talk about static testing, we talk about dynamic testing, we talk about the manual aspect potentially of both of those. And ThreadFix normalizes and duplicates all that data to give you that one list of here are the problems that are currently open for this application.

Not only lets you bundle those up and ship those over to the developer in the tools they're already using. So if they're using Jura to manage their workflow and their backlog, instead of saying, "Read this report." Or, "Log into my system over here." You can say, "Hey, I just took these 20 cross-eyed scripting vulnerabilities and I put those in your system as a trouble ticket that lives alongside all the other stuff."

So again, that shows an understanding of the developers and the tools they're using and how they've developed a strum meetings and a tempo of all these meetings and what not to manage their workload. So ThreadFix lets you manage those vulnerabilities through to resolution and then it gives you data about your program as a whole.

So from a risk management standpoint, you can take a much more quantitative view of your security program. Again, we saw these challenges organizations have with hundreds, thousands of applications, lots of data and poor communication and with the ThreadFix platform, we put organizations in a situation to help address those issues. So again, they can better incorporate security as a risk management service alongside development and operations to drive business value.

Chris: Dan Cornell, thank you for being with us today.

Dan: Well, thank you so much. Really enjoyed it.

Chris: And thank you all today for listening and watching. If you enjoyed today's video, you can find many more of them on your YouTube page. Just to go to YouTube and type in InfoSec Institute, check out our collection of tutorials, interviews and past webinars. If you'd rather have us in your ears during your workday, all of our videos are available as audio podcasts. Please visit InfoSecInstitute.com/cyberspeak for the full list of episodes.

If you'd like to qualify for a free pair of headphones with a class signup, podcast listeners can go to InfoSecInstitute.com/podcast to learn more.

And finally, if you'd like to try our free, security IQ package, which includes phishing simulators you can use to fake phish and then educate your colleagues and friends on the ways of security awareness, please visit InfoSecInstitute.com/securityIQ.

Thanks once again to Dan Cornell and thank you all again for watching and listening. We'll speak to you next week.