Listen to or download the 7:08 minute podcast below:

Download file

What follows is the transcript of my podcast with Ted Julian, Vice President of Marketing for Application Security, Inc., where we discuss the problems and best practices of database protection, how Pfizer could have avoided their third high-profile data breach in three months, what companies need to know about PCI compliance, and finally, the future of database security.

What are some of the problems and best practices companies need to know about when protecting their database?

It certainly starts with, "where are they?" Even with some of the largest, most tightly run organizations in the world, when we go and do a discovery, they almost always find some databases they don't know about, you know, whether it's because things are fairly organic and people are throwing up new applications or maybe they've bought three regional banks in the last quarter and they're still trying to figure all that out. It's not unusual at all to find even dozens of substantial databases than an audit or a security or other group didn't even know were there.

I see on the Application Security website that you say you're the industry's only complete database security solution. What does your solution have that others don't?

Essentially, what our DbProtect suite allows customers to do is apply the same security best practices that they've deployed over the past, almost 10 years, on their network and their general-purpose hosts, and bring that to their database. So specifically, I mean, not only discovery, which we talked about just a second ago, but also having done a discovery, the ability to assess those discovered systems for security vulnerabilities, misconfigurations that can allow people to abuse their privileges or otherwise compromise the database. Those two things are kind of the first leg on the stool.

The second is activity monitoring on the database. So that even if, for example, the DBA tries to do a select star against the credit card column -- take all the credit card numbers in the database, they'd probably have all the privileges in the world to do so but with good activity monitoring, you could flag that. And then finally the third, sort of optional component of our suite is column level encryption on the database so that even more the DBA tried to take just a few of the credit cards, something that even a finely tuned monitoring system might not notice, they go to grab them and they can't get them because they're encrypted and they don't have the key so in short, it's the ability to provide discover, assessment, and monitoring across the enterprise for those database. Everybody else that's in the "database security" business has one leg on the stool, no one else has even two, let alone three.

Anybody following the news probably knows that Pfizer just had its third data breach in three months. How would Application Security help Pfizer prevent these data breaches?

That reflects on everything we just talked about. I mean it could be as simple as the breach happens because it was one of those unknown databases and because it wasn't being tracked by anybody, so it still had default IDs and passwords in place on a privileged account and that's how somebody was able to get in. That's a simple problem to fix that we would easily discover.

It could be that somebody tried to run a known vulnerability against the database and get privileged on it and then stole the data. Well, that's something that good activity monitoring would alert you in real time against something like that. Or, you know, it could be that sophisticated DBA who might get through some of those other hoops but with column level encryption, they'd go to take the goods, customer data, whatever it is, and then it's useless to them because it's encrypted. So, there's any number of ways that we can help.

I think the key thing is that with these attacks these days, especially as compared with maybe two, certainly five years ago, they're focused, they're after data that they can sell. They're not looking to just deface a web site or otherwise create downtime so much, they want to harvest a large amount of data and to do so ideally without being caught, without tipping off any alarms, so they can then sell that data and with that change in threat, databases just come out as a real obvious target since after all, a lot of people in the IT organization labor mightily to make those things highly available with the most up-to-date information as possible.

What do companies need to know about PCI compliance and how can Application Security help them achieve this?

Anybody who's looked at PCI has probably heard about the "dirty dozen", where there's a dozen high level requirements within it. The short answer is that we help companies ground that PCI compliance effort or really any compliance effort in the database where that data tends to exist. So, you'll see when you tease through the requirements in PCI that in addition to maintaining, you know, up-to-date anti-virus and all the rest, they've expanded over time to include keeping your databases patched because that is where card-holder data sits so those systems need to be secure.

There's also a requirement in there to encrypt cardholder data and so we certainly apply there as well. And then the last thing, then, very important one to point out is the notion of compensating controls in PCI. In theory, the notion of compensating control, a substitute if you will, for some other requirement can apply to anything within PCI. However, where we most often see it applied is on that encryption requirement because of any number of reasons. It could be because...A) You simply can't encrypt it. With some older obscure database there simply isn't an encryption solution available. Or, it could be because of the nature of your environment, if you tried to deploy encryption, you know, the performance impact would be so severe the system would crash or you wouldn't be able to process transactions.

Anyway, there are any number of barriers to that particular requirement. Well, because of compensating controls, you might, for example, go to your auditor and say, "What we'd like to do as a compensating control is deploy granular monitoring against that database so that, you know, somebody could try to steal the data but we'd either be able to stop them or worse case, know about it immediately and be able to shut it down before the data could be leveraged against the customer." So that is a fairly common example of a compensating control. Monitoring, as a compensating control, against the encryption requirement since it is the one that many companies struggle with more than any other.

