Listen to or download the 11:46 minute podcast below:

Download file

In this month's edition of the Mike Rothman Security Report podcast, Mike interviews blogger extraordinaire Alan Shimel of StillSecure, as they talk about the pro's and con's of security vendor consolidation. This is a top of mind issue for application security professionals, since the acquisitions in the space (HP/SPI Dynamics, IBM/Watchfire) have already started.

Alan and Mike debate about whether it's better to buy from a big or small vendor and what to look for when making those choices. Alan is also subjected to the Free Association treatment, where we get to hear Alan's views on the IBM/ISS acquisition and how to deal with the really big security vendors, like Symantec, McAfee and Cisco. The transcript follows:

MR: Welcome back to the Mike Rothman Security Report here on the ebizQ Network. In this month's podcast, we're going to talk a little about vendor dynamics because, obviously, if you've been in the security space, or even in any technology space for a certain amount of time, you know that companies innovate then they kind of get integrated in terms of a consolidation into some of the bigger, whether it's IT applications, or security vendors, and then, obviously, their impact on customers as well as just how they're going to use that product, whether its continued to be invest in, whether its end of life.

So there are a lot of different types of discussions that need to go around this idea of vendor consolidation and you kind of maturation of a lot of the technology markets. And I think application security has already entered that phase so I think it makes sense to talk about it.

And today, I'm very pleased to bring on a very good friend of mine; Alan Shimel from StillSecure who has been in the technology space as well as the security space for many years has been through a number of these different cycles. And I'm certainly going to ask Alan to kind of illuminate a little bit in terms of what the best perspective from a customer viewpoint is in terms of how to deal with these consolidating markets. Alan, how are you buddy; are you there?

AS: Yes. Mike thanks very much for having me, always a pleasure to do anything with my buddy, Mike Rothman.

MR: So first of all, I mean I know a lot of people, especially since ebizQ Network tends to focus a lot on the application side that may not know who the myth, the legend Alan Shimel is so why don't you just give a couple of seconds on who you are and what your company does.

AS: Sure. So Mike, never under estimate the reach Alan Shimel first of all. I'm sure many of your listeners and readers are intimately familiar with me. But in any event, my name is Alan Shimel. I'm one of the co-founders of a company called StillSecure. And StillSecure is a secure infrastructure provider. We've been around about, geez, about seven or eight years now. And we have products in the intrusion detection prevention space, vulnerability management, and we're probably best known for our network access control product or NAC called “Safe Access”.

We also have a secured networking platform called “Cobia”, C-O-B-I-A, which is a free download. StillSecure is based in Colorado, Mike. Prior to StillSecure as you said, I do have a rather lengthy history in technology, IT, internet, and have as we like to say, it's not my first trip on the tuna boat.

MR: That's exactly right. So great. Lets kind of jump into the topic today, Alan. There are a lot of different deals in the application security space. So last year, HP bought SPI Dyanmics. You also have seen some consolidation in the source code analysis, Watchfire bought by IBM so a lot of the big application development companies and, obviously, big IT shops are starting to inflict their mass on this little world that is application security. And obviously, you've seen this movie before so, what are customers really have to worry about? What are some of the considerations that they should have if their vendor gets acquired?

AS: Sure. So a couple of things Mike. First of all, the three biggest lies in market consolidation, probably the biggest lie is, No, we're not for sale. Any of your vendors who are telling you that they're not for sale, are lying to you because everyone is for sale, Mike, you know that, I that. For the right price, any company be it public or private can be had. And too many times I've seen vendors answer customers by saying, Oh no, we're not for sale.

We're here for the long run. We want to do this. We want to do that. We're going to change the world. All fine and dandy but the fact of the matter is, Mike, company can be bought at any time. And I think the faster you realize that the faster you know. Secondly, I think from an end user dealing with their vendor perspective, Mike, it's very important to look at products that are standards based, right.

Because when you lock yourself into Black Box Technology, you are at the mercy of whoever buys, or whoever the acquiring company is, or even not in an acquisition. The company can close up shop tomorrow and you're left with a great flowerpot for a computer box. So buy stuff that's standards based where there is some sort of transition path. My two biggest pieces of advice.

MR: Yep. That's great. Application security is a little interesting in that there really isn't -- I mean there's obviously a lot of technologies that are standardized, right, the programming language the protocols, how you do things, even some of the attack vectors tend to be fairly standardized but I wouldn't say that there's like something like kind of TNC in the NAC world. So again, does that change your opinion about standards at?

AS: No. So look, whoever said TNC is standard that anyone uses? But that's a podcast for a different day. By standards, I mean what format is your data being kept in, your reporting, your results? Can you take that out? Can you export that data that is being accumulated into another database? Do you have open database schema? Are these reports, are they crystallized or can they be run in Crystal?

How is that data stored? Where is that data stored? Do you have access to that data? If its proprietary type of formatting or what have you, that's what I'm talking about. Yeah, everybody's going to have their own special source about how they examine code or what have you. But at some point, there's an end product they give you, Mike, and that end product needs to be able to be leverageable.

