Listen to or download the 6:05 minute podcast below:

Download file

What follows is a transcript of my podcast with two people from Packet Analytics, Andy Alsop, President and CEO, and Ben Uphoff, the Vice President of Research, where we discuss Packet Analytics' Network Forensic Search Engine, how to tool was developed at Los Alamos National Laboratory, what the Network Forensic Search Engine does, how it would have helped with an access breach like Societe Generale, and, finally, what they see for the future of security.

Packet Analytics recently announced the launch of a Network Forensics Search Engine, give me a brief overview of both your company and what the announcement entails.

So essentially, what we’ve done is we have developed technologies that has been licensed exclusively out of Los Alamos National Laboratory and we have commercialized the software that was developed by Ben and developed it and are selling it as product called 'Net/FSE' or the Network Forensics Search Engine.

It allows security analytics to do deep dives into network alerts using all that voluminous network data (IP-based data) that exists on the network and allowing them to dig down deep into those alerts and put contexts around those alerts far beyond any of the other solutions that exists in the marketplace today.

As you mentioned, it was with an agreement with Los Alamos National Laboratory. I find that fascinating so tell me a little bit more about that.

Well, the technology was developed at Los Alamos based on the needs of the network engineering group there, specifically, the network security team. And what we were faced with was millions and millions of events being generate by the network every day that all had really interesting information in them but we didn’t really have the technology to quickly search and efficiently store that data so we set out to solve that problem by developing Net/FSE and that technology allows the security analyst at Los Alamos to, in a single web interface, access all the network log data that’s important in their day-to-day operations to get down to the bottom of security incidents, intrusion detection, system alerts, or just kind of, you know, user troubleshooting questions.

So now tell me a little bit more about how the search engine works and exactly what does it tell you.

The search engine is designed and optimized to quickly search through IP-based network information. One 'sweet spot' of the search engine is NetFlow data and that was a real driver of the technology. At Los Alamos they were generating over a hundred million NetFlow events from routers alone off the network, that’s not even including firewall data, IDS data. We’re looking at potentially hundreds of millions of network events and the search engine was designed to be optimized for that situation and to quickly put the data at the fingertips at security analyst and work as a tool for them to do their analysis and incident response.

How would a tool like this have stopped what happened to the bank in France, Societe Generale, where the rogue trader essentially traded away $7 billion.

Well, what I would say is that essentially it’s not going to stop an event from happening but what it allows the security analyst to do is to be able to recover much more quickly. Currently, what ends up happening is that there is no way to have visibility -- significant visibility into all of that network data as it exists today and many organizations aren’t even collecting it.

But if the bank were to have been collecting this type of data, what it would allow them to do is to look into the activity of that trader to put more contexts around his activity and what he was doing. So as soon as the alert or something triggered his behavior that something had been going on. And they need to do the forensic investigation beyond just what he was doing in his trading system, it would allow the analyst within the organization to determine maybe what his motivation was or what websites he was visiting, looking at his email traffic, looking at his network traffic to be able to put context around all this trade activity.

And as you’re seeing in the, you know, in a lot of the news reports, that’s one of the -- one of the pieces they’re still digging down into is what was all the motivation behind this and all the trades that he did.

Now, what do you see for the future of both security and your company?

Well, what we’re seeing is there are trends in the industry and they’re already starting. There’s a -- if you consider the whole security -- the IT security piece as being a pie, a large segment, maybe 90 percent of the pie right now, if not more, is being focused on the -- what we call the “protection and detection” side and that is securing perimeters and looking at what intrusions might be coming in and trying to block those intrusions.

We expect that companies have to and will continue to invest in those technologies. But there’s a piece that’s missing and that’s the piece we’re bringing to the table as well and that is the incident response side that -- the ability to respond when something happens. Because you can just see in 2007 was really an awful year and there were a lot of companies that found themselves with situations they weren’t expecting and didn’t have the opportunity to quickly recover and respond.

I mean TJX is probably the bellwether example of having to take months to figure out what happened. There really has to be an incident response plan that is proactively put in place. And that -- I see that as being a growing piece of the pie for IT security spending.

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

So I just signed off from ebizQ's SOA Security Roundtable, and while I missed the first 15 minutes tangling with plug-ins, and still couldn't get it to work until I simply switched from Firefox to Explorer, I certainly plan to catch up on it as soon as it becomes available on ebizQ. Altogether, I found it quite enlightening.

One of the bigger questions to come up was, Who is going to do all the work? Who has the expertise to handle both software architecture and SOA security? More often then not, there simply is no one, so the best thing to do is find someone who knows a little bit about both, and someone who wants to learn a lot in a short time, and then grow and train your own. As Gunnar Peterson said, "You really do need these people, but they're not out there."