What do you see as the future of data security, basically both in terms of the coming attacks and the protection that's going to be needed to defend against them.

The bad guys are following the money, that's why databases are in the cross-hairs. You see it in the breaches that are happening, you see it in the research. Oracle, for example, was forced to move to a quarterly patch update schedule because there are so many Oracle vulnerabilities being discovered that they average about 80 or so new vulnerabilities every quarter and, I think, the hackers will continue to follow the money and to me that means continuing to move up the IP (internet protocol) stack into the applications themselves.

So, I think when we look forward we will see attackers looking at critical systems like SAP and PeopleSoft, Oracle Financials, other things that are the backbone of a company's business because that's the most valuable data a company has and thus what attackers are going to go after.

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

This September 30 brings another PCI (Payment Card Industry) deadline, where the major credit card companies like Visa and MasterCard have threatened fines and penalties if retail companies do not meet their requirements, but over a third of the Level 1 merchants (the largest retailers) will not be up to standard. Smaller merchants promise to post an even a higher failure rate.

"Sixty percent of the respondents in the U.S. and the U.K. will plan to be fully compliant in the next year, white 51 percent of companies in Germany and 40 percent of companies in Spain and France are planning to take more than one year to comply with PCI," says Forrester Research in an RSA-sponsored study that appears on Dark Reading. "Twenty-two percent of the global respondents plan to take at least two years or more before becoming fully PCI compliant."

The PCI standard has 230 requirements, and according to a recent VeriSign survey, 53 percent of companies failed to meet at least one of those requirements. That’s an improvement over last year, when the number was 73 percent. And for retailers that don’t make this end-of-September deadline, this will be the third one they’ve missed (the credit card companies had originally set compliance for June 2005). That deadline was extended to 2006, and extended once again until three days from now.

My money is on another extension. By why so many missed deadlines? Experts list three likely culprits: access management, application security, and encryption.

In terms of access management and control, more than 25 percent of the companies are having a difficult time classifying credit card data and securely storing it. Another 25 percent said they are having trouble with their access controls, while another 20 percent brought up access control technologies is their primary problem.

"One of the biggest questions was whether companies should do detailed code review or put in an application firewall," said Joe Lindstrom, senior director of compliance consulting at Symantec, who was a panelist at the meeting. "The standard says you must do either one, but it doesn't require you to do both, so a lot of companies are struggling with what to do there."

Finally, encryption continues to be one of the most problematic hurdles for companies facing PCI compliance. A continuing problem with encryption is the wireless environment, where WEP continues to dominate despite is many weaknesses.

And that’s still dealing mostly with Level 1 merchants, which hardly mentions Level 2 and below. So what is going to happen? If companies continue to fail to meet the PCI mark, look for the long arm of the law to step in. Because if anyone knows how to miss a deadline, it's the government.

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

Companies should look to spend less of their IT budgets on security, Gartner VP John Pescatore said in an keynote speech reported on at Computer Weekly. Where retailers typically spend 1.5% of revenue on security and typically lose 1.5% more due to theft, organizations typically spend 5% of its IT budget on security (a number which excludes disaster recovery and business continuity), and IT managers are being asked for more.

In Gartner’s annual survey, security has dropped from the most important issue in 2005 to sixth today, according to the CIOs surveyed. CIOs do not believe that security is a journey without a destination, as many other areas of IT are able to offer companies more business benefit for their buck.

That means the answer is to spend less. And to do that, security should no longer chase the latest threats, instead evolving into a model Pescatore called “Security 3.0.” The key to this model is security would anticipate threats instead of fight them off once they’ve already struck.

Pescatore compares this as evolving from a game like “Whack the Mole” to more of a game of chess, where security no longer relies on reaction speed and is firmly rooted in a long-term strategy. To do this, Pescatore recommends prevention, which means considering a system's security in the very beginning, and refusing to purchase products that are inadequately protected. While this may result in paying more upfront, we all know that prevention is better and cheaper than cure.

Pescatore also explained that, while a digital rights management system would not appear in time to make a difference in their lifetimes, what made most sense in protecting data was to keep track of where the data is flowing, and block it from flowing to insecure locations.

Gartner estimates that by 2010, a fifth of companies will have achieved “operations excellence,” where they will be spending just 3 to 4% of their IT budged on security, while two-fifths will still be stuck in the corrective stage, spending 7 to 8 percent.

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

In a recent survey released by Deloitte Touche Tohmatsu, and featured at Search Security, said that, while two-thirds of the respondents reported external security breaches in the form of viruses, worms and phishing attacks, the biggest worry now is insider attacks. 91 percent of those surveyed said they were concerned about employees, and 80 percent cited employees as the reason for informational security failures.