MR: Yep. Now, that's a great point. So if you kind of think about again, from the customer viewpoint, I can sit and talk to the small vendor. I can talk to, obviously, the acquired part of this big vendor. Were there any cases where kind of the warmth or the, hey, nobody ever gets fired for buying from IBM or HP. Is there ever a time when that kind of consideration really overweighs some of the functionality or business requirements why you would be looking at certain product?

AS: Yeah. Well Mike, there is a certain analyst down Atlanta way who has this big is the new small thing that would have us believe that no one ever does get fired for buying IBM, or HP, or Cisco. And maybe you are better off dealing with the big vendor only so you don't have to deal the evitable consolidation and change that seems to be the life of smaller vendors. But that road is fraught with its own dangers as well, right.

There have been many large vendors who would've bought a smaller vendor only to see the founding team of that or a brain drain. And it may wind up taking a very long time for that product to fall apart but it may in fact fall apart. And the big vendor may have to scramble to actually have it keep up with your needs and the reason why you bought the darn thing.

MR: Yep, yep. And the one thing that I would add to that, Alan, is being the originator of this biggest is the new small idea is as a customer, you can't forget about the business requirements ever, right. At the end of the day, we are all kind of working for whoever it is that we're working for but we are tasked with meeting the business requirements of that specific organization.

So once you kind of understand that, if again, one man's opinion is if you can find two companies with equal types of capabilities to meet your requirements in a similar way, I think there's certainly some comfort in buying from the big vendor. But again, not at the point of kind of sacrificing functionality that you absolutely need to meet your business requirements.

AS: Yes sir. And you got to make sure the big vendor's committed to continuing to provide that product. A lot of these guys buy it as a checkbox, right. And if it's a checkbox that you want, that's fine. But if you want more than a checkbox, make sure they're not just checkboxing it.

MR: You bet. You bet. And that's a great place to kind of segue into the next section of the Mike Rothman Security Report, which is, of course, free associations. So Alan, what I'll do now is kind of blurt out one or two, or maybe three, if I'm feeling all funky today, terms. Give me one or two sentences in terms of what you think of these things. So first place to start; let's talk about Internet Security Systems. And obviously, being acquired by IBM last year, what do you think of these guys?

AS: Well, look, ISS -- the ISS/IBM acquire wasn't the ISS of its heyday, but it was still a formable security team. I think, frankly, they're having a tough time finding their way within the monolithic IBM world, and they're becoming less and less relevant in the space if you ask me. I mean I can't tell you. We never run into them. The only thing happening, I mean, that's the danger of big is the new small, right. IBM has the checkbox. They've got to security but is it still relevant to what some of the pure play security guys are doing.

MR: Yep. And while we're on this topic, let's blurt out the next one, which would be big security or Symantec and McAfee. What do you think about big security nowadays?

AS: So you can't do big security without Cisco either. Let's not --

MR: Good point.

AS: For all the talk, they're still making the most money, I think, from security. They have the most security revenue so it's tough to compete. Look, I'm a smaller vendor competing with these guys every day. And you have a Symantec or McAfee that each control, I don't know, what is Mike, 20, 30 million desktops? And they have an entry in every silo of the market. You got to pick your spots on when you can go against them. They have inherent advantages at every step of the way. Thank God, they still don't all execute perfectly and they're enough people out there who are willing to give innovation a try with a smaller company.

MR: You bet. And that's great. I want to thank Alan Shimel, my friend. You can find him -- well, Alan, why don't you tell us where we can find you out on the web.

AS: Okay. On the web, you can find me. I was going say anything. On a Friday night or Saturday but -- on the web you can find me at StillSecureafteralltheseyears.com which is my own personal blog where I blog on security, and life, and technology, and kids, and everything else. And I'm now a member of the Forbes.com community of bloggers for business and finance.

MR: Wow.

AS: So -- yeah, it just it means I get to run some ads Mike. But anyway, yeah, you can hear me on that or look around at some security shows. You'll usually see me hanging out by the bar.

MR: You bet.

AS: The shorter little gray-haired guy next to me.

MR: Yeah. And I don't know who the short guy --

AS: I'm the taller gray-haired guy.

MR: I don't know who you're talking about. Again, thank you Alan for being here. Thank everybody for listening to Mike Rothman Security Report here on ebizQ Network. We'll be back next month with another action packed, quick-paced podcast to talk about some topic that's of import to us application security professionals. That's great. Have a great month.

Posted by pschooff in | Permalink | Comments (0) | TrackBacks (0)

I've been following the security markets for close to 15 years at this point, and I continue to spot the same trends over and over again. You don't have to be too smart to figure out where things are going, based upon where they've been. At least that's the way it's worked in technology.

Application security will be no different. Although still an early market, it's following the general deployment characteristics of its siblings in the network and host security environments.

One of the "big" research ideas I put forth in 2006 was a concept called "big is the new small." This idea reflected the reality that for most organizations, the idea of doing business with a security start-up created a risk profile they weren't comfortable with anymore. Certainly not for established and mature technology categories, like network security (firewalls, IPS, VPNs).

