Show 135: Ksenia Dmitrieva-Peguero discusses software security and AngularJS

June 27, 2017

Ksenia Dmitrieva-Peguero is a Principal Consultant within Synopsys’ Software Integrity Group. She is a subject matter expert in a variety of software security practices including static analysis tool design and execution, customization, and deployment. She is also an expert in the areas of penetration testing and threat modeling. Throughout her career as a consultant, Ksenia has established and evolved secure coding guidance and best practices for many different firms, and has delivered numerous software security training sessions. She speaks regularly at events around the world on topics such as HTML5, CSP, and JavaScript. Ksenia holds degrees in Education and Computer Science from Clemson University, and an MS in Computer Science from George Washington University. She lives in Virginia with her husband and newborn daughter.

Listen as Gary and Ksenia discuss software security awareness, AngularJS, security conferences, and more.

 

Listen to Podcast

Transcript

Gary McGraw: This is a Silver Bullet Security Podcast with Gary McGraw. I’m your host, Gary McGraw, vice president of security technology at Synopsys and author of “Software Security.” This podcast is cosponsored by Synopsys and IEEE Security and Privacy Magazine, where a portion of this interview will appear in print. For more, see www.computer.org/security and www.synopsys.com/silverbullet. This the 135th in a series of interviews with security gurus, and I’m super pleased to have today with me Ksenia Dmitrieva-Peguero, which is impossible to pronounce, so tell me how to say that right, Ksenia.

 

Ksenia Dmitrieva: Dmitrieva-Peguero.

 

McGraw: Dmitrieva-Peguero. That’s, oh yeah, that sounds better when you say it. So Ksenia is a principal consultant at Synopsys in the Software Integrity Group. Ksenia has many years of hands-on experience in software security and systems security. She is an expert in many software security practices, including penetration testing; static analysis tool, design, execution, customization, and deployment; and threat modeling. Throughout her career as a consultant, Ksenia has established and evolved secure coding guidance and best practices for many different firms and has delivered numerous software security training sessions. She is passionate about cutting-edge web technologies and probing system security. Ms. Dmitrieva speaks regularly around the world on topics such as HTML5, CSP, and JavaScript. Ksenia has degrees in education and computer science from Clemson and an M.S. in computer science from George Washington University. She lives in Virginia with her husband and a brand-new baby girl. So thanks for joining us today.

 

Dmitrieva: No problem. Thank you for having me.

 

McGraw: Congrats on the birth of Sophia Tamara, 12 days ago. Holy cow!

 

Dmitrieva: Yep.

 

McGraw: Yeah, what’s it like to be a brand-new mom?

 

Dmitrieva: Ah, it’s much harder than being a security consultant, I’ll tell you that.

 

McGraw: It’s sort of a...it’s a never-ending rhythm at this point, from what I recall.

 

Dmitrieva: Yes, there is no deadline on Friday and then you can go for a weekend. It never ends on deadline.

 

McGraw: So you’ve been doing hands-on software security in the real world for many years. How has the field evolved since you started doing consulting about 7 years ago?

 

Dmitrieva: I think 7 years ago, a lot of people didn’t even know what I was talking about or what we as a company were talking about. One example, I remember, for hiring people at Cigital, including myself, we would look for people with just programming experience, and we didn’t care about security experience, and you would kind of learn everything on the job. These days, there are degrees at universities in security, and we expect the students to know what security is and have some experience. And then when you talk to the clients, they also know what software security is. They’ve definitely heard of penetration testing and static analysis. So their awareness is definitely much higher.

 

McGraw: I guess that makes it easier to get straight to work, maybe. Do you think we’ve made progress as a field in those 7 years, beyond just awareness?

 

Dmitrieva: Yeah, well, at the end of it, there’s awareness. I mean, there are still bugs; there are still problems. But I think we are making progress. The field has definitely grown. There is more demand, so there is more understanding of what kind of problems we are trying to solve, right? What is the difference between software security versus all the other things that have to do with IT and security in the company.

 

McGraw: Right.

 

Dmitrieva: In terms of quality, that’s...I don’t know.

 