"Security used to be a cost thing and in many areas of IT we needed to reduce our costs," Michelle Stewart, CISO at AirTran Airways. said. "A lot more risk was accepted than there is today because of the publicity of the data breaches."

It’s not too surprising then that the survey found that pretty much all of the respondents reported increased security budgets. But of those, 35 percents still said that their spending on security was still lagging behind business needs and only 20 percent said they had the skills and competencies to deal with their security requirements.

"Due to the increased number of high-profile losses or theft of customer data, data protection has been the subject of intense attention over the past 18 months," Deloitt said.

From all this, look for security spending and to increase further.

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

While the day-to-day battle to keep our systems up and running is rather akin to fighting a battle in the trenches, sometimes it is helpful to find out what the generals are thinking looking down on the big battlefield from above and trying to build a long-term strategy for victory. The following 5 trends are from David DeWalt, the CEO of McAfee, taken from his keynote speech at a recent Information Week conference.

1) Large security vendors will continue to buy up the smaller security companies, meaning, "The security market will go through the same transition that other industries have," DeWalt said. "Right now you've got 50 or 60 vendors out there, and customers are faced with the questions of how do you integrate all those solutions, and create interoperability between them? It's not sustainable."

That means security will start coming packaged in the form of unified threat management, or what's also being called endpoint security, which I blogged about here. This will ease up the security pressures on IT managers and allow them to control and manage systems through a single console.

2) Compliance requirements will keep getting more stringent in trying to keep up with the ever escalating cyberthreats. "There's a lot of legislation around industries forcing them to comply with various standards for customer protection," said DeWalt, including PCI, Sarbanes-Oxley reporting requirements for public companies, and the many others.

DeWalt believes the government has gone too far, causing U.S. companies to become burdened with too much red tape, threatening America's competitive edge.

3) The growing movement towards protecting data. "Traditional security has always been concentrated on the perimiter, on endpoint devices, particularly with firewalls," DeWalt noted. "The focus now is on thinking about data-oriented security" by classifying certain types of data so that it cannot leave the corporate network or company-owned devices. And as so much of data is threatened by insider attacks, this type of protection will become ever-more essential.

4) The many new challenges that will come from server virtualization. "Virtualization is an amazing juggernaut in terms of security risk," said DeWalt, "managing and protecting a single physical endpoint is much different than managing security virtually," DeWalt said.

5) The emergence of more mobile devices will continue to offer hackers new attack vectors, forcing security to deal with constantly emerging threats. Said DeWalt, "We're in inning two of a nine-inning game here." And in this continuous battle, sometimes security will be ahead of the attackers, and sometimes we'll be behind.

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

According to David DeWalt, the CEO of McAfee, companies continue to underestimate the threats from phishing, data loss, application security, and other vulnerabilities which now represent a 105 billion Dollar business, surpassing the worldwide drug trade. So I guess when you imagine Scarface today, just picture him in his massive Miami mansion and, instead of being armed with the biggest and baddest guns and weaponry, all he needs now is the latest laptop.

According to InfoWeek, DeWalt said, "it's amazing how low the awareness is of cybersecurity threats" among both government officials and corporate executives. "As the world has flattened, we've seen a significant amount of emerging threats from increasingly sophisticated groups attacking organizations around the world."

There have been recent high-profile data breaches at TD Ameritrade, Citigroup, and TJX, and computer crime now totals a 40 billion a year business. Says DeWalt: "If you rob a 7-Eleven you'll get a much harsher punishment than if you stole millions online," DeWalt remarked. "The cross-border sophistication in tracking and arresting cybercriminals is just not there."

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

The birth of the security industry (and many of the largest security companies) came with the onset of the first virus, as I covered in my blog yesterday, but what's interesting is that in a recent survey, only 52 percent of respondents said they had even caught a computer virus in the past year.

As we all know, with all the electronic ink spilled over big and bigger security breaches, our computer insecurity is through the roof. So what's an Antivirus company to do? As with my last podcast with Symantec, evolve into a complete security solution, also known as an endpoint protection platform (EPP).

According to Amrit's blog, Gartner defines EPP as "the convergence of desktop security functionality into a single product that delivers antivirus, antispyware, personal firewall and other styles of host intrusion prevention (for example, behavioral blocking) capabilities into a single and cohesive policy-managed solution."

Just imagine if, when anything went wrong with your car, you had to go to that specific part manufacturer to get it fixed. For example, say your cup holder cracked, so you've got to go to Just Cup Holder Repairs to get it fixed. Well that's ridiculous, I know, because we simply buy one car from one car maker.