A manifestation of this mentality is the ongoing consolidation of security functions by the "aggregators," or "Big Security" as I call them, who bring market might and distribution leverage to accelerate the adoption of emerging security categories. Folks like Symantec and McAfee, and let's not forget the powers from other technology disciplines, like Cisco, Microsoft, HP, IBM and the like.

So what? Since you probably focus on applications and application-oriented security, why do you care? Basically, you've seen this movie before and it's happening again right before your eyes. Take a case in point last year, when within the space of a couple of months the leading application security scanning companies (Watchfire and SPI Dynamics) were acquired by IBM and HP, respectively.

As comforting as it is to have deep pocket parents like IBM and HP behind your favorite app scanner, is this a good thing? Will it remain a good thing? Should you start looking at other alternatives? Basically, you need an idea of whether consolidation is a good thing or a bad thing for you – the customer.

Unfortunately, history tells us that most deals are a lot worse for the customers than they are for the founders of the security start-ups, who tend to walk directly from the bank to the Ferrari dealership to flex their new found net worth. In a lot of cases, the acquired technology is buried within the larger company and innovation slows to a trickle, support drops off a cliff, and the technology dies a slow and horrible death.

On the other hand, is it any safer to go with a start-up that is still trying to figure out whether they can make payroll this quarter and if the investors are going to give them enough runway to grow their business? As you can see, there are risks on both sides. If you want a no-risk environment, go work…Ah, I'm actually not sure where you would work to eliminate risk. That's not an option anymore in any business.

Basically, you need to start thinking about #1 and that is you and the needs of your organization. That means focusing first on finding the product (or service) that most closely meets your needs, and don't worry about corporate heritage, funding, or ownership at this point. It's counter-productive. As discussed in my Buying Security Products guide, this first stage is about finding solutions that can meet your needs.

Once you have a "short list" of sufficient solutions, then you can start weighing the benefits and risks of working with a big company vs. a small company. Relative to application security, the entire business is not a stand-alone opportunity. There is a niche opportunity for maybe 1 or 2 of the firms to get to sufficient heft, but the reality is that application security tools need to be part of a bigger software development suite. So it's not a matter of if, but when the interesting, innovative tools will be swallowed up and integrated into a bigger suite of products.

That's what was so interesting about the HP/SPI and IBM/Watchfire deals. It wasn't the companies that did the deals, but where in those monstrous organizations the technology resides. Both of the acquired companies ended up in the application dev tools business units. Candidly, that's where the technology belongs.

So what's my conclusion? Basically, it's just a matter of time before all of the major players in application security are "consolidated" and subsumed into the collective of a big application development tools shop. Deals always create risk and angst, but it's no reason to not work with a vendor.

But it's also not a reason to do business either. Focus on what problems you need to solve. Find solutions and/or services to meet those needs. Then pick a vendor that you are comfortable with, regardless of how big they are.

While you are at it, build contingency plans – just in case. Application security folks should do that without even thinking anymore. Murphy's Law is alive and well. If it can go wrong, it will. So plan for that. If the vendor gets bought, make sure you have Plan B. If they are lost and stop innovating, let your wallet express your dissatisfaction. In the security business, deals happen. You should plan for that.

Posted by pschooff in | Permalink | Comments (0) | TrackBacks (0)

***Editor's Note: If you're interested in the secure B2B identity architecture of tomorrow, make sure you sign up for the Federation and User Centric Identity webinar today!

Listen to or download the 9:55 minute podcast below:

Download file

In this podcast Mike talks with Jeff Williams, CEO of Aspect Security, where they discuss everything you need to know about identifying and defending against the current scourge of cross-site scripting attacks.

MR: My friend Jeremiah Grossman over at WhiteHat Security actually has done a bunch of research that says upwards of 60 to 70 percent of websites are actually vulnerable to cross-site scripting attacks. So I’m very pleased this month to actually have lined up one of the preeminent experts on all sorts of different application security issues here too kind of explaining cross-site scripting, talk a little bit about how it is that developers can both address as well as make sure that their applications aren’t vulnerable to cross-site scripting attacks. And with that, let me introduce Jeff Williams; he is Chief Executive Officer of Aspect Security. Jeff, how are you, buddy?

JW: Great. Hi, Mike.

MR: So hey, why don’t you just kind of introduce yourself and Aspect Security for maybe a minute and just give people a feel for what you guys are about.

JW: Sure. I’m the CEO of Aspect. We’re a small company. We provide application security risk management services. We also have some training courses and some services to help companies start writing better code across their whole STLC.

MR: Yeah.

JW: I’m also the chair of OWASP, which is the Open Web Application Security Project and which is a not-for-profit foundation focused on application security and I encourage everybody to go check it out.

MR: OWASP.com is exactly right. That was one of the things you were going to talk about a little bit later. So if you would, why don’t we just kind of go over and give everybody kind of a pretty brief introduction to cross-site scripting and really why it is such a problem out there.

JW: Sure. So the underlying problem is really very simple; its developers are taking input from untrusted sources like the HTTP request and they’re sticking it into their web pages without any kind of validation or encoding. And what attackers can do is they can send in little fragments of scripts to an application. The script gets echoed back into the HTML pages and runs in the victim’s browsers.

