ARCast.net - Defending the Application

Announcer: It's Tuesday, May 1, 2007 and you're listening to ARCast.

Ron Jacobs: Hey, welcome back to ARCast. This is your host Ron Jacobs and happy May Day to you, to those people for whom the first of May is a big deal. Which I guess it is in some parts of the world. They have big parties, parades, and celebrations. You know, it's always kind of an interesting time of the year; springtime and the allergies starting to act up.


You know, but I love the warm weather and the spring that's happening; it kind of reminds me of security. What? No, I'm serious, I was just thinking about security and when I was in Israel in January, I had a nice chat with Alik Levin, who is one of the MCS guys in Israel there. He kind of works on security. And a lot of people think, "Oh, security is a problem for the platform people, it's a problem for the network people." But really, there's a level of security that has to be applied at the application layer. So let's welcome Alik Levin.

Ron: Welcome back to ARCast, I'm your host Ron Jacobs and today, I'm here in TelAviv, Israel, where I'm joined by Alik Levin. And welcome, Alik, to ARCast.

Alik Levin: Thank you very much. It's a pleasure.

Ron: Tell me a little bit about yourself. What do you do here in Israel?

Alik: Well, I joined Microsoft two years ago, Microsoft Consulting Services with MCS and I help my customers to build, deploy, and maintain their line of business application in a more secure way.

Ron: Ah, OK.

Alik: I'm a security guy.

Ron: Now, security guys. You and I were talking earlier about one of our colleagues, J.D. Meyer, who is on the Patterns and Practices team, and is perhaps one of the most intense security people I have ever known. Isn't he?

Alik: Absolutely. He's very sharp; he is my guiding light in security. And when I say security, I'm talking about application security.

Ron: Yeah.

Alik: So it's all about application security, it's not about firewalls, SSL's, VPN's, Wale, infrastructure technologies, and other products. But it's focused around application building, application based on our technologies, mostly around other framework.

Ron: Now I mentioned J.D. because he's on the Patterns and Practices team, one of the driving forces behind things like improving web application security, threats and attacks and so forth. So great, we have loads of material here that people should keep in mind.


But you brought up an important point that I want to talk about. About application security; I've heard a lot of people say, "Hey, it's no problem, we have a firewall; we're OK." What's wrong with that kind of thinking?

Alik: Well, when you have a firewall between your users and your application, or your application server and the database, again, the firewall allows some traffic to go through there. Specifically, when you're talking about web applications, you must allow some port to communicate from the browser to the web server. And it's usually port 443, 444.

Ron: Yeah.

Alik: Doesn't matter. So you need to allow some port to communicate. Do you know what goes inside the application through that port? Do you know how the application handles that data on behalf of the user on the server? Do you know what privileges that application has on the server? Do you know what resources are accessed by that application?


No, you don't. Unless you plan for security, unless you architect for security, architect the application, you design with security in mind, you code with security in mind, and you deploy with security in mind. Because if you code it... I bet you've heard about SQL injections?

Ron: Oh, sure.

Alik: Imagine that you vendor...

Ron: Well, actually, for the sake of those who are listening and don't know what a SQL injection is, tell me briefly what it is.

Alik: Well, as we already mentioned, there is data that flows from the end user through that SSL port to the application and that data is built into SQL statements, that application runs in the database.


So it's up to applications to build this statement safe. Because if not, the bad guy might supply such input so that when the application builds that statement, it can incorporate that statement and these states might be very harmful. Like getting back sensitive information or even totally controlling your server.

Ron: You know, it's funny that you mention this because a lot of people are going, "Oh, come on, everybody know that about SQL injections." But yet, I was doing some research on security yesterday. Just yesterday, I looked at securityfocus.com, which has the bug track mailing list, and every day people report vulnerabilities and products that they find.


And just yesterday, there were two products with SQL injection vulnerabilities that were reported. So this is happening every day in people's code that they're writing because...

Alik: Tell me why.

Ron: People get... I don't know, they're careless about it maybe, they just don't know?

Alik: No, no, they do care. They do care.

Ron: Yeah? OK.

Alik: There are too many hands and the security had too many people and too many projects. With Microsoft, we do have SDL and security development life cycle and the product that utilizes this is a SQL server and since it's launch, we didn't have any security advisory.