But the evolution of security pretty much defines putting the card in front of the horse, as it is the threats that drive our security protection purchases, creating a fractured protection profile at best. So where is it all going?

Essentially, Amrit sees security and operation converging on the desktop which will provide stronger systems management and more centralized admin of the whole system. But we all know that cybercriminals like nothing more than to run and end-around, or in the case of security, and endpoint around, which means that many of these security behemoths that are now touting endpoint security will have to remain quick and agile, or almost exactly what a corporate behemoth is not.

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

In what is already some very bad data-breach news for TD Ameritrade, in that in a company computer audit, some malicious code was found in a customer database that allowed hackers to steal the names, addresses, along with the email addresses of every single one of their 6.3 million customers, a recent lawsuit has accused TD Ameritrade of actually knowing about the data breach for nearly a year and failing to disclose the information to their customers, information which is critical to heading off spear-phishing scams.

TD Ameritrade contends that they only discovered the malicious code several weeks ago, due to customer complaints about an unusual flurry of stock spam. But the lawsuit contends that the company new about the breach much longer. According to Dark Reading, Scott Kamber, lead counsel for the lawsuit and an electronic privacy expert, said, "It's the most irresponsible lack of disclosure I have ever seen."

While Ameritrade does not comment on pending court cases, they contend that they were aware of customer spam complaints, but were not aware that it was being caused by malicious code secreted on a database.

The entire case hinges on Matthew Elvey, a customer who created an email account specifically for his Ameritrade account, and who then become suspicious when that email address started getting bombarded with stock spam. Elvey alerted Ameritrade of his suspicions that they were the source of the spam back in October of 2006.

At the same time, Elvey moved his dedicated email account to a new address, and not long after, the stock spam moved too. "At that point, there should have been no question in anyone's mind that Ameritrade's customer data had been violated somehow," Kamber says.

TD Ameritrade continues to claim that no Social Security numbers were compromised in the breach, but that, along with their obfuscation in customer notification, is seeming more and more unlikely.

Once again, a reminder to sign-up for the ebizQ Security Newsletter, where you get all the security news you need right in your in-box. You can do that right here.

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

According to the Computer Security Institute (CSI), company insiders have now overtaken viruses as the greatest threat to corporate computer security.

For the 2007 Computer Crime and Security Survey reported by Infoworld, the CSI questioned 494 security folks from different US companies and government organizations, finding that an insider incident had occurred with 59 percent of the respondents, with only 52 percent saying they had caught a computer virus in the past year.

The good news is that both insider incidents and viruses have been falling since the year 2000, when the two reached their zenith, but this is the very first time that insider incidents have eclipsed viruses. The CSI does define insider incidents in a very general way, including leaking or stealing company information, but also such things as using pirated software, or accessing pornography.

The other type of threat that the CSI is seeing an explosion of is "laptop and mobile device" theft, which many think will also soon overtake viruses as the second most realized security threat. The survey also recorded a growing incidence of targeted attacks, where 28 percent of the companies felt like they have been carefully chosen for a specific attack.

Internet-based attacks were also found to be more integrated, thereby blurring the lines between consumer and corporate security, which used to be seen as separate concerns.

"In the past, the struggle has been cast as one between security professionals and the criminals who attack their networks. Now, the picture is more complicated. Criminals attack both enterprise networks and steal customer data. They use this data to then attack individual consumers," the report concludes.

With the frightening rise of insider attacks, perhaps the corporate motto of the 21st Century is going to be, "Keep your employees happy."

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

Listen to or download the 11:27 min. podcast below:

Download file

What follows is the transcript of my discussion with with Brian Chess, the founder and chief scientist for Fortify Software and also the author of the excellent book, Secure Programming with Static Analysis. In this podcast we discuss static source code analysis (also referred to as application security testing), how it defends against cross-site scripting, how static analysis can keep up with the ever-evolving threats, key PCI requirements that companies need to be concerned with, and finally, how static analysis helps protect against the dangers of Web 2.0.

Also, I highly recommend checking out Fortify's excellent White Paper, Web Applications Under Attack: Four Eye-Opening Findings.

Can you give me an overview of what static source code analysis is and how it works?

Static analysis really refers to any process for analyzing code where you don't run the code. And that might seem a little odd at first, because code is built to be run. But when you do analyze the code statically, you have an opportunity to explore many, many more possibilities than you can when you have to actually run the code and put it in a variety of different states.