So at the end of the day, it allows attackers to run scripts in the victim’s browsers. And JavaScript is a full programming language. You can write very complicated applications in JavaScript that do things like steal data, and steal session cookies, and accounts, and all the stuff that you would put into a Web browser so that’s why it’s a serious problem.

MR: Yep. Do you buy this number from WhiteHat in terms of 60 to 70 percent? I mean when you kind of go into a new client’s site and really start checking out what it is that they have, is this kind of the most prevalent issue that you find within their web applications?

JW: Well, it’s definitely incredibly prevalent. I actually think the number is probably more like 90 percent. We almost never see an application that doesn’t have some cross-site scripting problem in it; some of them are more obscure. Most of them are very easy to find, even a tool could find them. But they’re not the most serious issue. I mean they’re definitely important but in terms of impact, they’re probably not the most serious.

I would put access control issues, authentication issues, in terms of impact as higher but there’s no question that cross-site scripting is the most prevalent issue of application security.

MR: Yep, which actually brings up a good point. Obviously, there are things that are more serious. But what are some of the stuff? So you talked about JavaScript as being a full programming language, what are the things that attackers could do if they were actually able to perpetrate a cross-site scripting attack and actually gain control of the user’s browser?

JW: Now, when you authenticate with a Web application, you type in your username and password, and the site issues you a session cookie; it’s like a temporary hand stamp that you might use to get in. And if the attacker steals it, they can become you, it’s just as good as stealing your username and password. And JavaScript has access to the session cookie.

So if an attacker can perform a cross-site scripting attack, they steal the session cookie, and then they just become you. They can do anything that you can. Now, another thing they can do that’s with cross-site scripting that’s even more serious is they can inject what’s called an “XSS proxy” into your browser, which accesses applications as you.

So the attacker is actually using your browser as a proxy to browse the Internet as you; so sending out requests through your browser and then go to sites that trust you. So they’re using you as that trusted man in the middle and using your credentials to access sites and you might be totally unaware that any of this is happening.

MR: Yep, which could clearly be our problem. So obviously, it’s something that might not be the most serious but it’s certainly something that we want to address because it puts our users at risk, or our customers, if you’re in some kind of e-commerce type of application. So if you had to say that there were one or two or maybe three things that developers can do to kind of avoid this issue, what would they be?

JW: Well, I mentioned at the beginning, the underlying flaw is that they’ve failed to validate their input and do the appropriate output encoding before they put that input into a webpage. So there’s a bunch of different approaches to that, but really anytime you get anything out of the HTDP request, like a get parameter, or get header, or get a cookie. Anytime you get stuff out of the HTDP request you autovalidate it, and I’m talking about white list validation; not just checking for a view bad characters because that’s not going to get it done. You need to check if it’s a zip code you’re expecting it should look like a zip code.

So put a regular expression there or compare it against a list of known good values, something like that. And then for output encoding, anytime you deal with an interpreter, you want to do the appropriate output encoding. And for HTML that means you want to use something like called “HTML Entity Encoding”, that’s when you replace like the less than symbol with "<" and a bunch of different characters like that.

You should encode everything that you’re not really sure is safe for the browser, that’s all the special characters, anything that isn’t alphanumeric you should probably HTML entity encode before it goes into the browser. Don’t do a black list encoding where you’re just encoding three or four characters; we see that an awful lot and it’s dangerous because attackers know how to bypass those things.

MR: Yep. Yep. And so it’s really one of these things where it continues to be a kind of a arms races where you can do the output encoding and that certainly helps, but really the white listing approach is kind of interesting to me because, again, what you’re trying to do is only specify what can be allowed on your site and within the application as opposed to kind of looking for known types of attack vectors. It just seems to me like a much more leverageable and strategic way they go about building your application.

JW: That’s exactly right. The black list approach means you’re going to constantly have to maintain the black list and add new characters as attackers develop new techniques. The white list approach, if you say it’s a zip code, and its only five digits or five-four, it’s like that forever. You’re never going to have to change that definition so it’s actually much more efficient long-term to just do the work and do a positive security model for your validation.

MR: That’s exactly right. So Jeff , I want to thank you for kind of the little primer on cross-site scripting that was certainly valuable to me and I know the rest of the listeners here at ebizQ’s network. So what we always kind of end up at the Mike Rothman Security Report with a little session I call “Free Association”.

So what I’ll do is I’ll blurt out a statement or two and I just want a real quick top of mine one sentence or less type of approach from that standpoint or answer. And again, we’re just kind to try to have a little bit of fun with this but; again, I do think that it is pretty instructive to understand kind of some of the top of mind issues are. So you game for that?

JW: Sure, let her rip.

MR: Okay. Great. First thing I’ll ask you about are application scanners.

JW: Pretty good at finding cross-site scripting flaws, not great at finding a lot more, but probably should be part of your balanced breakfast.

MR: Great. What about the SDLC?

JW: If you want to do application security right, you got to get in your SDLC. I strongly recommend getting organized and maybe thinking about building the process around an enterprise security API. I just started a new project that OWASP about that. You can find it at OWASP and the project name is ESAPI.

MR: And that’s great. Let’s just kind of wrap up a little bit with OWASP. So in one sentence, again, why should folks get involved?