Ron: Ah, nice. So tell me a little bit about this, though. Because a lot of people... I agree with you, people are not careless. I mean, it's not like people go, "Who cares if they break into our system?" They do care, but maybe they just don't know what to do or how to do it. So what do you do when you're helping to educate customers about SDL?

Alik: Well, when you talk about customers, I have a whole spectrum of customers' hats. I call it hats, or roles. I have a seasoned security officer that does care about the overall poster of the organization, so when the application is installed in his enterprise, he doesn't want to hear about SQL injections. He wants to hear about risks that the application brings in.


I have customers that are product managers. They are concerned about being on time, being on a budget, and about features. So if features, like security, is not on a schedule in the program, they don't care about it.


Then I have developers that care about security if the project manager demands it. Now, the developer needs to know how to do it, and J.D.'s stuff comes in with a detailed how-to of how to write, for example, SQL queries that counter that SQL injection.


And then I have IT folks that take that application and install it. Here is how the process goes: they get the application, run next, next, next, install, try to access a default page, access denied, insufficient privileges, access denied. And the manager is going to come into the room in two minutes and I have to show that application working! OK, full control! Everybody, full control! Oh, it works!

Ron: [laughs]

Alik: Once it works, don't touch it.

Ron: Yes. Yeah.

Alik: So even though the whole process until the deployment included security actions, that single process of deploying the application in an unsecured way just put a big X on that work.

Ron: Yeah. I like what you are saying because it is really important that from the very beginning while we are laying out the requirements, the features of the application, security is at the top of the list all the way through. We can't say, "Oh, we'll add the security at the end," or something like that. You will never get to it.

Alik: No.

Ron: OK. All right. Now, we have seen a lot of people making mistakes over the years with security. SQL injection vulnerabilities are just one of these. Tell me about some of the other kind of mistakes that you see people making.

Alik: Excellent. Yeah, SQL injection is kind of a design encoding bug. It is a security vulnerability/security bug that can be exploited by an attacker.


So let's take for a moment that you have built an application and you told Alik, "Please go ahead and do security inspection." And I have ran each and every tool on it and I have spent 40-80 hours to inspect it manually. I didn't find anything wrong. Thank you very much. You have built a most resistant application from the code perspective--no cross-site scripting, no SQL injection, nothing.

Ron: Yeah!

Alik: Now let's talk about architecture. Do you understand something in architecture?

Ron: [laughing] I hope so.

Alik: Have you been in that business?

Ron: [laughs]

Alik: So let's talk about architecture. I see that you have built a WinForms application that talks to Web Services. Excellent. This is today's trend. So let's see how you architect the authentication mechanism. Oh, I see that you actually authenticate users using a client WinForms application. Then for each Web Service request you pass the user identifier as a clear text as a parameter for the Web Service.


Well, this is a really, really, really big issue from the architectural perspective. You didn't architect your authentication and identity flow mechanism right. Because if you did so... I can easily capture that identifier and spoof end-user identity. Even though there is no SQL injections I can spoof an end-user's identity and work on his behalf. So this is a security bug, an architecture security bug.


Another one--deployment. [sarcastically] Isn't it great that a dot net framework allows Xcopy deployment?

Ron: Oh, sure. Love that. [laughs]

Alik: I think this is just great. Now, check this out: Developers develop the applications.

Ron: Yeah.

Alik: And probably a manager came in and he is happy with the features. So let's deploy it--Xcopy, with all the emails, with all the documents, with all the copy-off, default. aspx.cs. So from a deployment perspective, the application was deployed very insecure.


Imagine for a moment that you have been using ASP.NET url authorization. This is a built-in feature with ASP.net that allows configurability in the Web.config shell framework. This page can be accessed by that user, and that one by another.


Now, imagine that I allow Admin.aspx for the Admin users. But there is another file that's called "Copy of Admin.aspx.cs."

Ron: Oh.

Alik: So that URL authorization string will not catch it if I type into the address bar that name.

Ron: Uh-huh. OK.

Alik: Once I type that, I get that page with a UI for the administrator. So from a deployment perspective, it was vulnerable.

Ron: Mm-hmm.

Alik: I didn't find any SQL injections, cross-site scripting, and anything else, from the code perspective.

Ron: Now, I'm curious about, it seems like you ought to have some kind of process in place to know that the deployment is secure. I mean, it's one thing to say, "Well, we've got to do this securely." But how could you know that the deployment is secure? What do you do to check that?