So most people are familiar with static analysis tools, although they might not call them that. For instance, "compiler." When it does type checking, is performing static analysis. There are a lot of different static analysis tools out there. Some of them are pretty basic. They are basically grepping through code for patterns of, you know, letters or characters or white space and triggering on that sort of thing.

The static analysis tools I'm much more interested in are a lot more advanced than that. They are actually tracking paths through the code and trying to figure out how an attacker might actually be able to manipulate a piece of code.

For more than a few people, 2007 was probably the first they even heard of application security testing. Why don't most of the standard security solutions protect against these types of vulnerabilities?

Historically speaking, we've been able to get away with building software that contains security defects and then somehow putting some protection around it. For instance, a firewall protects a potentially vulnerable internal network from all the bad stuff out there on the Internet that might want to get at it. And that works just fine until you want to hook up that internal software so it can talk to the outside world. And now we've really got to depend on the ability of the software to defend itself. So we can no longer put some sort of prophylactic around it. We've got to make the software itself secure. And that's really what has changed over the last five years, is we've started exposing all sorts of systems to the Internet. And then depending on those systems to be secure.

And now that means we've got to go inside and look at the code and make sure that the code is written the right way in a tenable fashion, a way that's going to allow legitimate users to get what they want out of it and not allow malicious users to get anything else out of it.

Looking over Fortify's Web site, I really enjoyed your demonstration on cross-site scripting. And I was quite surprised at how vulnerable many Web sites still are. How does static source code analysis help defend again cross-site scripting?

You hit on a topic that I like a lot. I think cross-site scripting stands a good chance at being the new buffer overflow. And let me explain what I mean when I say that. So, let's back up and talk about buffer overflow for just a second. So, buffer overflow attacks are deadly because they allow a bad guy to overwrite your program and essentially insert their own code into your program. There are also really easy mistakes to make in C and C++ because C and C++ weren't designed with much security in mind. So they leave the possibility of errors that lead to buffer overflow wide open.

So now let me make the comparison to cross-site scripting. So cross-site scripting is, in most Web-facing languages, a really easy mistake to make. It happens when you allow some piece of input that an attacker can control to be reflected directly into the Web page that you are creating. And so in order to see this analogy, you have to understand that modern Web pages just aren't static things anymore. They're really more like programs that you're downloading into a browser.

And so now what we're giving is the attacker an ability to almost rewrite that program that you're downloading into the browser. So here you've got a mistake that's easy to make and that gives an attacker quite a bit of control over what gets executed in a Web browser. Now to back up five or maybe even ten years, cross-site scripting was sort of a novelty item. You could go to somebody's "sign my guest book" page and maybe put "Barney the Dinosaur" on their page so you couldn't see any of the other stuff on it and ha ha, isn't that funny?

And more recently, cross-site scripting has been about phishing attacks. So you send somebody to a Web site that looks like it's trusted, but really, the bad guy is going to harvest the user name and password information off of what appears to be a trusted site. Even more recently than that, people are starting to figure out that you can use cross-site scripting to attack internal networks. You can really use cross-site scripting to bypass a firewall and start exploring on the inside of a victim's network.

So back to your question about, well, what does static analysis do for you? Really, what static analysis does is it allows you to look at all of the different things that are influencing the Web page that you generate. And if one of those things that is being put into the Web page is something that the attacker controls, then cross-site scripting is a possibility. And so what we can do is point out to people where they need to go back and take extra precautions in their code in order to prevent the vulnerability.

How does static analysis keep up with the ever-evolving threats?

That's a really good point. Actually, both sides of the equation are both constantly changing. Let me tell you what the two sides I see are: one is how are people building software. And that's always changing because people are changing the programming languages that they like. They are changing the programming frameworks that they use within those languages. And really, software development just never holds still. So we constantly have to keep up with -- well, what are programmers trying to do with their software? And what kind of mistakes might they be able to make?

Now, on the other side of the equation, we've got to look at, well -- how are attackers going at the software? What kind of techniques are they using? What have they learned how to exploit in better or more malicious kinds of ways?

And so we've really got to look at what are the programming constructs and what are they vulnerable to, and then, how are they going to be exploited?

And so the end result of balancing that equation is a constant stream of new rules that we feed to a static analysis engine. So a program that looks like its completely secure today, we may find out tomorrow is actually susceptible to some new kind of attack and we'll want to go through that program using static analysis and a new rule set in order to find those types of weaknesses.

Now what are some of the key PCI requirements that a company needs to be concerned with and how does Fortify help address them?

I hear a lot of people talking about PCI today. I think it's a really good wake-up call to people, the security of their software matters and it matters in a couple of different ways. I'll tell you where most people come and talk to Fortify about PCI has to do with Requirement Six, which calls for developing and maintaining secure systems and applications. And that means doing things like checking your code against the OWASP top ten. You may perform a complete code review in order to meet requirement six. And those are the kinds of things that static analysis can help with.