JW: It’s a huge free and open community dedicated to application security. we’ve got a zillion documents, a bunch book links, PDFs that you can download for free, and a ton of great tools, some of the leading application security tools including WebScarab, which is a testing tool, and WebGoat, which is a full application that you can use to learn how to test application security.

MR: That’s perfect. I want to thank Jeff Williams from Aspect Security; that is aspectsecurity.com. Is that right, Jeff?

JW: That’s right.

MR: If folks want to go find you. Go check them out. Again, one of the preeminent experts on kind of Web application security out there. And again, this is Mike Rothman. Appreciate everybody listening in to the Mike Rothman Security Report and we will see you next month.

Posted by pschooff in | Permalink | Comments (0) | TrackBacks (0)

***Editor's Note: If you're interested in the secure B2B identity architecture of tomorrow , make sure you sign up for the Federation and User Centric Identity webinar today!

This month I want to dig a bit deeper into the cross-site scripting (XSS) attack. The type of issue is rather pervasive out there in the wild, and most web site developers have no idea what an XSS is and how to fix it – until their users are getting hurt. The sad truth is that many web sites do'’t pay as much attention to XSS attacks because they aren't used to compromise the web site's data.

These attacks are used to steal information from the browser of the user, making them perform unauthorized scripts because they believe the website they are visiting is trusted. It's a nasty attack and relatively easy to detect, though harder to stop. Let's jump in.

What is XSS? How does it work?

A cross-site scripting attack uses an unsuspecting web site to launch an attack against a visitor, leveraging the "trusted" nature of the underlying web site. When the visitor's browser renders the compromised page, the malicious script, which is stored on another site (ergo CROSS-SITE), is executed providing access to information resident in the browser of the visitor.

XSS comes in two flavors. The first, called a "stored" attack, involves the offending script command to be entered into a text block. This could be a comment field, search box or message forum, etc. This can be a problem for any of the "Web 2.0" types of applications that allow user comment and feedback. If it allows visitors to insert and store data in your application, then it's vulnerable to a stored XSS attack.

The other type, "reflected XSS" involves more traditional social engineering. The visitor needs to click on a link, which has the malicious script embedded. The web site then "reflects" the script back to the visitor and it’s executed in the visitor’s browser.

What is the impact of a successful XSS attack? Who gets hurt?

Basically, the user gets hurt, not necessarily the web site, and that's been the big sticking point in taking XSS attacks seriously. The first generation of XSS attacks really focused on nuisances like cookie stealing, but more recently a new type of very malicious XSS is appearing. These new attacks can bring down web sites, cause users to take actions like they don't want to (like the Samy MySpace worm), and even host a phishing site within a real site.

To illuminate a bit on this last example, imagine that you are buying something on yourfavoritestore.com. So you go to their web site and everything checks out. The SSL certificate is right and the domain is right. You're good, right? Wrong. What happens if you enter in your userID and password and it turns out a malicious script in a comment field on that page launches a script that takes the data from your form and sends it to Eastern Europe? You'll never even know what hit you.

It's like an ATM attack where the bad guys bolt a fake front on an ATM machine. The fake front reads your card and then passes it to the real ATM machine. You get you money, like you expect – but the bad guys have your number and your PIN. XSS can do that, but a lot more transparently and with a lot less risk to the attackers. No wonder this attack is very prevalent.

Detecting the XSS

So how to you detect a potential XSS problem? Technically it's not that hard, although the scale of the problem is significant. Basically you have to check every form and field in all of your web sites. Anywhere someone can enter text into your web site needs to be checked. Obviously that's a tall order for a human, so you are best off looking at scanners to help automate the process.

How to fix the XSS?

Fixing the XSS is also readily doable. Here are three options to consider:

1. Web application firewall – Yes, a WAF will help to block if your web site calls out to a foreign site to execute a script. So if you front end your application with a firewall, you can largely eliminate the problem. Of course, all your traffic needs to go through that firewall so make sure there aren't alternate routes into the application that could get around the defense.

2. Code frameworks – A number of the packaged application frameworks are down with XSS, and have built-in validation processes to make sure that forms and fields cannot accept foreign scripts. Microsoft (once again) is leading the business on this issue, with ASP.net offering many of these advanced validation checks built-in. J2EE and Rails offer a lot of tips and documentation to defend against XSS attacks as well.

3. Developer training – It's great that a lot of the frameworks add defenses to stop XSS, but ultimately you want your developers to be aware of the attack vector and to code their applications with these issues in mind. Of course, we are a ways off from developers caring about security, but through consistent evangelizing and persistent testing of applications, you can get the developers on board.

XSS is a scourge, but a manageable issue. With a little preventative scanning and some proactive mitigations, much of the risk of XSS can be eliminated from your web sites.

Posted by pschooff in | Permalink | Comments (0) | TrackBacks (0)

***Editor's Note: If you like this podcast, make sure to tune into the upcoming ebizQ Webinar hosted by Mike Rothman about the latest and least-greatest threats titled Threatscape 2008.

Listen to or download the 11:52 minute podcast below:

Download file