When it comes to thinking about SOA security, all agreed that you should start thinking about it immediately. And security training should start immediately, as failure to do so means opening yourself up to vulnerabilities. As Fred Etemadieh of the Open Group interjected, The earlier you start on a project implementing security, the less costly it's going to be in the long run.

Also, everyone agreed that SOA security pretty much requires a layered approach. Or, as Andrew Brown from Amberpoint calls it, the First Mile, the Middle Mile, and the Last Mile, with each step requiring specific tools and a specific approach. I think laid out like that really indicates how essential security is to SOA and will continue to be to SOA as long as there is money to be made from worldwide wickedness on the World Wide Web.

I'll certainly have more later, so stay tuned.

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

Regular readers to this blog might have heard me mention once or twice (or even thrice) and the day is finally here. Today is the day for the SOA Security Roundtable.

Today, this afternoon, at high noon...and if you would just indulge me and allow me to carry the metaphor a little further, imagine a dusty old Western three-horse town circa 1870. On one side of the street, at the Firewall Tavern, are the crusty old cowboys who still insist that putting a barbed-wire perimeter around the town will stop the horse thieves from riding into town and stealing their livestock.

Across the street is the SOA Saloon, a bar with all modern fixtures, and these cowboys like to ride the bucking broncos of high tech (which at this point is this newfangled storage device they're calling the Lazy Susan). They want to open up the town, give everyone a stake, allow everyone in the town to be a task-master over whatever task they reckon to accomplish (yeah, I know, but it's early, and I'm having a hard time cooking up a cup of coffee on this here campfire). But the folks at the SOA Saloon know that this will also increase the risks, and give those horse thieves a great many more areas to infiltrate and attack, so they need better protection, better security tools.

And in front of the Agility Hotel the old clock is marking time, the second hand slowly sweeping around the dial. Both sides watch and wait, because once it hits twelve noon, high noon, both sides are coming out with guns a-blazing.

Yep, that's right, it's gonna be the gunfight at the You're-Not-OK-Until-You-Attend-the-Roundtable Corral. Get a ringside seat right here.

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

This Wednesday's SOA Security Roundtable is really shaping up into a dream team of security panelists.

The four security movers and shakers ready to dispense their advice on SOA security are:

- Fred Etemadieh, Co-Chair of The Open Group's SOA and Security Project, Open Group
- Andrew Brown, Director of Security Product Marketing, AmberPoint
- Gunnar Peterson, Managing Principal, Arctec Group
- Mike Rothman, President and Principal Analyst, Security Incite

All we need is one more ringer, and ebizQ's starting five could play full-court press basketball against any dream team the NBA could ever dream up...Jordon, Shaq, Kobe, Magic...bring 'em on! Of course, I mean computer basketball. What do you think security vulnerabilities are on those video games...whatever they are, I bet those four above could find 'em and exploit them and have video Jordan and video Shaq playing just about as bad as our four panelists probably play basketball in real life (although they may have game, I'm just relying on the law of averages, and the fact that I stink at basketball).