Let me say that I think sometimes people overlook a couple of the other requirements. They overlook Requirement Three, which calls for protecting stored data. And that's something that actually using a static analysis tool can help with a lot because you can trace where the data in your code is going to. So, for instance, if you end of writing a piece to track credit card data to a log file without realizing it, that's the kind of thing that you might use a static analysis tool to trace through the code and find.

Similarly, Requirement Four requires that you encrypt transmissions of cardholder data and you can do the same thing: you can find out, well, where maybe am I putting credit card data onto the wire without encrypting it by using a static analysis tool.

How does application security testing help protect against the vulnerabilities of Web 2.0?

I really like the Web 2.0 story. Because it's yet another shift in the titanic battle between client and server. So, I mean, just the history of computing, you can frame in terms of this client/server balance. In the beginning, we only had servers because we only a couple of computers in the world and you had to go up to the front console of the computer and rewire it in order to program it. And then eventually, we figured out that we could hook up a bunch of terminals to the same computer. And then the thin client was really born. And then Xerox Park came along and introduced the Alto and that was a small personal kind of computer for the first time. And then, of course, the PC revolution was not far behind that.

And we ended up a lot of client-side computing. Then the Web came along and the Web pushed everything back onto the server. All the smarts were all on the server and all you had was this very simple renderer in the form of a Web browser to accept what the server sent down. Now Web 2.0 comes along and says, "Hey! That simple little renderer actually can execute scripting languages like, for instance, Java script. And you can start to make a really rich client experience by pushing a program down into that Web browser." What we've done is we've taken a big hive of complexity on the server and we've divided it up between the client and the server now.

What that makes for is a much more complex communication protocol between the client and the server. And what that means is that standard ways that were used to testing Web applications just don't work as well anymore. Because we've got a much more rich interaction. We've also got the opportunity to make all kinds of mistakes on the client that just weren't there before.

So what we have to do in order to make those systems adequately secure, is find a way to ignore those communication protocols and really get back to the root of, well -- what is it possible for a bad guy to do to this system? So, doing that is really all about analyzing that software and understanding what that software is capable of doing. And, you know, if I didn't put a whole lot of Web 2.0 buzzwords in there, if we haven't talked about Ajax a lot or maybe even Adobe Flash, or other sort of Web 2.0 technologies, it's because I think the fundamentals of what we've got to do with Web 2.0 are really independent of any of those technologies. And it really comes down to: is our software under our control? Do we know what it's capable of doing and what its limits are?

It sounds like fundamentally, that software just has to be tested or the bad guys are more than happy to test it for you.

And tested in such a way that you actually have confidence that you know what that software can do and what it won't do. And that's really, really important.

Tag: application security, cross-site scripting, buffer overflow, security, static source code analysis, compiler, static analysis, firewall, malware, PCI, OWASP, encryption, Web 2.0, client-side computing, Ajax, Adobe Flash

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

The folks over at CIO.com have just released the results of their Global State of Information Security survey that, while noting some critical trends, have also uncovered some security truisms that have remained remarkably consistent over the five years they've been doing the survey.

And these security truisms are:

1) Companies are 10 percent happier with their security policies than with their security spending. While 85 percent said that their security policies are in-line with the business, only 75 percent felt that about their security spending.

2) Companies are more confident in their own security than their partners: 80 to 85 percent of the companies surveyed were confident in their security policies, but that number dropped down to 70 to 75 percent when the companies were asked how confident they were in their partner’s security.

3) Very few are fully confident: less than 8 percent of respondents claimed they were 100 percent compliant with their security policies.

4) Company size does not affect security spending. When measured as a percentage of the entire IT budget, it did not matter how big a company was or how many employees it had when determining it’s security spending. What mattered was the type of industry, with technology companies typically spending the most, and nonprofits and educational institutions the least.

5) Follow the money. As I blogged yesterday, banks and financial services companies are attacked the most but suffer less. And while financial institutions have reported an increase in the frequency of attacks, they have not suffered a similar increase in losses or system downtime.

All week long I'm going to remind you to sign-up for the ebizQ Security Newsletter, where you get all the security news you need to know directly into your in-box. You can do that right here.

Tag: Security Survey, Security Budget, Security Spending

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

Wasn't it deep in the bowels of a Washington DC parking garage that Deep Throat stepped out and told Woodward and Bernstein that if they wanted to break Watergate wide open, they had to follow the money.