This month Mike chats with Kevin Beaver of Principle Logic about the ins and outs of application testing. They discuss how network and system penetration testing differs from testing applications and why it's critical to look at the problem from both sides. Kevin also provides a little view into his tool bag and discusses what tools he uses for what jobs and, finally, Mike subjects Kevin to the free association treatment. Hear what Kevin has to say about Metasploit, source code analysis and cross-site scripting.

The transcript follows:

MR: Hello, this is Mike Rothman. Welcome back to the Mike Rothman Security Report on the ebizQ Network. This week we are going to tackle the concept of application testing. And you know whether we want to call application scanning, or you want to call it application penetration testing, you know, there are a lot of different ways to talk about the issue.

But given the fact that applications are still a bulk of and becoming increasingly the majority of where many of the attackers are going first, putting your applications through its paces, really understanding, you know, that the issues are, vulnerabilities, exploitabilities of that application are is absolutely critical. And I’m very pleased to have a local Atlanta guy, a good friend, Mr. Kevin Beaver with me today. He is with a shop called Principle Logic. Kevin how are you?

KB: Mighty fine. Doing great Mike, thanks for having me today.

MR: Oh, that’s great. That’s great. So Kevin why don’t give everybody a little bit of background Principle Logic and on what to do because you’re very well known in the networking and systems security areas but maybe not so much on the applications side.

KB: Well, I’m working on that. I am an independent information security consultant. In my practice I basically focus on performing security assessments, pointing out the flaws in networks, applications, databases, and even security operations so really end-to-end services. And I’ve also been doing quite a bit of expert witness work lately, and I do a lot speaking, and I have this new audio program series called “Security On Wheels”.

MR: Well, that’s great. That’s great. So since a lot of what you’re doing is, you know, kind of assessments and really helping folks go through and understand, you know, what’s actually happening in their infrastructure as well as their applications. You know why don’t we kind of start with a little bit in terms of, you know, how you tackle a network assessment, or a systems assessment and how that’s different than, you know, how you tackle an application assessment, you know. Well, is it is that the tools, is it just the methodology, or the mentality, or is there no difference at all; a test is a test is a test?

KB: Well actually, by and large a test is a test is a test. I think the big differentiator is the tools that use. You know whether you’re looking at a operating systems, network infrastructure devices, or web applications, the methodology is the same. I’ve used what’s called the “Ethical Hacking Methodology” where, you know, you get in, you plan things out, you do your testing, which involves, you know, performing your initial scanning, your reconnaissance, your actual vulnerability findings, and then any exploitation, and then once you’re done with the testing, of course, you got to go in and analyze your results, you got document your results, and then deliver the reporting phase essentially.

So really regardless of what it is, if it’s an IP address, if it’s a URL, if -- basically, if it has an on/off switch, it’s essentially the same. I think the biggest differentiator is the tools. And whenever you’re looking at an entire network of systems -- of operating systems, routers, firewalls, switches, you name it, you’re going to want to use good tools that are specific to those type of devices. I mean for instance, I use QualysGuard to find network and OS level of vulnerabilities and then follow-up with tools like Cain and Metaspoit, and some of the Back Track Live CD tool’s to exploit the flaws.

MR: Yep.

KB: A lot of times, if I’m doing an internal network assessment, I’ll use a network analyzer called “OmniPeek” and I’m able to quite often find some network anomalies that you’d never find otherwise, you know. And he thing is with the network layer or network-centric vulnerability assessment tools, they’re going to look at everything, they’re going to look all the way up to Layer 7, you know, look at the Web server and maybe some of the web application components, but they’re not going to dive in deep enough and that’s where these applications, security specific tools come in to play.

MR: Good. So that’s actually a great segue into some of these tools. Obviously, there are scanners. Obviously, there are, you know, some tools that are being positioned more as penetration testing tools so -- you know, again, you’ve been contracted to give SecurityInsight.com, for example, and by the way don’t do this.

KB: I won’t; I don’t have permission.

MR: Yes, that’s right. So let’s say, you know, I contract you to kind of figure out where the holes are in my application or my shopping cart or something like that. You know, how do you get started? What are the first couple of things that you end up doing?

KB: First couple things are determining what’s the URL, obviously. And then figuring out do you want to look at this from a true outsider’s perspective or do you want to look it both from an outsider’s perspective as well as a trusted user’s perspective. And a lot of people they just look at their Web apps from the outside.

They assume, well, you know, we’ve got these Eastern European bloc countries, and Asia, and all that stuff, they’re trying to hack into our system, that’s what we need to worry about the most. But a lot of people overlook the fact that somebody on the inside, somebody that has a trusted access into the environment may actually be able to get in and manipulate the URL, get in a poke around and do things with the application that allow them to penetrate the system.

MR: Yeah. So, either you’ll go in, you’ll kind of check out the URLs, you’ll kind of look at it again depending on whether you’re kind of acting as either an outsider or a potentially trusted insider. You know there are certain, you know, set of tools or a number of tools that you have in your little kitbag that help you do this stuff?