Alik: Excellent. Excellent. JD to the rescue.

Ron: Mm-hmm.

Alik: So JD Meier, from the patterns and practices--he led, I think, from 2003 or 2002, since Trustworthy Computing was launched--he created tons of how-to materials. This is not MSDN articles. This is recites. This is practical how-tos. And for each step, there is a practical how-to.


For example, there is deployment how-tos: how you deploy applications, how you check that the web server is secured, how the database server is secured, how the ASP.net application is deployed in a secure way--without debugging through, without any insecure configuration. And there are many, many more.


The best part is that it's published in checklist format.

Ron: Ah, yeah.

Alik: So we just go to the web page on the MSDN.com/securityengineering.

Ron: Mm-hmm.

Alik: You go to the deployment index, you download the page that is the deployment checklist--and this is in format of checklist.

Ron: Uh-huh.

Alik: Just print--check, check, uncheck, check, check, check, check. Here's your security poster.


Ron. Yeah, yeah. You know, when you think about it, like I was noticing as I was getting ready to come on the plane here, I happened to be sitting in the very first row, and I could see the door of the cockpit is open. I'm watching the pilot and the co-pilot in the minutes before we take off.

Alik: [breathes deeply] Pay me no mind.

Ron: [laughs] And you know what they were doing? A checklist! They were going, "Well, OK, we've got this, check; got this, check." And so they were checking everything about the aircraft. Why? Because it's not only my life on the line, but theirs as well. If they miss something, we all die, right? So they're going to take very, very special care to make sure that everything is right.


And a checklist is just the only way that you're going to be sure that you don't miss anything about this when you're going into production.


Now, the other thing I thought was interesting, I was reading a recent "MSDN Magazine," I think it was from November--there was a whole issue that was focused around security.

Alik: Yes.

Ron: And in there, they were talking about--one of the key things, I think, was an article by Michael Howard, who's one of our big security guys. He was talking about staying up-to-date on the latest things, because there's always people coming up with new ideas, new ways to trick you or bypass your security and so forth.


Now, I had heard of SQL injection, but he talked about one in that article I hadn't heard of before, which was called "SQL truncation," which is a really interesting one. And the idea was that, if you had a buffer of a certain length, if you know that the system is using a function that will--there's a function in SQL called "replace" which will replace one character with another, or quotes, and so forth. You can actually get it to replace, if you pass a number of quotes in a string, you can get it to replace it with so many it would push the identifiers off the end of that string.

Alik: Yes.

Ron: Then you would end up with very much the same kind of problem as SQL injection. But I thought, "Well that is an interesting example of something I wouldn't have known to look for."

Alik: What else don't I know?

Ron: [laughs] Exactly. I mean there are so many things that you don't know that the attackers are constantly sharing information with each other, posting messages about things they found that were... So you have to stay informed on this.

Alik: Well, this is an excellent point that you started to talk about. My attitude, my approach for that one, when I talk to developers I am talking to them from that perspective. My goal is, first of all, you dot net developers, you can teach me how to write dot net framework applications, really. And the last thing that I want you to know about is hacking stuff, about how to inject and how to cross-site and how to do 80+ attacks.


For example Owasp.org, which is a kind of authority with open web application development, it collects many web application security related stuff. It talks about 80+ attacks that can be launched against web applications.


So the last that I want is to go to the developer that is concerned about features to provide-- learn all these attacks. I am telling him, "You know dot net framework. I know you have built applications. All I want to do is to turn a bit your knowledge with a focus on security. Keep doing what you are doing. But when you do data access with a system data namespace, use stored procedures and parameterized queries. When you print out the output to the web pages use that namespace and that class to encode..."

Ron: HTML encoded?

Alik: HTML encoded, right.

Ron: Yeah.

Alik: Forget that it counters XSS and anything; just this is a good behavior. Apply good behavior. Stay on top of 10 principles, 20 principles; you don't have to learn all these attacks. In the security area it is called "Blacklist." If you try to counter each and every bad thing...

Ron: You will never get it.

Alik: That's right. But if you are a good citizen you don't cross the street on the red light. You have good behaviors. Keep on with those behaviors and you pretty much are getting there. You are raising the bar.