McGraw: Maybe more awareness and more people wanting it, but the quality remained constant?

 

Dmitrieva: Well, as you say, there is more software, there are more bugs, and because there are more things to be attacked now—we have Internet of Things, and there is software in mobile devices and software everywhere, in cars and everywhere else—so it may look like there are more security issues. But it’s probably also just us being more aware, us as a society being more aware of that, and that’s getting more publicity on the news, that it may look more scary than 7 years ago. So it’s hard to say if we’ve made any qualitative progress in that.

 

McGraw: OK, well, let’s go after it a different way. If you were able to fix any practice area in software security, which one do you think requires the most attention these days? Like what’s the farthest behind or where do we have the most work to do?

 

Dmitrieva: Probably threat modeling, I would say, and architecture review. So that’s farthest behind because that’s the more complicated one and people have very different descriptions of what it is and very different understanding of what it is. Everybody has their own version of threat modeling and risk analysis. So yeah, I think that’s the one lagging behind.

 

McGraw: OK. And it may be partly because it’s harder to automate. We can build a computer program to go through our code and look for bugs, but you can’t really build a similar system to go through a design and look for flaws.

 

Dmitrieva: Yeah, absolutely. There’s definitely less tooling, and the reason why there is less tooling is because it’s much more involved. So maybe with the development of artificial intelligence, we will be better in developing some sort of automation in understanding the design and understanding the problems of design.

 

McGraw: Yeah. I’m not holding my breath for that one. Having worked on AI 25 years ago, I think we’re just barely making progress in that field too. But who knows? I think you’re right. I agree with you about the architecture being behind, figuring out how to do analysis that way.

 

Let’s talk about frameworks a little bit because I know you’ve been working in web-based systems for a while. These frameworks like JavaScript have been popping up all over the place. I’m thinking about Angular and Node and Express and things like that. So in your view, with all those things, do all frameworks have the same security posture?

 

Dmitrieva: Definitely not. All frameworks have the problem or the issue of building security into the framework and how much each framework developer or framework maintainer wants to make security part of the framework. Unfortunately, these days, that’s not the highest priority for a framework. We’re still going for more features, for speed, performance—that’s definitely there. But security—only very, very few frameworks think about security, like Angular and Spring, you know, Java frameworks. But most of them don’t bother about it.

 

And then what happens is developers are left to solve all the security problems themselves, even when they’re using the framework. And every developer is solving the same problem. Everybody needs authentication. Everybody needs some sort of validation. And instead of having these features built on the framework, they have to reinvent the wheel every single time.

 

McGraw: And they do the wrong thing when they roll their own. So you think that the developers of the frameworks have more responsibility to do some stuff that the developers using the frameworks can use?

 

Dmitrieva: I think so. That would be the perfect way to fix more issues in the code. And it, on one hand, should be the responsibility of the framework maintainers and developers. On the other hand, it should be a demand from the developers that when they choose the framework, they should look into, “Oh, you know, what’s the security posture of this framework?” I don’t see any questions on forums like Stack Overflow, saying, “Hey, which framework is more secure?” Right? Usually you see the question, “Hey, which framework has more of these visual components, or is faster, or has better connection with the database?”

 

McGraw: Right. So still it’s a property of a system that’s just not that high on the priority list, and the developers building the frameworks don’t really get to it. And then the developers who are using the frameworks can screw everything up, from a security perspective. So do they? Do they...

 

Dmitrieva: Yeah, they do.

 

McGraw: What do they do, like...

 

Dmitrieva: So, if we take validation, some sort of validation, right? There are different things they can do. They can either write their own routine to validate address, email address, etc., and that will most likely be some code copied from Stack Overflow, or some other GitHub repository that we don’t know how good the quality is.

 

Sometimes there are third-party libraries that they can use, and depending on the developer, or depending on the framework, or depending on how well the library is integrated with the framework, they may be using that third-party library, which oftentimes is a better solution a little bit more validated, updated, and more secure. But yeah, in both cases they have opportunities to screw things up, because even if they use a third-party library or a plugin, it usually requires some configuration. Like we’ve seen these examples in Angular where plugins come with pretty good default security settings, but they don’t satisfy some features that developers need, so they turn off security settings, they change them, and basically the plugin doesn’t do the job that it’s supposed to do.

 