KB: Absolutely. Even if I’m running a general application assessment, I tend to use some of the network level tools like QualysGuard and Nessus and things like that just to get an overall picture of the server that the applications running on and maybe find stuff that some of the higher level scanners aren’t going to fine. But then I’ll actually start digging in and using tools like HP’s WebInspect is usually the primary tool that I use.

MR: Yep. I mean have you seen any difference in level of support or, you know, kind of responsiveness since they were actually bought -- since SpyDynamics, is again, another local Atlanta company was acquired by HP?

KB: No, I mean if anything, it’s gotten better so. I’ve always had a good experience with these guys and that’s why in my work I strive to be vendor neutral but if I find a product and a vendor that I really like and really believe in, I’m not ashamed to tell people who it is and to point people in that direction.

And, you know, just like QualysGuard, I think that WebInspect is an excellent tool if you’re looking to find the most vulnerabilities without all the false positives and all the noise that a lot of the other ones will generate.

MR: Yep, I’m sure a lot of listeners certainly appreciate that perspective because --

KB: Sure.

MR: -- and again, there are just a lot of solutions out there and to hear from, obviously, somebody knowledgeable in terms of what works -- that’s, obviously, you know very helpful. So, you know, let’s talk a little bit. So you’ve got some tools but the tools will only get you so far, how much of doing these assessments, you know, well get back to your own skill or your ability to interpret the information that comes out of the tool versus the tool itself?

KB: It’s almost always about 50/50. It’s 50 percent tools and 50 percent human expertise and context. You know a lot of people they go and they run their scans but they never do any in-depth checking or validation of the findings of their tools. And you’ve got to take your security scanner results with a grain of salt. And the thing is no matter how good the tools are there’s simply not going to find us certain vulnerabilities.

And really, likewise, no matter how good you are at finding security weaknesses, there’s no way to test that the level that these security testing tools can test. So it’s got a be a good trade off, it’s got to be good balance and, you know, using good tools and pulling in your expertise, your experience, your analytical abilities is really important to find out what matters in the environment that you’re testing.

MR: Yeah. Great. So, you know, anybody that’s listening out there don’t worry you will still have a job tomorrow.

KB: Oh absolutely.

MR: We’re not having a Terminator action here where SkyNet is going to come out of the sky and -- and make all of us security folks irrelevant.

KB: Well, as much as the vendors want you to believe that all you need is their tool, it’s simply not the case.

MR: Well, that’s great. That’s exactly what I think everybody wants to hear. So now we’ll kind of bridge into what I call “the free association” part of the -- of the show. And, you know, the rules are pretty simple, Kevin. I’ll blurt out a statement; you kind of provide your perspective and what I hope to be a sentence or less.

KB: Okay.

MR: We’ll do a couple of them and, you know, again, we’ll just see where it goes. So let’s start with Metaspoit.

KB: A must have security testing tool. That’s the first thing that comes to mind.

MR: Yep. No, that’s great and that’s what exactly what free association is about. And for those of you that aren’t familiar with Metaspoit, it’s actually an Open Source exploit penetration testing service or package, I guess, is what you would call it. But it actually uses real exploits to help compromise machines and understands, you know, where the real holes are as opposed to broader vulnerabilities.

KB: Yeah, it actually helps you to show just what can happen out when QualysGuard and Nessus, and all these other tools find the missing patches. It allows you to take things to the next level.

MR: You bet. Source code analysis?

KB: Got to have it, not seeing enough of it.

MR: And Cross-site scripting?

KB: Still see it everywhere; don’t know why it’s not fixed yet.

MR: That’s exactly what free association is all about. Because you know again, I mean, I’m seeing a lot of the same stuff which is, you know, source code analysis is just hard and, you know, this is part of the reason I’m excited to continue to work withebizQ is that it’s largely an application developer that their heritage is certainly application developers and SOA, and a lot of application oriented stuff. And, you know, it really is an evangelizing role that we security professionals have to take with, you know, kind of the idea of building security, and building secure applications sooner rather than later. And the fact that a lot of people are, you know, not embracing source code analysis, and a lot of people, you know, still are plagued by, you know, again, pretty straightforward, you know, attacks that can be solved with things like, you know, input validation, you know, like SQL Injection and some of these other buffer overflow issues. I mean, you know, again, you look at from a security guy standpoint, you know, like why is this stuff still happening? But again, it just gets back to the evangelizing that we as security people continue to have to do.

KB: Right. And you know what’s happening? The essence of all this is that developers by and large, I’m not saying all of them, but by and large, from what I’m seeing, they think that as long as they’re checking for memory leaks, checking making sure they have strong password requirements, and they’re using SSL, then that’s what security is all about, but we know that it’s way more than that.

MR: You beg; we do know. So with that, Kevin Beaver, thanks so much. Why don’t you again, give us some URLs so the listeners know where they can find you.

KB: Absolutely. My business is at PrincipleLogic.com. I have links to all of my articles, Webcasts, podcasts, you name in my audio programs both free and for sale are at SecurityOnWheels.com.

MR: SecurityOnWheels.com. Thank -- thanks again, Kevin. Thanks everybody for listening to the latest edition of the Mike Rothman Security Report on ebizQ Network and we will see you next time.