Ron: Well, I think there are... To know these principles though, that is the... Understanding some of these attacks anyway helps you to understand the principles.


Most people don't think about what a bad guy is going to do to you.


Like I would have never thought that when you are writing your SQL procedure and you are declaring a buffer that is going to hold some kind of identifier and you think, "Well, how big should this buffer be?" You think, "Well, it will never be larger than this." So you come you with, I don't know, 40 characters or something, "Oh, that should be plenty."


Then you don't think about what an attacker is going to do and try to use the SQL truncation, for example, and try to give you something that is longer than what your buffer is going to hold.


You know, we have to develop a little bit of a paranoid mindset and think about, "What could somebody who wants to attack this do to my site, and what can I do to prevent it?"

Alik: Let me disagree with you.

Ron: OK.

Alik: Let security guys be paranoid. Let JD be paranoid, let me be paranoid, let Michael Howard be paranoid...

Ron: Yeah.

Alik: Let people do what they ought to do, like developers need to develop applications. When I come into a project, I'm telling you up front, the last thing that I want to turn this project into is a security project.

Ron: OK.

Alik: Let's try to see your current process and hats and roles and assign security-related activities to that role, that hat. In that manner, we achieve a cost-effective approach, because I don't see lots of budgets allocated for security. I don't see it, despite demand for security from the customers.

Ron: Yeah.

Alik: So we need to find some balance between cost and investment that we can invest into it and the security features we need to provide. For example, the latest JD's achievement was to refactor all this stuff that was published on MSDN, to refactor it into very chunky rules and put it into Guidance Explorer. Did you hear that one?

Ron: Oh yes. Yeah. Guidance Explorer is terrific.

Alik: Terrific, terrific. You download from the Internet, and you go, "I want to know about the principles." Then you click the principles node, and it tells about good behavior principles for auditing, for authenticating, authorization, consecration management, and so on and so on. So it doesn't try to teach you how they will hack you.

Ron: Mm-hmm.

Alik: From the marketing perspective, from my job security, this is my marketing story.

Ron: Right.

Alik: I tell people how bad it can be, but in the end, I want to tell them, "Here's the knowledge. There's the best practices. Apply it." Because I noticed that if you come to people up-front, "Here are the best practices..."

Ron: Yeah.

Alik: They just don't do it.

Ron: It's funny when you mention that, because one of the checklists that JD and his team put together was a checklist for sensitive data. So if you've got credit card numbers in the database, let's say, or other personal information that identity thieves would like to have, we have a checklist for what you ought to do.


It's been a year and a half, I think, since I first saw this checklist, and I've been watching the reports in the press that come out repeatedly about, "This company had this thing hacked," or, "A laptop was stolen with all this information." And in every case, if those people had followed our advice--what this checklist said--it would've been no problem. It would've been OK.

Alik: I agree. I agree. Funny you're reminded of this, because I manage my own blog, which I write in English...

Ron: Mm-hmm.

Alik: But it's hosted on our local Israeli website, blogs.microsoft.co.il. So you might notice a tag which is totally hacked...

Ron: Yeah.

Alik: This is all my marketing story, in trying to attract people by hacking terms. But actually, my blog is not teaching people how to hack, but to get in and see how best practices should be.


So I'm always on those stories, that a retail chain was hacked and a Scandinavian bank was hacked, and then I'm trying to apply those JD's checklists that they should have been looking at...

Ron: Yeah.

Alik: Thus avoiding that situation.

Ron: Oh yeah. Well when you look at how easy it is now to do encryption in the database, why would anyone want to store credit card numbers in a database unencrypted, when it's easy to do it. It's totally possible, but you're so exposed when you do that.

Alik: Well, from the development perspective, from the architecture and maintenance perspective, this is not that easy. So you need to take into account how you store the encryption keys, and if you use key-less algorithms like DBPI, which is used AFS technology, so you need to be aware of the farm issues, and the recovering agent.

Ron: Yeah.

Alik: So it takes us back to, OK, OK, you've bought my story, you want to do it, but you need to think upfront in the architecture and planning stage, so that when the data... Let's say it's not compromised in the database, but the administrator was fired and his account was locked, and nobody knows how to unlock that data in the database, the business collapsed.

Ron: Oh yeah.

Alik: So what's the use of security if it causes denial of service of the whole business?

