This week I was able to sit down with Ksenia and talk information security. I first met Ksenia at Angular Summit last year and I’m looking forward to catching some of her talks at UberConf 2016.
Announcer: You’re listening to the “No Fluff Just Stuff podcast,” the JVM conference series with dozens of dates around the country. There’ll be one near you. Check out our tour dates at nofluffjuststuff.com.
Michael Carducci: Hey everybody, this is Michael Carducci, the host of the No Fluff Just Stuff podcast. If you’re a regular listener then you’ve no doubt realized that we cover a wide range of topics on the podcast. We do the same thing at the conferences that we put together around the country and even our destination shows that really start to specialize in one particular area.Coming up in a few weeks is the Angular Summit, where we’re certainly going to be talking about Angular 1.5, Angular 2.0, best practices, making that transition, architecture, things like that.
We’re also going to be talking about a lot of other frameworks, talking about Meteor, React, Aurelia and things like that beyond the technical aspects that are certainly important.
We’re going to be talking about information security and even many of the broader skills that are absolutely necessary for you to succeed as a modern web developer. We’re doing the same thing at UberConf.
UberConf, we cover technology in depth, but we’re also going to be talking about architecture, leadership, soft skills, and all these different things that are not only going to make you better at what you do primarily but are going to make you more effective overall.
Certainly, if you want to learn more about the shows we’ve got coming up on tour, go to nofluffjuststuff.com — and some of our destination events that are coming up this year. The Angular Summit is in a few weeks in mid-May in Chicago, Illinois.
We’ve got UberConf, our flagship event, 10 concurrent tracks all day, several days. It is not for the faint of heart. Check that out atuberconf.com. We’re also busily planning another ArchConf event, the Rich Web experience and the G3 summit. Do check those out, do stay tuned for more information about those.
Now we’re going to talk a little bit about information security with Ksenia. I managed to sit down and catch up with her at ArchConf West a few weeks ago. You will see her at UberConf as well this year.
Michael: I’m here with Ksenia Dmitrieva. We’re at ArchConf West. Ksenia, you’ve been speaking on a number of different topics this week. I know you’ve been talking about security, some architecture stuff…What have you enjoyed most speaking about?
Ksenia Dmitrieva: Mostly my focus is security. I was speaking about threat modeling, which is one of the ways to assess the security poster of the application. It’s very relevant for the architects, because it gives you a high-level overview of your system, and allows you to find the defects that you’re not going to find with pen testing or code review, standard security techniques.I will be speaking also about another technology. It’s an HTML5 technology called Content Security Policy. It basically allows you to monitor what is being loaded onto your web page when your users open your website in real time. If there are any malicious scripts that are being loaded, you will be notified that that happens.
Michael: It seems like information security is only getting harder and harder, despite the fact that our industry is getting better and better.
Ksenia: We write more code, which means there is more opportunity to have more bugs in the code. On one hand, we are making a lot of advances in information security. We have all these new tools and all these new technologies, but if you look at the number of bugs, the number of security defects over the years, the number goes up.You ask yourself, “Are we doing the work right as information security specialists?” The problem is that there is more code, there are more dependencies and the software gets more complex.
Michael: And there’s a greater surface area because these things are now online and there’s all…[crosstalk]
Ksenia: Exactly, this is your fridge or this is your car. All these devices now have software in them, they’re all running Linux or whatever…
Michael: And everyone just goes and adds them to your home WiFi. You’ve got this device now which is on your home WiFi in your internal network that probably isn’t going to get a firmware upgrade, ever. They’re becoming attack vectors, which is really interesting.Part of it falls on us as software engineers. Our definition of success — does the code build? Does it work? Do our tests pass? There’s this whole other dimension around security that is getting overlooked. I feel like certainly there’s some education failures. We’re not looking at our application from that lens.
Ksenia: One is the education failure, where if you take standard computer science courses in the universities, they never talk about information security. If somebody is taking an information security course then yes, maybe, but when you learn how to write Java code, you don’t think about these things. That’s one thing.Even in software development, when you talk about the requirements stage, you have your functional requirements, you have your non-functional requirements. These are the features that application should have, this is how it should operate, these are the performance requirements.
Nobody talks about, “The application shouldn’t be hackable. What if somebody, instead of sending a username, submits some bogus data in this field, what will happen?”
Michael: Little Bobby Tables.
Michael: That’s kind of an implicit thing. This idea that it’s not hackable is implicit to an engineer who feels they did their job right, but that’s so difficult to quantify. Is it hackable? There are so many creative ways to hack an application. That almost seems like an impossible question to answer.
Ksenia: That’s why you need to look at the requirements with an information security analyst where they will quantify them. They’ll say, “You have a login scenario. What can go wrong in the login scenario? You send the password, the password gets stored in the database. How do you store the password?”There will be multiple questions that are coming from just one scenario from the security perspective. The next will be, “You view the features for that user, that personalized profile. Can the user be able to see features of a different user or of an admin?” You have to take apart each functional requirement and look at what can go wrong.
Michael: You’ve reminded me, actually, of early in my career, in probably about 2000, 2001, I was working for a company and they had an intern who was studying computer science and wanted to do some computer science work experience rather than just some general office work experience.She built an application for [inaudible 7:03] department. They brought me in to do a code review. I noticed one of the things…The authentication logic was in the application code itself. There was just a series of if statements. If username equals such-and-such and password equals such-and-such then this. If username equals this and password equals this…
I was trying to be supportive in the way that I was approaching this, because this is really bad. I just said, “What happens if a password gets compromised and we need to change the password?” She says, “No problem, you just contact me and I’ll make a new build with a new password.”
I said, “What happens to the old application?” She said, “I guess you’d have to destroy it, delete it.” I said, “That seems like that might be hard to do. That might be hard to control.” She says, “Yeah.”
Michael: We’re not asking ourselves these questions. Like you said, if you’re looking at things from purely functional requirements then it’s easy to…because that meets all the functions.A lot of organizations aren’t fortunate enough to have an information security analyst. Are we out of luck? What are some things we can do? How do we get better at this?
Ksenia: It’s a question of priorities. It’s your problem, the answer is, but it’s how high of a priority information security is to you.If your priority to just get the software out of the door and just release in the next three months and we have to get it done, that’s your priority, and then it’s not going to be secure. If it gets released and then it gets hacked the next week that’s your problem.
It’s always a business decision. If you want to think, “We’re going to educate our developers so we don’t really need an information security person, as long as the developers know how to code securely, we’re going to spend some money on training…”
Michael: “And we don’t need operations, either, we’ll just train the developers…”
Ksenia: Those are all of the business decisions you’ll be making.
Michael: I don’t know if this is working towards or against the goal, but application frameworks have started more and more building security into them. I do a lot of development on the .NET MVC platform, and that has its own identity provider. It has a lot of security baked into it.One of the things I did that just came up, I’m building a feature in the application where somebody can edit an HTML template and load that up into the database. It put the kibosh on the request, the POST, when I was saving that the first time and said that there was a potentially unsafe.
Michael: Yeah. Some regex somewhere, it said, “This is potentially malicious and it’s going to stop.” I had to go in there and annotate that particular method to not try to filter the content, but elsewhere it’s doing this.On one hand, it’s creating this nice baseline of security. There’s a lot of obvious mistakes that are getting taken care of. I wonder if that’s at the cost of people understanding what they’re doing and having to think about these things themselves, or if there’s this implicit assumption that, “I’m building this, and this is a pretty secure platform, so it’s going to be fine.”
Ksenia: On one hand, when we talk about solutions for information security problems, there are different levels where you can solve it. You can write your own code around that validation of the input that’s coming into your HTML text field, you can use an existing library — that’s easier, you just make a call — or maybe a framework does it for you.It’s better for the developer that the framework does it for you, because then you don’t need to worry about all the security things. It’s all taken care of.
Michael: But should we be worrying about it anyway?
We’re in unlikely position because it’s an open-source framework, we can reach out to the maintainers and say, “You guys actually doing something wrong here,” and that will be fixed hopefully soon enough. This is still the right way to do it. I think the framework have to take care of security.
One of the good examples of that, if you look at the OWASP top 10, the Open Web Application Security top 10 vulnerabilities that come out every two years and they say, “These are the top 10 issues in the most applications,” if you look how the vulnerabilities move up and down, what are the top three, what are the top five…
Cross-site request forgery was in top three for many years, and in the last couple of years, I think right now it’s number eight or seven. You’re thinking, “Did developers actually got smart and they’re not making this problem? They’re not making that mistake?”
Michael: Isn’t it more the browsers and the servers themselves trying to handle that?
Ksenia: It’s actually the frameworks that are adding automatically. If we’re talking about .NET, they have View State, if we’re talking about Express and Node they have the csurf library. All you need to do is call the library, or sometimes .NET just…
Michael: It’s just there.
Ksenia: It’s just there. As long as you configure it correctly, don’t turn it off, it’s just there.
Michael: My concern about that, Microsoft historically has been terrible about information security. If you look back over the years, I remember when Heartbleed became an issue and they said, “It affects all these different web servers but not Microsoft IIS.” I was thinking, “Did I just wake up in bizarro world?”Historically, IE was notorious for vulnerabilities, IIS was notorious for vulnerabilities, Windows was notorious for vulnerabilities. Putting that into perspective and then saying, “I’m going to trust .NET to take care of all my security for me,” might be unwise, but it’s better than nothing.
Ksenia: I think that Microsoft has a very bad rap for that because we don’t have things to compare with Microsoft at that scale. We have Apple, Apple also has problems, but still, it’s not as popular as Microsoft. When everybody’s using Windows and there is a vulnerability, everybody’s going to be talking about it.Ubuntu gets patched all the time. They have issues. [laughs] They are not completely secure. Microsoft gets a bad rap, but they are definitely spending a lot of money on security, they are definitely doing a lot of research…
Michael: They’re doing a lot of things differently now, which is actually quite exciting.
Ksenia: Azure will be the next thing, comparing how secure Azure is and you know, AWS.
Michael: It’s been a really fascinating conversation, but one takeaway is, if I’m in an organization and we don’t have a security analyst and I don’t want to be the person responsible for the next big leak or anything like that, where do you start? It seems like there’s so much information, and some of the exploits are extremely creative.I’m reminded of the story of the Wired journalist who had his Twitter account stolen and in the process his MacBook and his iPhone and his iPad were wiped, losing all of his first year of his baby photos and all these things.
The process that they took over his Twitter account was they called into Amazon to add a card, then they used that card number to identify the account holder, and from that they were able to get the last four digits of their Amazon card and use that to identify themselves on iCloud, and then they used iCloud to reset the Gmail password, and then…
Ksenia: And one you have the Gmail password you own…[crosstalk]
Michael: Yeah, you have the keys to the kingdom — which is a separate thing, by the way. I don’t think we realize how sensitive our email passwords really are. It doesn’t matter how good your keychain is.
Ksenia: If you’re a developer and you don’t want to be responsible for the next hack of your software, this is something to talk about with the management. That’s the decision they have to make. One other interesting thing about information security is that the breaking part, the hacking part, is much more interesting than the fixing part. Maybe something you can do is…That’s sexier, right?
Michael: Yeah, it really is.
Ksenia: Nobody cares about how to develop software securely. Everybody cares about how they hacked the next car or fridge or whatever.
Michael: That’s exciting, yeah.
Ksenia: Maybe if you can actually find a vulnerability in your code, in your own application, and demonstrate it to your management and say, “If somebody tries to do this with our application we are actually in problem. What are you going to do as a manager?”[crosstalk]
Michael: Yeah, as the business owner.
Ksenia: As the business owner.
Michael: It’s your liability, not my liability.
Michael: Although I think that’s going to change, too. The fact that these things do keep happening. How long do you think it will be before software engineers have to carry malpractice insurance?
Ksenia: The whole insurance and cyber-security insurance, I think it’s a bubble. We’ll see in the next few years. A lot of companies are trying to do that, to buy that insurance for, “What if we get hacked?” Evaluating those risks, at this point, I don’t think we have the right tools and understanding of the problem because this world keeps changing.
Michael: Absolutely. I like that suggestion, though, to focus on the interesting aspect, to focus on trying to break it rather than trying to fix it. Trying to fix it preemptively is tedious and it’s very difficult to quantify. “Have I made this secure?” I have no idea. I may or may not have found a vulnerability. That tells us almost nothing about the security of the application.
Ksenia: It’s your [inaudible 18:09] . “We found 25 bugs,” that’s a problem. “We didn’t find any bugs.” Does that mean we are secure, or we just didn’t look for other things? It doesn’t tell you anything.Another way, but this is again from a management perspective, is hiring a consultant who will come and test your application, who will come and do a red-hat assessment trying to break into everything. That’s how you get the budget after the red-teaming exercise…
Michael: “…we have a problem.”
Ksenia: …going to get the budget.
Michael: I really hope that information security becomes a larger part of the conversation. One of the things I like about these conferences is that we are talking about a lot of these things, and a lot of things that aren’t being talked about as much.Sure, all the new technologies, architectures, Docker, containers and all these things are sexy, but information security is really crucial, not only as an architect but even as just a software engineer, knowing how to write good, secure, code.
Thank you for taking the time to join us.
Ksenia: You’re welcome. My pleasure.
Michael: Will you be at Angular?
Ksenia: I hope so.
Michael: And UberConf, maybe?
Michael: All right. We look forward to seeing you again on the road. Thanks again.
Ksenia: Thank you.[background music]
Announcer: At No Fluff Just Stuff, we bring the best technologists to you on a roadshow format. Early bird discounts are available for the 2016 season. Check out the entire show lineup and tour dates at nofluffjuststuff.com.
Michael: I’m your host Michael Carducci, thanks for listening and stay subscribed.