Posted by pschooff in | Permalink | Comments (0) | TrackBacks (0)

***Editor's Note: If you like this topic, join ebizQ and Security Expert Mike Rothman for this month's Threatscape 2008 featuring Mike Rothman and A. N. Ananth.

Applications are the path of least resistance for the bad guys. With a myriad of client-side attacks and other JavaScript and PHP vulnerabilities, many web applications look more like Swiss cheese than the entry point to an organizations most sensitive data. The reality is that bad guys are attacking your environment every day. Just check your firewall and application logs if you don’t believe me.

Wouldn’t it be nice to know what the bad guys are going to find before they find it? No, I’m not going to tell you to buy a crystal ball, though that may not hurt. A concept I’ve been pushing called "security assurance" focuses on testing your environment, including your networks, systems, as well as applications. You use the same (or similar) tools as the bad guys do, and you try to break your stuff.

I believe every company of size needs to have a dedicated team focusing on trying to compromise business systems. Sure it’s an investment, but it also provides significant peace of mind -- and we all know that is priceless. To know what will happen when the bad guys exercise your defenses gives you a huge advantage in the ongoing battle with the dark forces that are trying to steal your customer's private data and your intellectual property.

But testing your application after it's been let loose on the world is not too helpful. So one of the first jobs you have to tackle is evangelizing the need to get the security team involved early and often in new application initiatives. I speak to lots of folks where the security team doesn't find out about new applications being deployed until servers and infrastructure is being installed to support it. Suffice it to say, that's just too late to have an impact.

Once you figure out which applications are happening and when they are going live, then you need to approach the development lead and work out a testing scheme that allows you to put the application through a security gauntlet before your customers (and the bad guys) do.

The main tool in your arsenal is going to be the application scanner. These tools mimic a number of attack vectors, like SQL Injection, buffer overflows, and cross-site scripting, in order to find the break points in your application(s). If you aren't doing proper input validation, the tool is going to find that. If you can bring down the application via a buffer overflow, you'll know.

Network and system-oriented scanners have been around for years and the technology is very mature. Historically, scanners focus on identifying the vulnerabilities in a non-intrusive way. Penetration testing products on the other hand (Metasploit, Core IMPACT, Canvas) use actual exploit code to see which systems can be exploited. Pen testing tools brake stuff by design, and I assure you -- that is a good thing.

But the line between vulnerability and exploit is not as clear in the application world. It turns out the only way to figure out if an application is vulnerable is to actually launch an attack. So there is definitely a blurring between application scanners and pen testing tools. Let's be clear -- to a customer, the difference is meaningless. You want to know if a bad guy can own your application. You aren't interested in semantics and vendor category definitions.

So what's an application scanner good for? At this point, they are pretty effective in determining the simple (and well-known) attacks, like SQL Injection and cross-site scripting (XSS). More complicated attacks, using holes in JavaScript and things like cross-site request forgery (CSRF), are more problematic to detect. The point is atool provides a good start to finding the obvious application holes that a bad guy could drive a truck through.

I do need to caution you that tools will only take you so far. Don't get too comfortable that a skilled attacker won't break your application via an advanced attack or logic error.

Which brings up the main point: You still need good, competent, skilled personnel to test your applications. They can uncover how your business logic might allow a hacker to exploit how your application handles sessions or recovers passwords. These tend to be the low hanging fruit for the bad guys.

Skilled application testers are worth their weight in gold. Seriously! By taking a very critical look at your application before it goes live, you will save yourself a ton of heartburn and maybe even protect your customer's data while you are at it. Is that worth a little hassle during the development cycle? I think it is, but I'm not the one telling the sales people that the application isn't ready because a hacker could make mincemeat out of it.

So, even with a commitment to testing using tools and skilled people, you still aren't done yet. You also need to be able to create a sufficient level of urgency to fix the issues you find and maybe even delay an application from deployment. But that's another topic for another day.

Posted by pschooff in | Permalink | Comments (0) | TrackBacks (0)

Someone attending next Wednesday's SOA Security Roundtable asked the following question:

There are a lot of levels in security that need to get "stitched in" to provide process level security in the SOA enterprise. A quick review of the more obvious ones:

1. Identity verification ... authenticating the user is who they claim to be (password, digital signature, ...)
2. Role assignment ... defining a set of corporate "roles" across the whole enterprise, and provisioning users to them.
3. Access enforcement ... via SAML assertions(?) around key service point access to ensure only authorized users with the correct ID can invoke selected functionality.
4. Monitoring / reporting all access to sensitive (ex: customer) data ... a BAM function.
5. A set of business process definitions (BPELs) which correctly link the authentication and BAM services into the existing processes flow to meet predefined security constraints in SOA service governance policies.
and so on.

Question: How does an architect step back and compose "SOA Security" out of these discrete components, supplied by a variety of software vendors? Are there SOA best practices, SOA security design patterns, precanned BPEL or ... ??

Answer: There is no easy answer to that question without going into an entire treatise on SOA Security. But this topic, and many others, will be covered extensively at next Wednesday's SOA security roundtable. Sign up right here.

Posted by pschooff in | Permalink | Comments (0) | TrackBacks (0)