McGraw: Right, right. So you’ve spent a bunch of time digging into Angular and thinking about how to automate aspects of security analysis. So what have you learned about Angular, and what have you done to get that into automation?

 

Dmitrieva: Angular is interesting. On one hand, it still...it’s client-side code, right? And as you know, we don’t trust anything that runs on the client. A lot of things can be bypassed. But then, on the other hand, the way that templating is done in Angular actually provides a pretty good protection, for example, from cross-site scripting. And in terms of automatically finding the problems, that is still a big question. Like there are still not really good tools that can do that. It’s possible to find some data pool and cross-site scripting issues, but with the issues that have to do with the configuration of the framework for plugins, the problem is that they get updated so often, right?

 

McGraw: I see. So it’s sort of a...it’s a moving target.

 

Dmitrieva: Yeah. We’re always chasing that, and there are updates every couple of months and a new version of Angular is coming out. And not everything changes, but still there may be enough changes that our automated tools don’t find things anymore.

 

McGraw: So have you guys building those automated tools talked to the developers that are building Angular about this problem?

 

Dmitrieva: No. We have not communicated directly to them.

 

McGraw: But are they aware of what you’re doing? I mean, I’m trying to figure out what framework developers think about, beyond security features and input monitoring. Like there have to be and you said that’s even hard to keep up with, so I’m trying to figure out how that all washes out.

 

Dmitrieva: Well, from the Angular developers’ standpoint, they are, from my understanding, as I said, we haven’t communicated directly to them, but when they introduce new features, they oftentimes say, “Hey, this is a breaking build, and we kind of don’t care about the older versions. We don’t have the requirements or the desire to support whatever was built before. So we’re just going to go ahead and start a new version.”

 

McGraw: So you have to figure out what they did and then figure out how to adjust whatever you built to work again, every time.

 

Dmitrieva: Yeah, yeah. On one hand, yes, but then, on the other hand, the developers who started using, say, Angular 1.6, and now Angular 2.0 is out, and now Angular 3.0 is coming out as well. Sometimes the developer would just stick with the version because if they want to use the new version of Angular—Angular 2.0, for example—they have to rewrite their whole application. And not every company will do that. So on one hand, if developers are still using the older 1.6 version, then the tool that was built for 1.6 will still work. But they won’t work for a new application.

 

McGraw: Right, right. Yeah. This is just too complicated! So what are the biggest open problems? Do you think that version controlling and kind of keeping everything somewhat similar in terms of its security posture is the biggest open problem?

 

Dmitrieva: I think one of the problems is, yes, keeping up to date, basically, to all the versions and to all the new features and plugins. That’s one issue. And then the second problem is keeping up to date to different frameworks, because last year Angular was number one. It was so popular. I think it’s probably fading out these days and React is stepping in. And now we need to build all these automation tools for React, and then 6 months later, it’s going to be something else.

 

McGraw: Right. So there’s kind of a fashion or a style with these frameworks, like which one you choose. It’s like what kind of clothes you wear.

 

We’ll be right back after this message.

 

If you like what you’re hearing on Silver Bullet, make sure to check out my other projects on garymcgraw.com. There, you can find writings, videos, and even original music.

 

McGraw: Here’s a trick question. Are you ready for a trick question? What’s more important, code review or architectural risk analysis?

 

Dmitrieva: I would say it depends on the application. If the application is your standard web app that has a database, a back end, and a front end, then you may not gain as much in doing architecture risk analysis. And you may just start with a code review and get kind of more bang for the buck.

 

McGraw: Yeah. That makes sense because the pattern is so normal, or you’ve seen it so many times, people have mostly got that straight.

 

Dmitrieva: Yeah. It’s a known pattern. It’s known architecture. But if it’s something unusual, right? If it’s some software in a car or some very complicated thing, then yes, I think that we should start with the architecture analysis.

 