I think the same can be said of the security industry in terms of pinpointing the next wave of identity and access management. Because while it may be true in some industries that image is money or time is money, what is most true in banking and finance is that money is money.

So I was quite interested to read about HSBC developing a new and alternative security authentication system after concluding that the current two-factor system simply wasn’t user-friendly or safe enough.

According to Computer Weekly, HSBC’s “out of band” authentication system relies on a customer’s phone to keep their account secure. When making a payment with HSBC, a pop-up appears asking which phone number they would like to be called on and then issues an instantaneous computer generated Pin number, which the user has to punch in once the bank calls.

The current two-factor system, which is backed by Apacs, requires customers to carry a card reader, which they then have to insert their debit card into when making a payment, and which then gives an eight digit password which they have to enter when prompted. HSBC is still testing the system, and expect to roll it out within a year.

"The two-factor system works for our business customers," said personal internet banking manager Nick Staib, "because more than one employee often needs access to the business accounts. They can keep a card-reading device in a drawer. But retail banking customers do not want to carry this device around, and are likely to make transactions in various different places."

The other factor, of course, is that HSBC believes that their system will provide better security. To gain control over a card reader system, all a hacker has to do is take control of the computer. Said Staib about HSBC’s system:

"We are working on the basis that there is no way for them to take control of your phone. Plus, someone in another country cannot pretend to be you, because they are not on the end of your home phone."

I guess then the scariest thing would be, when finding out exactly where you're being hacked from, you find out the attack is coming from the computer in the DEN!!! But I guess that scenario is more the stuff of Hollywood thrillers. I hope.

All week long I'm going to keep reminding you to sign up for the ebizQ Security Newsletter, where you get all the security news you need to know directly into your in-box. You can do that right here.

Tag: Web 2.0, HSBC, Security Authentication, out of band authentication, Two Factor Authentication, Apacs,

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

I know, I know, I am guilty of hyper-inflating by writing Web 10.0, but I was watching a commercial over the weekend, I think watching another NY football team lose, and saw an IBM commercial come and, and in the commercial they referenced Web 3.0. As me and the rest of the blogosphere have been sticking with Web 2.0, my ears immediately perked up when I heard the term, and I think I might have even gasped.

Immediately I thought to myself, Web 3.0 huh…says who? Because the last time I checked with my own blog, and with all the others out there in the blogosphere, there’s pretty much unanimity with Web 2.0.

So if IBM starts saying Web 3.0, does that mean it’s true? Not necessarily. And while it may be reasonable enough to start saying Web 3.0 with the advent of web connectivity from handhelds like the iPhone, the way I see it, there is still a six hundred pound gorilla between Web 2.0 and 3.0. And that, my friends, is security.

We can shrink the internet down to a contact lens and allow blink navigation, but if the security on Web 2.0 does not improve, and by that I mean NAC controls, compliance, encryption, along with the all important application security testing, not to mention all the various facets of email security -- well, if large companies like Pfizer and TJX keep getting owned, then I’d say we’re closer to Web 0.0 then we are to 3.0.

Also, just another reminder to sign up for the ebizQ Security Newsletter, where you get all the security news you need to know directly into your in-box. You can do that right here.

Tag: Web 2.0, Web 2.0,email+security,iPhone Security,data+compliance

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

First thing, I do want to mention that, if I do say so myself, the ebizQ weekly Security Newsletter is really shaping up into a must-read document. The newsletter goes out every Monday, and has all the features, blogs, and important news you need to know. So instead of finding us, let us come to you, right into your inbox. So sign up for the Security Newsletter right here.

With Pfizer being just another example of data gone wild, it seems like a good time to cover the 5 keys to a secure database. According to Forrester Research, 80 percent of companies lack even the most basic database security plan.

Security is not just some product that you can buy off the shelf and that’s it, you’re secure. According to Noel Yuhanna, a principal analyst at Forrester Research, a secure database is a matter of process, not technology, which is why a plan is so important. Forrester recommends the following five steps, which was taken from eWeek:

1) Monitoring -- Automated monitoring tools are important because of the sheer volume of activity going on with many databases, making it impossible for someone to do it without automation.

2) Vulnerability Assessment -- Data needs to be rated according to it’s significance, and the more important it is, the better it needs to be protected. According to Forrester’s Yuhanna, “Once you classify the data, then you build a policy around it.”

3) Data Masking -- Many think you need to keep the data off the database from the very beginning. Smart users actually hide important data by overlaying false values, so the applications can continue to work normally and the important data is never exposed.

4) Encryption -- We all know how important data encryption is, but encryption still comes with what seems to be more challenges than solutions. But while encryption can be difficult to implement, encrypting key data is critical to good security practices, and also an essential element of HIPAA and PCI regulations.