Speculation aside, if you have any interest in cutting edge security (and if you're a CSO or IT person, how could you not), this Wednesday's roundtable really is the best way to learn the latest and greatest in SOA attacks and defense. And all my jabbering aside, just click right here.

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

First, you only have a few more days to sign up for this Wednesday's ebizQ SOA security roundtable. The roundtable now includes 4 featured speakers, a veritable who's who of security thinkers and doers, and as SOA security is as challenging as security gets, this truly is a can't miss. And all you've got to do is click right here!.

Now for the news: what was once considered fail-safe data protection (disc encryption) has been revealed as quite hackable. According to Science Daily, the attack exploits the fact that information does not disappear from RAM immediately after a machine is shut off. Generally, RAM continues to hold the information from several seconds to a minute after it's been shut down. This process has been slowed down to ten minutes when the chips are cooled using easily availabe "canned" air, which, when turned upside down, issue a freezing blast.

But this method does not even require a deep freeze, it's just the fact that as long as the keys are stored in RAM, those encryption keys can be had. The hack worked even when the attackers only had remote access to the computers network, and worked even after the encryption key has already semi-decayed, as they were able to reconstruct it from multiple derivative keys.

And what machines are at risk? "We've broken disk encryption products in exactly the case when they seem to be most important these days: laptops that contain sensitive corporate data or personal information about business customers," said Alex Halderman, a Ph.D. candidate in Princeton's computer science department. "Unlike many security problems, this isn't a minor flaw; it is a fundamental limitation in the way these systems were designed."

For now, the only true defense is to fully power down your laptop (or desktop, if you've got a suspicious looking Mr. Freeze working a few cubicles away), as computers in the active, sleep, or locked state are all highly vulnerable.

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

Make sure you sign up for what's certain to be an exciting and illuminating ebizQ SOA security roundtable happening next week Wednesday, February 27th. Sign up right here!

Listen to or download the 6:58 minute podcast below:

Download file

What follows is a transcript of my podcast with Anne Thomas Manes, Vice President and Research Director of the Burton Group, where we discuss SOA security -- how traditional security methods are insufficient for protecting SOA, why layered defenses are best, whether or not security will slow down an SOA deployment, and finally, what's coming in the future for SOA security.

What are top security concerns associated with SOA?

I would say that the biggest concern is the fact that with services, you’re exposing business processes within your organization and if you don’t properly secure those interfaces to those business processes, you’re now letting anybody in the world come in and access them.

And, you know, a lot of people think that well as long as I keep it only inside my firewall it’s reasonably well protected. But, you know, if there is a URL that provides access to a service, chances are somebody’s going to be able to connect into it. And the -- the idea that your perimeter is actually going to protect your internal systems is pretty dangerous at this point.

So you mention perimeters, which sounds a lot to me like a traditional security system. How come traditional security like perimeters and intrusion detection systems, how come they’re not sufficient to protect SOA?

They’re really good for protecting a single URL so as long as there is no links, or there’s no hops in the process, as long as you’re having a client talk directly to the service and you’re protected that one URL that’s providing access, then that might work okay. But the thing is that that when you’re -- we’re dealing with service-oriented systems, you typically have many different services involved in a process.

And as you go from one service, to the next service, to the next service, to the next service, you wind up losing all of the authentication information and you lose any opportunity to truly audit the process. And so you need some kind of mechanism to actually carry along the original user’s ID and to capture the path and all the different services that get touched in the process in order to capture the appropriate amount of information to support your requirements for, you know, all the regulations that are going on, or for e-discovery type of requirements and things like that.

So the traditional mechanisms that are out there typically are based on point-to-point security so they will protect a communication between one endpoint and another endpoint. And they will enable authentication between those two endpoints but they won’t provide the kind of security required to protect information when it’s sitting in an intermediary or propagate that authentication information on the next top in the process.

So is what I’m hearing, is it a layered defense would be best for SOA security?

Well, I certainly like layered defenses. So you got the idea. If you got your periphery on the outside, so you’re using traditional firewalls, using traditional virus intrusion detection and those kind of things because there’s an awful lot things that can filter out. But then, you also want to make sure that the individual endpoint does proper authentication, and you may actually want to put in multiple levels in between, which are giving additional levels of authentication, and capturing the audit trail, and other different areas.

So yes, I recommend that you use a combination of security protections when you’re dealing with a service-oriented system. You use the traditional periphery type of security measures, you also use identity-based security measures at the endpoints, and then potentially you use additional intermediaries to perform additional security capabilities like auditing, or cross domain, credential mapping and things like that.

Is it essentially a given that security concerns will slow down a SOA deployment?

Well, that actually depends, on how well managed your security strategy is. If you have too devised a security system for every single service, then obviously, that’s going to delay the deployment of a particular service. But if you’ve got security that’s automated and mechanized within your system, you could actually get it so that you simply deploy the service and then you can figure your security requirements at the service and it’s taken care of automatically.

That’s actually part of your governance program. You want to make sure that it’s part of your governance program, you have a standard security strategy and you just make sure that whenever service gets deployed that it automatically gets instrumented and secured according to your policies.

Right, that’s good to know. Now, what do you see as the future of SOA security?

At this point, I think it’s actually really easy to secure your environment. You just have to use different practices than what you would probably do just for your websites. There are some great technologies that are out there that will enable the kind of security that I’m talking about. Any platform that support Web services has the ability to support WS-Security.

So that gives you the ability to actually capture security information and pass it with the message and that’s one of the things that’s required to do the multiple layer defense approach. And then there’s some really good technologies out there from XML gateway vendors or from Web services management vendors who provide the kind of automated infrastructure that I was just talk about, which will automatically protect your services for you, and automatically configure the kind of management and security protections that you want, such that you don’t have to do a whole bunch of effort every single time you deploy a service.

So the basic security systems are in place right now, and that’s a wonderful thing, and I strongly recommend that people use these technologies to secure their systems. Now there are some additional things that are coming along so, for example, there’s a specification that was finalized last year at OASIS called “WS-Secure Conversation” and that actually gives you an additional layer of security by enabling two communicating service endpoints to establish a secure connection, and that actually is going to be more -- a more efficient way of establishing a secure conversation so that you don’t have to authenticate on each interaction.

You setup the connection once and then you use that connection for a series of exchanges and stuff, and so therefore, you amortize the cost of that initial connection over time. Two additional specifications: WS-Trust was also standardize last year and then WS-Federation just began. These are systems that allow you to establish security token servers, a place where you can go get a security token and it’s actually a component of WS-Secure Conversation to get these tokens to create the sessions.

WS-Federation, now, allows you to actually create a mechanism to cross domains, which is something that’s -- is inherent in business-to-business type communications and also even within a given organization. If you got a large organization with a lot of different business units, you probably have different security domains. And so being able to cross those security domains is a challenge today and right now you have to do a credential mapping, you have to put it an intermediary in between and have them actually map credentials one to the other. But if you can have that more automated that is probably going to be a nice feature. It’ll probably be two or three years I think before that’s really implemented in products but that’ll definitely make life a little bit easier.

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

First and foremost, the SOA security train is coming into the station one week from tomorrow, February 27th, and I hope you'll all be there for all the learning that'll going to be going on, learning that will undoubtedly help your earning, which you can do by just clicking here!

Also, this morning, I recorded a security podcast with the SOA extraordinare Anne Thomas Manes. We discussed various SOA security issues, and one of the more fascinating, and encouraging things, she related, was the fact that all the tools to secure SOA are already available, and all that's needed is implementation! Make sure you check in this Thursday when the podcast is live on ebizQ.

Now, back to El Blog. I was going to title this blog, "So when do you know your SOA security is enough," as that would have been more accurate, but I just liked this one better, taken, of course, from Nick Lowe via Elvis Costello's bombastic song, "What's so funny about peace, love, and understanding."

Last week I quoted from this document on various SOA security traps, and I just wanted to finish up with the point that, well, how do you know when you're done, how do you know when your SOA is secure enough to go for it!

While there are plenty of tools like penetration testing, vulnerability testing, source code analysis, touchpoint analysis, proof-of-concept, and third party reviews, the fact is, nothing can ever be 100 percent secure. To play on that classic line I once heard from a lawyer, I provide reasonable doubt at a reasonable price, in terms of SOA security, make sure you have reasonable security at a reasonable price. And just in case, make sure you have a contingency plan.

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

Don't forget next week's ebizQ roundtable on SOA security. Sign up right here!

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

Download file

What follows is a transcript of my podcast with Sanjay Beri, Vice President of Access Solutions for Juniper Networks. Sanjay has ten years' experience in the high-tech industry having played key roles at companies such as Microsoft, Newbridge Networks and McAfee, and in this podcast we discuss today's attack vectors, Juniper's solution, and the future of security attacks.

What type of attacks do companies need to be most concerned with in 2008.

Sure, there's really two types of categories of attacks that I would say come to the forefront. The first are associated with insiders, or your own employees, or end-users. And the first thing that most folks are realizing is that the threat of inside folks, employees, contractors and even partners often outweighs the attack vector that, for example, an outsider who wants to penetrate your network and steal data could weigh in on.

So that's the first threat. The first threat is employees, they're not experts in security, they do open email attachments, they do browse to websites, which are consumer-based websites full of malware and so on. They do what many would call normal things but in the security world, frankly, opening themselves to many threats.

And as a result, I think the first thing that folks need to realize when they look at threats is valid employees trying to do the right thing, doing things that are authorized at work will do things that open themselves up to attack and it doesn't need to be -- an attack doesn't need to be instigated by an outsider. An employee can actually instigate it by simply going to a website. For example, going to Facebook, downloading a widget, doing whatever many employees do with either for business or consumer purposes at work and that's -- that's the first thing.

And then the second, of course, is the traditional one, which is attackers, right, hackers. Most of them used to many times script kiddies and -- and folks doing this for fame. Nowadays, these are in many cases criminals, people actually trying to penetrate your network not leave any, you know, leftovers that tell you that they did it and often end-pointed attacks steal a lot data, those are the two big categories of threats that are out there.

So those are the attacks. Give me a quick overview of Juniper's solution?

So Juniper's solution is really broken up into both of those different vectors. And -- and the first is the recognition, I think, that-- and this sort of drives Juniper's development of its solutions -- the recognition that employees, partners, contractors, you know what, the philosophy that not to trust anyone is actually a good one.

And it's not to say that your employees aren't trustworthy or your partners aren't, it's just that, you know what, they don't know often what's on their systems. They don't know, for example, that there's a bot or a piece of spyware, or a malicious code on their system that will propagate to other users or servers.

So Juniper's solution on that side is to ensure that, for example, before a user gets onto the network, you not only validate who they are, user name, password, token, and so on but, frankly, that's not good enough anymore. You go in, for example, look at where they're coming from. Are they coming from my LAN? Are they coming from a kiosk? Are they a partner coming in from an external site, which I do not control? Are they coming in from the wireless network?

So that's one other factor. And then the other factor is what is their net, you know, end-point that they're connecting from look like? Is it all company- issued laptop, which has AV, personal firewall and so on, on that system, i.e., is it a secure system, you know? Is it, wow, that system is locked or that's a pretty open system? Take all of that data, all of those parameters and using our product, whether it's the SSL VPN, which is our market leading remote access product or Unified Access Control product, which is built off the SSL VPN but is more for campus and wireless networks versus remote access.

Those two products which basically have the same platform, same underlying policies, they take all of the data I just mentioned and they then allow a user access to the network in the right way, to the right resources, with the right security privileges, and they do that, basically, by dynamically assessing all three parameters, user, location, end-point state.

Then they provision the network. We do that in the UAC case, provision your firewalls; provision your switches via 802.1 access and so on. They provision them so the end-user gets access only to the right things. For an SSL VPN, where all traffic goes through the product, it is a proxy and as a result can do it immediately for you on the product itself and provision only the right resources to the right users at layer seven.

That's the first step, access. Ensure that the right users get access to the right resources with the right security policies and do it in a way that's easy, manageable and as well open so that whatever vendor they have in the end-point. And frankly, in the UAC or NAC's case, whatever they have in their network, Juniper's switches or someone else's, it works, so open is key.

The second piece is -- let's say me, Sanjay. I have a valid computer, locked down, I authenticate it properly, I'm on the LAN. Does that mean that I just stop there and all of a sudden, I get access to everything and they, you know, I don't check that the person is doing something malicious? No. The second thing you need to make sure you have is inline control of these systems. You need to make sure that you have firewalls and IPSs looking at the traffic and seeing if there is something malicious that is being passed on the network from the user to the user and so on.

And that's where intrusion prevention comes in and we have products that integrate firewalls and IPSs together. And those products as well by the way do, for example, take that data that they get and pass it back to our SSL and net -- and UAC products so that if I'm on the network, and these products detect something malicious on the network, they notify a remote access and UAC NAC products and they can then de-provision or re-provision the user's access based on what dynamically was going on in the network.

How is Juniper's solution different from simply just bundling a bunch applications together and do a single appliance?

Sure. I think the first thing to remember about Juniper's solution is it's open. We are not forcing people and we never will to just buy our products. And it is a key characteristic of Juniper in general and a key characteristic of our solutions to combat these threats. We promote open standards like TCG and TNC, and we drive those standards in the industry, and collaborate with partners, competitors and others to make sure that, for example, if you have our UAC or NAC product, you can have whatever you want on the end-point.

If you want to use our 802.1X supplement you can, if you don't, you don't have to. If you want to use Vendor A's antivirus, you can, or Vendor B's, sure. Whatever it is on the end-point, we're driving open standards so that data can be in an open standard way fed to a NAC product and then provision the network. We're also driving things in the industry that allow networking devices to feed the results of what they see on the network to a product like a or UAC, Unified Access Control, which is our NAC offering to that in an open way so if you have our firewalls, our IPSs or someone else's, you can feed that data out.

So that's one big thing, it's open. The other key characteristic is that we focus on what I would say is “closed loop” systems. Systems that don't just, for example, you stick our SSL VPN in and or you stick our UAC in and you're done, that's it, you know. It doesn't work with any your other products. From a management point of view, you can't get reporting through that same management system that you manage your UAC or SSL with your other product that we have.

So generally, trying to solve that management framework while remaining open and realizing that single box integration is definitely valuable, for example, in the branch where you can't afford multiple devices. But people will want multiple devices in many cases. And they may not want them from the same vendor. When integration makes sense, we make and we offer those products, firewall IPS integrated, done.

You know we have that best-of-breed. Firewall IPS routing, same thing. However, in many cases, for vendors or customers who don't want that, we'll also make sure we work in that other mode so that's one big difference. Open, you want integrated, you want stand-alone. Making sure, that works. Closed loop systems, i.e., don't just let one product operate by itself.

It'd be great if you're a UAC and SSL product could interoperate with the firewalls, and switches, and IPSs out there and they made one plus one equal three instead of operating a silos, we make that happen. And then, the last point I tell you is this. One of the keys that we focus on is developing best-of-breed systems. We focus on the quality of what we deliver because we're focusing on customers who view they networks as strategic, right.

Customers who view security and networking as a driver for their business in terms of, hey, this is a differentiator, right. This can differentiate me. Not someone who just views it as, hey, let me just buy the cheapest appliance, that's not who we sell to. We sell to folks who view their networks as strategic and that drives our development and the quality of products we put out.

Since some of the solution is automated, can't that create problems if a hacker manages to change some of the automatic settings?

Sure, that's a good question. The automation, if you remember, the first thing that when folks, for example, configure a product. Say you go to our UAC product or SSL VPN product and you configure a policy, the first thing is everything I describe to you about end-users, it should apply to that administrator too. Who are they? Where are they coming from? What does their end-point state look like?

Access all that, then let them configure the product and set the policy. So first of all, on a control channel side, you need to make sure that you have the right level of authorization, authentication, access of that user before you even let them change any policies, and that is the first step to making sure that an unauthorized user doesn't get onto your equipment and set policies.

So that high level of security it needs to apply not just to your employees, and remote access employees, and your contractors, but to your administrators as well, and that's one of the big reasons you can avoid this. In terms of automation, after those automation policies are set, what we find is customers often start sort of in a non-automated way, they setup policies, they see how things often go, for example, you remember the IDS IPS transition.

Many folks adopted sort of IDS first and then moved inline prevention. On the remote access and NAC market, some have more closed looped systems than others. Some choose to automatically, you know, re-provision switches and firewalls across their campus. Some wait and get comfortable with it and then do it. So it's also a process, right. We don't expect folks to do everything immediately.

They'll go through pilots, they‘ll go through larger deployments and then they'll get eventually to fully or partially automated. So, you know, our system allows folks to cross all that chain, right. They can do whatever they want from the most automated to partially, whatever they're comfortable with. So that's -- that's one of the big things to make sure that folks have a plan and a phased plan to move along and roll these things out.

Now, what do you see as the future for security threats?

Sure. So the future is, you know, I categorize in two things. And I said, you know, these hackers and which are often criminals now and then there's protecting a corporation from its own people, and its partners, and contractors. Those two vectors are still the same. I think some of the big changes that you'll see is nowadays an employee often does a lot more than work at work.

You know it's not just surfing traditional websites and, you know, news sites and so on. It's frankly going to Facebook looking at widgets which one day could have malware on them or going to Google's, you know, initiatives when they, for example, launch lots of their, you know, whether it's video, open social whatever it is. Lots of these things, which take up a lot of bandwidth, which folks will be looking at, at work. These are just new vectors of attacks, new vectors of threats.

And as social networking and P-to-P and so on takeoff even more, it will enter the corporate world. Whether that is through employees doing things that have nothing to do with work or it's corporations using these applications for the betterment of themselves. So having a device and a system, which does what I said, access first. Who gets access to what with what security privileges, dynamic assessment of user location end-point?

Those paradigms will remain the same. What will change is all the different vectors in which attacks can come into the network. The other big thing, I think, you will see as well pretty soon and you've already seen, it's just this notion that folks who are attacking you -- malicious folks, they're not out for fame, they're still criminals so more pointed attacks whether its credit cards from large corporations or it's personal data; that will continue and that will get more and more sophisticated.

And as a result, systems on your network need to get more sophisticated, they need to understand applications. Ports and IPs, you know, that's a thing of the past, right. It's users, applications, understanding them, protocol, decoding them and so on. So more of that is absolutely critical to combat sort of the complexity of what attackers out there will be throwing at us.

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

Don't forget to sign-up for ebizQ's SOA Security roundtable in two weeks. It'll be hosted by none other than Mike Rothman (who not only knows his stuff, but is just plain entertaining). The industry will certainly be buzzing about it afterwards, so you might as well get it first hand right here.

SOA and SOA Security pressure information from two different directions: SOA from the inside, in wanting information to be opened up, and security from the outside, in which the only perfect security is no information is ever revealed to anyone, even to the person who created it. But in this post-manufacturing world we live in, our use of information is what separates us. You don't want to end up in a position of SOA vs. security, and to do that, here are some traps to avoid (taken from this IEEE Computer Society Document).

1. Assuming the vendor is taking care of security -- when buying a car, you can assume that the seatbelts, the air bags, pretty much all of the auto's security is taken care of. But with an SOA application, that is not true. And just like the baby in the back seat you buy a protective seat for, that's your information you need to protect.

2. Thinking that, because one aspect of security is taken care of, it's all taken care of -- Just because your firewall is up and functioning doesn't mean your secure. With SOA, security is much more than just perimeter and means working security in during the design and implementation phase.

3. Relying on a cursory risk assessment -- business relies on the effective allocation of limited resources, and some companies even rationalize that even though their SOA framework might have flaws, it's far less likely to be exploited then something like an unpatched router. Because even though routers are more popular with hackers now, now is an ever shorter time frame in tech.

4. Incorrectly relying on public metrics -- Some security experts rely on published vulnerabilities and bugs to determine a products quality. A better idea is to ask the vendor about security assurance in the software development lifecycle and if they use touchpoints.

5. Leaving security for later -- many experts recommend the start small and grow approach to SOA. That should be true of SOA security as well.

6. Relying too much on security standards or security features -- Many believe that standards such as SSL (for web servers), S/MIME, or WS-Security will provide security when, while they are definitely important, they don't fully secure the system. Implementation bugs or architectural flaws can still leave vulnerabilities, so think more in terms of software security assurance.

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

According to the Chronicle of Higher Education, colleges suffered more data breaches in 2007 than 2006, and most of those data spills were caused by mistakes or property theft than were caused by hackers.

Colleges reported 112 computer security incidents in 2007, nearly double the 65 incidents from 2006, according to Adam D. Dodge and his Educational Security Incidents Web site. The total number of incidents was 139, as some universities had more than one security incident (can you say tenure?), up from a total of 83 the year before.

Approximately 100 of the incidents in 2007 were Social Security number being exposed, and which involved a total of 1,085,708 records, which was actually down from 2,268,580 SS#s being exposed in 2006 in 66 incidents. Is it starting to seem to you that in a couple of years every American born will have more than one person using their SS#?

Most important, though, is the findings that hackers were not responsible for the spike in incidents, as the number of actual network attacks remained flat, at 33. So what remains the true data threat is not something new and invented, but as old as computing itself -- the data prat-fall.

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

An interesting blog over at Dark Reading quotes the antivirus inventor, Peter Tippett, as saying at the Computer Forensics show that many companies are chasing the wrong security risks, in essence they're still building their Maginot Line when the hackers have already mobilized.

Tibbet's first target was vulnerability testing, saying, "Only 3 percent of the vulnerabilities that are discovered are ever exploited," he said. "Yet there is huge amount of attention given to vulnerability disclosure, patch management, and so forth."

The next weakness Tibbet found was the fact that experts often try to perfect defenses until they are 100 percent secure, often throwing out those that come up short. "If a product can be cracked, it's sometimes thrown out and considered useless," he observed. "But automobile seatbelts only prevent fatalities about 50 percent of the time. Are they worthless? Security products don't have to be perfect to be helpful in your defense."

And there are still plenty of simple things security departments can do that can yield results and not waste time. "For example, only 8 percent of companies have enabled their routers to do 'default deny' on inbound traffic," he said. "Even fewer do it on outbound traffic. That's an example of a simple effort that could pay high dividends if more companies took the time to do it."

And as I try to point out here time and time again, Tibbet said that employee awareness still offers one of the best bangs for the buck. "Employee training sometimes gets a bad rap because it doesn't alter the behavior of every employee who takes it," he said. "But if I can reduce the number of security incidents by 30 percent through a $10,000 security awareness program, doesn't that make more sense than spending $1 million on an antivirus upgrade that only reduces incidents by 2 percent?"

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

Everybody uses Google whether they admit it or not (Google seems to have supplanted Microsoft in the tech hate department, but to me, Google has kept it's dominance because of innovation, not because of Microsoft like strong-arm tactics, but, now that Google is contesting Microsoft's merger with Yahoo in court, we'll see about that).

And as Google is always only a click away, it's probably a good idea to know your company's Google vulnerabilities before a hacker does. Some of the highlights of the list, taken from Search Security, are as follows:

Site

Important information about your company can be had from a straight search. As Google rates pages per how the internet views the importance of each page, a general search can give you a quick view of how the web world views your internet presence page by page.

Blogger interruption: I've actually been playing around with the Search Security list for the last half hour, and recommend you simply go straight to the list and find the hacker goodies sitting in Google's crosshairs by clicking right here.

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

Came across another interesting bit on Dark Reading about a new type of authentication, actually more of a prototype, one which is expected to solve the problems generated from everything from keylogging malware to spyware to shoulder surfing. The system is called Undercover, and instead of hiding the users input, it hides the authentication questions.

I know, you're probably saying, Whatchoo talking 'bout Willis? The system was developed by Nicolas Christin and two graduate students at Carnegie Mellon University (where there has never been a highly publicized breach that I can recall). "I am a bit nervous every time I withdraw money from an ATM," Christin said. "Crooks can see me type my 'secret' PIN and very easily figure out what it is, which becomes a big problem if they also gain access to my card number."

The system enlists a combination of visual and tactile signals in the authentication process, working with a trackball controlled by Lego Mindstorm NXT robot and displays a set of images to the user and asks if any belongs to the image portfolio that the user had previously selected. To combat shoulder surfing, the user's hand has to fully cover the trackball for it to function,.

The folks at CMU tested this system against a PIN system with 38 users, and we're able to hack all of the PIN authentications, but were rarely able to hack the Undercover method (in this test, it seems like the researcher were instructed to directly observe the person authenticating themselves).

More detail is expected in April.

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

Caught an interesting post by George Hulme over at Information Week concerning the government's plan to spend $30 billion dollars over the next seven years upgrading the security of US communication networks.

That number may have just passed by in another blur of our government dropping another billion here or there, that's a lot of clams. To put it into perspective, the Bush administration has already earmarked $6 billion for 2008, while Infonetics Research estimated the entire worldwide network security appliance and software market to have reached $5 billion in 2007.

While it's certainly good news the Bush administration is finally putting dollars towards their promises of better security, we're talking about more than doubling the industry. What could they be thinking?

I can imagine the pitch asking for funding from the National Security Adviser (or maybe they go straight to the defense secretary), probably mentioning the amount of money spent everyday on defense, and everyday in Iraq, then concluding that, well, the Internet is now the place where the whole world gathers everyday, thus it is bound to be the next battleground.

But the Bush administration has not said what they plan to spend it on, saying that would only weaken their efforts. As Hulme says in his blog, "I thought security-by-obscurity went out of fashion a few years ago." I'm sure there will be more details ahead, but until the government fills in more of the blanks, it's hard no to think this is going to end up being another big government boondoggle.

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

Found an interesting article over at Dark Reading about the newest wave of vulnerability testing known as fuzzing, AKA fuzz testing, fault injection, or input validation. Fuzzing is where an application's inputs, areas like username, file, or an HTML field, are tested with somewhat random data to discover bugs and protect against things like privilege escalation or arbitrary code execution attacks.

Fuzzing is increasingly being used by companies like Microsoft and Juniper, and often entails running a command line program over and over while adding various random characters in hopes of inducing a crash and thereby uncovering a vulnerability. Fuzzing can be used on targets like MS Word or Mozilla Firebox or even a network router (to check out Mike Rothman's most recent (and most excellent) piece on Application Security click here).

Admittedly, vulnerability testing applications in the development process will certainly slow down the application's development, but as it's becoming ever more evident, either you pay some to get rid of bugs now, or pay more later once that bug's been exploited and you're application has been owned.

To get the whole low-down on fuzzing, head right here.

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

We've all heard the cliche -- a chain is only as strong as the weakest link -- and in terms of security, where the rubber hits the road, I mean seeing the forest for the trees (now that we're in cliche land), it really is no surprise that Search Midmarket CIO News reports that a survey sponsored by GFI Software Ltd. proves that you're still only as secure as your most slipshod laptop-leaving password-written-on-the-palm-of-their-hand never-met-a-piece-of-malware-they-didn't-try-to-download employee.

Your company could have the Fort Knox of IT security, but all it takes is one simpleton in Sales or an idjit in IT (to say nothing of the folks who actively set out to sabotage) to make the security budget look utterly irrelevant and data-disembowel an enterprise.

GFI's asked 455 IT leaders of SMEs what would improve their security, and only 12% responded, 'A bigger budget.' 48% said better security awareness amongst employees, and another 25% said better security awareness amongst senior management.

Even more telling, 42% said they do not think their network are secure. Much of the growing insecurity is the proliferation of Web 2.0 technologies that have employees updating profiles on lunch brakes thereby bringing them ever closer to that one devastating malicious link.

What usually needs an upgrade then, is the level of communication between IT and end users. New employees need to go through a comprehensive course in what they can and can't do on the network (but what do you do about the executives already there?).

But that still leaves the proverbial sucker born every minute. And like they say in poker, if you can't spot the sucker sitting at the table then the sucker is you, in security, you really do want to spot the sucker and educate that sucker (and first and foremost, make sure that sucker isn't you).

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