McGraw: OK, so how do you think that code review and ARA are related to each other?

 

Dmitrieva: Well, so, for example, if you’re viewing a complex system, right? You will start with an ARA, and then that will help you identify what are the potential issues. And then to find if these potential issues actually exist in this system, you would do a code review, right? You would look at something and say, “Hey, this system is talking to this third-party back end that has its own protocol. So how about we review the code of this third-party back end and this protocol and how the communication happens?” And in doing code review on that, we may find some issues.

 

McGraw: So I’m thinking of how to tie in this framework stuff and code review and ARA all together and wondering whether if you made certain changes to the design of a framework, you could maybe eradicate entire classes of bugs all at once because you made a design change, made it impossible for developers who use the frameworks to do certain things because of a design decision. Do you think that’s a possibility?

 

Dmitrieva: Probably, especially if the framework covers big security controls such as authentication and authorization, right? If authorization, for example, has been built into the framework, then all you need to do—and you know that the way developers are, writing code, they are following the framework standards, the framework requirements—then to review the authorization, you may just need to check a couple configuration files. And you don’t need to do a whole code review, trying to understand what are the roles and what are the permissions and how this is all interrelated.

 

McGraw: I was thinking about cross-site scripting, for example, requires a certain base design in order to be a problematic bug in some sense, and you could maybe get rid of that by changing the design, making it so that developers can’t do the calls the way they kind of want to. It makes it a little bit harder for them to get their work done, but it also makes it impossible to do cross-site scripting. I don’t know. It’s just an idea.

 

Dmitrieva: Yeah, that’s definitely possible. Angular is a great example of that. Angular has the built-in output encoding for any data that reaches a template, and so the change in the framework that they did is the separation of the template and then the data that comes from the server. So whatever comes from the server and becomes part of the template gets automatically encoded using their strict contextual encoding. And then, the only way for a developer to actually have cross-site scripting or have unencoded data that’s coming from the server in the page is to intentionally say, “Hey, I trust this code,” and basically turn off your encoding and send it the way it is. So then finding this issue is very easy; you just search for a couple of function calls that say, “Hey, trust this HTML,” and you’re done.

 

McGraw: Right. So that’s a way that making a change, an architectural change, to the framework can help get code review to be easier. So maybe we are making progress.

 

Dmitrieva: Well, yeah. Code review usually, and coding and having fewer issues. I was actually just recently looking at three groups of applications. One is built with a template engine, EJS, an open JavaScript template engine, one built with Jade or Pug template engine, and one group of applications built with Angular, and they’re all open source applications on GitHub. And the number of cross-site scripting—the real cross-site scripting issues that are not false positives—in the Angular applications are much, much lower. They’re, like...7% of the apps were vulnerable compared to 30%, 40% of the apps for EJS and Jade.

 

McGraw: Yes, that’s really interesting. So maybe we can make progress.

 

Dmitrieva: We sure can.

 

McGraw: All right.

 

You’ve experienced and lived in different cultures all over the world, and I’m wondering, do diverse cultures, sociological cultures, approach computer security differently, or is it the same, or is it so new? I’m trying to...is there an angle there?

 

Dmitrieva: I don’t know. I haven’t thought about it. And I cannot come up with a good example. I don’t think there is any difference between culture and computer security, at least in the societies and the countries that I’ve lived in and worked. I’m from Russia originally. I worked in Europe. I worked in the U.S. At least in these countries, I didn’t see any differences in how people understand or relate to computer security. Maybe in other cultures, it’s different.

 

McGraw: Well, I mean, there are certainly different aspects of those cultures not related to computer security, but I just wondered if it leaked into that at all. Maybe it’s because computer security is so relatively new that everybody is grappling with it in the same way?

 

Dmitrieva: Yeah, maybe it’s because it’s relatively new, and maybe because it’s so technical. I think if you look at some other industries or some other areas of knowledge, like education or psychology or maybe medicine, there may be cultural differences. But if you look at technical stuff, math and computers, I think it’s pretty straightforward in any culture.

 