Ron: Sure, sure. Well, I think that you're right, in that there are new policies and procedures that you'll have to learn and get used to and understand. But from what I've been reading, as a result of this retail chain in the U.S. that system was hacked recently, T.J. Maxx it was called, yeah.


There were several banks that had to re-issue thousands of credit cards because of this hack. Now the banks are getting very angry about this and threatening to sue the companies who have their sites, because it costs them a lot of money to have to re-issue all these cards.

Alik: Absolutely, it's all about money.

Ron: Sure, and they have a right to be angry, because it wasn't their fault that these guys were storing these numbers in the database unencrypted, so that someone could come along and gather them up.


So I think ultimately people are going to have illegal exposure if they are storing this kind of data and not taking appropriate measures. Hopefully this will cause people to think a little bit harder about what they're storing, or really even if they should be storing it at all.


Because the best advice when it comes to storing sensitive data is to don't, don't store it if you don't have to.

Alik: Absolutely, this is one of the rules and guidelines from JD. One of my personal stories, I've approached by one bank representative, and he offered me a new credit card with very attractive conditions, very attractive. So I said, "Of course, I do want it." "So fill in this form." And I think they took this card from the CIA agency or something like this, they wanted my wife's maiden name to fill in, I told them, "I'm not going to do it" So I gave up for the credit card conditions, you see how paranoid I am?

Ron: Oh sure.

Alik: I don't want this data to be stored centrally, can you tell me do you have STL...

Ron: [laughter]

Alik: Say what?

Ron: Well, you know I saw this actually on the medical, this happens a lot. Like every doctor I go to visit they want me to fill out a form, with not only medical information, but financial information about whose going to pay for this, and in the U.S. we have social security numbers which are often used for identity theft, so they wanted that number and all these kinds of things right.


So they are always wanting this number, and lately I've started saying, "I'm not giving you that number" And they say, "Can you fill in that number?" I said, "No, I'm not going to do it" Because I saw just last night on television about.


[Someone in background talking in foreign language]

Ron: [laughter] OK, I saw just last night on television about four women who were caught using stolen credit card numbers, and video surveillance at the store caught them because they were trying to run these numbers through a cashier, they were being rejected, the credit card's had been flagged as stolen.


And when they tracked down how they got these numbers, all of them got the numbers from the computer system at the hospital they worked at, and they had access to this information from the building system. So they were just writing it down at work, and then they would go out in the evenings and try to use it.

Alik: It's a never-ending story; my approach to this is just to raise the bar, when I step into some project... I had a couple of really big projects with two major verticals here, and when I came into executive board, talking to CXO level, I'm telling them upfront that, "I'm not promising you that I'm going to help you build a bulletproof unbreakable system, no one can do it. What I'm promising you is that I can significantly raise the bar so that the attacker would need a significant amount of resources, money, and time to break your system. But that time would allow you to constantly improve yourself, and constantly improve the bar. No one can build an unbreakable system"


So first direction was like, "Can't be, I give you money, and you're not going to build an unbreakable system?" This is it; it's about resources that an attacker will need to break your system. Do you manage critical assets, do you have anything that might be critical for the attacker.


So once the cost of the asset is equal to the cost of the amount of resources that an attacker needs to invest, it's not worth it, that's it. What we are offering JD Stuff in MCS is cost-effective approaches that can get you up and running with that processes and good behaviors for architecture design, development, deployment and maintenance.

Ron: Well, well thank you so much. So the MSDN Security Guidance is where again?

Alik: MSDN.com/securityengineering.

Ron: OK, so we want to make sure that people go and take a look at that, take advantage of this great resource, because it's really well worth it.


Thanks so much for joining me today.

Alik: Thank you very much.

Ron: Alik Levin with some security information, and you can't have too much of this, it's something that you have to come back and visit over and over again. Sometimes people ask me, "Well, I don't intend to be a security specialist. I mean, how much of this do I need to know?" And the answer is, "Enough, you need to know enough." "Well what is that?"


I'm not exactly sure, but look, if you're not thinking about it on a regular basis and kind of staying in the loop of the security best-practices every now and then, I don't know, maybe take one day a month and go read some security guidance.


You can go to MSDN.Microsoft.com/securityguidance and you'll get to this wonderful page with lots of great information, I hope you'll take it seriously.


Hey, we'll see you next time on ARCast.