5) Auditing -- Very simply, security is an ongoing process, and frequent auditing will keep a company on it’s security toes and hopefully keep it out of the data-breach news.

Tag: data breach, database, monitoring, vulnerability assessement, data masking, data audit

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

In what is hopefully not becoming a monthly occurrence, for the third time in three months Pfizer reported a serious data breach. The most recent data breach, reported last week and likely an inside job, resulted in the potential theft of vital personal information of 34,000 current and former employees of the company.

According to Dark Reading, in late June Pfizer reported the loss of around 17,000 employees’ personal information that was exposed through P2P file sharing. Then, about three weeks ago, two laptops with data on 950 employees were reported stolen from a consultant’s car in Boston.

While the first two were seemingly accidental, the most recent bore the hallmarks of an inside job. "The breach developed when a Pfizer employee wrongfully removed copies of confidential information from a Pfizer computer system late last year," the report to the state of New Hampshire says. "This was done without Pfizer's knowledge or consent, in violation of Pfizer policy."

The stolen data includes the names and Social Security numbers of the 34,000 employees exposed. Some of the data also includes home addresses, phone numbers, email addresses, credit card numbers, bank account numbers, driver's license numbers, birth dates, signatures, and reason for termination.

While Pfizer says it has found no evidence of the unauthorized use of the data, they are still looking into it, and have notified those affected and given them access to free credit protection services. The individual who pilfered the data no longer works at the company.

Tag: data breach, data theft, Pfizer, stolen data

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

As Mike Rothman over at Security Incite says, the only truly safe computer is one that is shut down and disconnected from the network. And I guess you could follow that with, the only truly trustworthy co-worker is a dead co-worker. But as we need our computers up and running and our co-workers living and engaged, enterprise security, then, is a series of compromises.

I found a recent report issued by Cyber-Ark Software (listen to my podcast with them right here) quite interesting. The report found that people trusted the temp staff, as well as cleaners, security guards, as well as the sales staff, the least in a company.

Following closely behind them were, surprisingly enough, the board of directors as well as the PR and marketing staff, each pulling in 10 percent of the respondents when asked who they trusted least in their organization.

And who are the most trusted? According to the survey, the HR staff, legal department, the boss’s secretary, and the IT department all came out on top. Really, IT the most trusted, you must be thinking. Please note, though, that the survey was conducted amongst 200 office workers, mainly IT staff.

1 in 3 of those IT staff surveyed went on to admit that they abuse their IT privileges by using admin passwords and snooping around their company’s systems. They admitted to often checking out confidential data such as private files, wage data, personal emails, and HR background.

Admitted one participant: “So I know some personal stuff about my co-workers but who cares? Sales and marketing are constantly making things up about our products. That’s so much more dangerous to our company than me knowing how much Viagra the COO ordered last month – okay it’s a bit cheeky snooping around other peoples email systems but at least I’m not lying!” He continued, “I also don’t trust the board of directors who trump up figures just to please the shareholders and just like politicians only tell us what they want us to know.”

That self-serving quote just goes to prove that, as the research at the US Department of Defense found, the number one threat to a company comes from an insider, most likely from the IT Department. I guess the new adage should be: absolute access corrupts absolutely!

That’s why it’s best a company keeps track of all insider access and keep their security compromises to a minimum.

Tag: insider access, insider abuse, insider attack

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

Found an interesting article at Intel's blog, which digs into the ever-so necessary evil of performing a risk assessment. As Brain Willis, the author of the piece, states, no one ever wakes up in the morning thinking, "What a great day, I think I’m going to do a risk assessment."

At best, risk assessments are painful, which is why it is so important to ask these three initial questions before embarking on a comprehensive risk assessment.

Question 1: Identify what question you are trying to answer. While this may seem overly simplistic, this actually is more like throwing down bread crumbs so you can find you’re way out of the thicket. A risk assessment can get very complex very fast, and the answer to this question can help keep you on to the straight and narrow path.

Question 2: What is the scope of the risk assessment? This establishes the boundaries of the risk assessment, and prevents it from being an exercise without end. So the more specific you can be in answering this question, the better, and make sure the scope is broad enough to answer to first question.

Question 3: Who should be involved in the risk assessment? This question includes incorporating the right experts and personnel so that the results are credible, but also considering the mix of personalities so that once a consensus is built, the answers are easily disseminated and adopted.

While these 3 questions might seem overly simplistic, it's worth nothing that while I've often heard of risk assessments that quickly turn bad, I've never heard of a risk assessment that starts out bad and turns good.

Tag: risk assessment, security

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