McGraw: Fair enough, because math is math, yep.

 

Dmitrieva: Yep.

 

McGraw: You give a lot of talks all over the place, and I’m interested to know what your favorite conference to attend is, or maybe to give a talk in.

 

Dmitrieva: Oh, that’s a tough one. I think one of my favorites, so far, has been AppSec in Europe. AppSec EU was really, really great. And maybe that’s because...there were a couple of reasons. There was a great concentration of web technology experts, so that’s just my playfield and play area where all the experts are, and I just enjoy communicating with them and interacting with them and listening to all these amazingly smart people. But also in Europe, I think people are very relaxed and very friendly and less commercialized than in the U.S.

 

McGraw: Yeah. So it’s a little bit more, I don’t know, like a club or something?

 

Dmitrieva: It’s more like a club. It’s more like exchange of ideas and not exchange of business cards and promotional materials.

 

McGraw: Right, right, right. That’s a good answer. Another question. So as a hard-core technologist and a woman, what is your view of sexism in the field? Do you think it’s harder to gain respect as a technologist if you’re a woman?

 

Dmitrieva: Yes. Unfortunately, it’s there. It is harder to gain respect, for sure. And I think it’s harder to gain respect on a medium level. So I think when you are at a higher level,—like, for example, if you are speaking at a big conference, of course there are right now requirements from society that, “Oh, we should be equally represented,” and so some conferences maybe even favor more women and select, women versus men to talk, so it’s kind of reverse sexism. But at the medium level, working with the clients and establishing your position and trust with a client as a woman may be harder, definitely. I’ve experienced that.

 

McGraw: Yeah. No, that...You have to sort of prove yourself a little bit more, somehow?

 

Dmitrieva: Yes.

 

McGraw: Does that seem right? Yeah.

 

Dmitrieva: And I’ve been in situations where I would be working with a male colleague, both of us with a client, and the client would just interact more with my male colleague and not me.

 

McGraw: Even though you probably knew more than the other guy?

 

Dmitrieva: Sometimes, yes.

 

McGraw: Oh, come on. Always.

 

Dmitrieva: Yep.

 

McGraw: All right. Last question, and a total flyer. So one of the coolest things you do is competitive ballroom dancing, and boy, are you guys fun to watch when you do that. So when did you start dancing, and did you ever think about going pro?

 

Dmitrieva: Oof! When did I start dancing? That was a long time ago. Let’s see, 2007. Gosh, 10 years ago. Yes. Going pro? No, I’ve never thought about that, because, see, I started in Russia, and then most of the people in Russia start ballroom dancing when they’re 6, 7 years old. I started much...I was not 6 years old when I started. So for me it was...and what I was doing in Russia is called a “hobby class.” So it’s only, if you’re starting after college, that’s only treated as a hobby. Like there is no way you can become a pro.

 

McGraw: Right, right. You can’t go pro. Well, you might be able to if you just made your life only about that.

 

Dmitrieva: Yes. In the U.S., you can, and yes, you have to just make your life out of it. But yeah, for me it’s just a hobby, which I still spend a lot of time on and get a lot of pleasure out of it. But it’s a hobby.

 

McGraw: Well, that’s cool. Well, it’s fun to watch. Hopefully, we’ll figure out a link that we can put on the podcast so people can see you doing it.

 

Dmitrieva: Oh, sure. Yeah. We can do that.

 

McGraw: Thanks for your time today. It’s been really interesting.

 

Dmitrieva: Thank you very much. It was a pleasure talking to you.

 

McGraw: This has been a Silver Bullet Security Podcast with Gary McGraw. Silver Bullet is cosponsored by Synopsys and IEEE Security and Privacy Magazine and syndicated by Search Security. The January/February issue of IEEE S&P Magazine includes our interview with Marie Moe, a Norwegian researcher who hacks her own pacemaker. So check that out. Show links, notes, and an online discussion can be found on the Silver Bullet web page at www.synopsys.com/silverbullet. This is Gary McGraw.

 


Ksenia Dmitrieva-Peguero