While preparing for the big Web seminar next week on “Hacking 101 for Management – How Hackers Attack your Website”, I came across this amazing Clickjacking video. 

It’s the best one I’ve seen that shows how you can unknowingly grant someone full access to your Webcam and microphone.  Hackers now have the potential to turn every browser into a surveillance zombie. 

Want to learn more about Clickjacking?  See the bullets points below for a brief summary.  They will be discussed in further detail at our Web seminar event next Thursday.  Sign up today.

Clickjacking Overview

• What is it?:  Attackers trick victims into unknowingly clicking and invoking unwanted requests / transactions.
• Root Cause:  Various current browser short-comings (IFRAME behavior) and plug-in vulnerabilities.
• Impact:  Attackers let the victim execute unwanted requests/transactions for them, rather than having to find and exploit existing Web app vulnerabilities.  This can result in a broad variety of possible exploits.
• Solution:  Due to the broad nature of different Clickjacking attack variants, a number of different remediation steps should be considered, such as “frame busting” code, CSRF remediation steps, and the temporary stop of vulnerable plug-ins until fixed versions become available.

by
Lars Ewe, CTO
Lars@cenzic.com

According to some recent data by Forrester, the potential costs of a Web application breach add up quickly.  The research firm estimates that the cost of a security breach ranges from about $90 to $305 per compromised record.  And when you consider the expense of the forensic analysis of compromised systems, increased call center activity from upset customers, legal fees and regulatory fines, data breach disclosure notices sent to affected customers, as well as other business and customer losses, it's no surprise that news reports often detail incidents costing anywhere from $20 million to $4.5 billion.

And those estimates don’t count the other, indirect costs that result from shoddy Web application security such as:  the inability to conduct business during denial-of-service attacks, crashed applications, reduced performance, and the potential loss of intellectual property to competitors.

So take a few lessons from companies like Forever 21, TJMaxx, and Guess.com and be proactive about your Web security posture.

by
Jon Zucker, Product Management
JZucker@cenzic.com

Cenzic is proud to interview Jerry Dixon as part of their Myth Busters series on application security.  This is the third of six pod cast interviews conducted on the show floor at the 2008 BlackHat Conference in Las Vegas.

Mr. Dixon is the VP of Government Relations at Infragard and the former head of Cybersecurity for the Department of Homeland Security.  Cenzic’s Chief Marketing Officer, Mandeep Khera, asks Jerry a series of questions about the application security landscape, why there’s been so little action taken to become more secure, and the myth about thinking you are secure simply because you haven’t been hacked.   

So listen to this 10 minute pod cast, as one of my favorite things Jerry says in regards to Web application security is:  “Pay for me now” or “Pay MORE for me later” – meaning you must invest in a sound security posture today or the ramifications could be in the millions of dollars tomorrow.

If you have any other questions or topic suggestions about the latest myths out there, send an email to:  mythbusters@cenzic.com

by
Erin Swanson, Marketing
Eswanson@cenzic.com

According to the recent article, “Why do Bad Things Happen to PCI-Compliant Companies?” you can’t assume your data is perfectly safe and secure just because you have PCI compliance. 

This hard lesson was recently learned by retail clothing company Forever 21, as they suffered a breach involving 98,000 credit cards at the time they were PCI compliant. 

So what can you do to better ensure the safety of your data?  According to industry experts, IT professions and employees need to maintain constant vigilance of their compliance status.  A company can be PCI compliant today but fall out of compliance the next week. 

That means to consistently test and re-test applications to know which ones are most vulnerable to hacker attacks.

by
Mandeep Khera, CMO
Mandeep@cenzic.com

The Comptroller of the Currency Administrator of National Banks (OCC) issued a bulletin to all national banks, and their technology service providers that application security is an important component of their information security program.  The OCC Bulletin 2008-16 was issued in May of this year.  Although it's been over 5 months since the bulletin was issued, there hasn't been a mad rush from the banks to secure their Web applications.  But, in all fairness, they have had other things on their minds.

I wanted to recap the bulletin so we don't lose sight of the importance of application security.  The bulletin made a good effort to raise awareness about securing Web applications.  It highlights reasons why Web-based applications are being targeted including: 

• The numerous vulnerabilities in Web applications,
• The openness of the Web, and
• The fact that network devices like firewalls and IDSs are not effective against Web application layer attacks.

The bulletin asks the banks to ensure that all applications are developed and maintained in a manner that appropriately addresses risks to the confidentiality, availability, and integrity of data.  Banks should look at various factors such as accessibility of the application via the Internet, whether the application is built in-house or purchased, secure practices in the application development process, and others.

I was pleased to see an explanation around purchased or commercial applications.  The bulletin correctly points out that even though banks have to rely on the software vendors to provide secure applications, bank management remains responsible to make sure that the customer and employee information is secure.

Although this is a nicely written bulletin with some real good advice, we need a much stronger regulation making application security mandatory.  We have seen a lot more financial institutions in the last few months using our solution to automate their security assessment and actively secure their Web applications.  However, we know that there are hundreds of other companies who haven't even started thinking of application security. Given that most attacks are occurring through the Web sites, and customer information is being stolen every day, it's mind boggling to see that companies and regulators are not taking this issue seriously enough. What would it take to get companies to get off the dime and do something?  

If we learned anything from the recent  credit market collapse that prompted painful actions after the damage was done is that it's much better to be proactive than wait for a catastrophe to happen.  I hope companies and regulators don't wait for a catastrophe when it comes to protecting our Web infrastructure because that could be really devastating.

by
Mandeep Khera, Chief Marketing Officer
Mandeep@cenzic.com

As October is Cyber Security Awareness Month, I wanted to highlight this article by Lorna Hutcheson on the top 10 signs you might be hacked (and not even know about it).  Most company networks and Web applications are under attack without anyone knowing about it for years such as the infamous TJ Maxx breach. 

Why do hackers remain silent rather than promoting their conquests and attacks to the world like they used to 10 years ago?  Very simple:  money.  Hackers can make millions of dollars with their expertise and they’d rather cash in on the big dollars rather than gain the notoriety and peer recognition. 

So what are some of the signs you might be compromised?  The following can be big clues if gone unchecked:     

1. Your logging server hasn't logged any events or you haven't received alerts in the last 12 hours 
2. Your FTP server/user hard drives etc. are suddenly out of disk space or maybe logs increase in size more than your normal variation 
3. Your competition's products looks just like yours, but have a prettier color scheme 
4. Your customers start receiving spam on email addresses they used only to sign up for your service 
5. You get machine acts "funny" report from users (i.e. windows closing by themselves, browser homepage changed, etc.) 
6. Someone needs help connecting to the company's wireless access point, you don't have a wireless access point 
7. Complaints that software (payment processing software, Web browser, etc) keeps crashing 
8. Complaints from user(s) that passwords/logins aren't working 
9. Computer systems running unusually slow 
10. Visitors to your Website complain that they get redirected to another site or one that just doesn't "look" right

by
Erin Swanson
ESwanson@cenzic.com

Cenzic is proud to interview Marcus Sachs as part of their Myth Busters series on application security.  This is the second of six pod cast interviews conducted on the show floor at the 2008 BlackHat Conference in Las Vegas.

Mr. Sachs volunteers as the Director of the SANS Internet Storm Center and is currently the Executive Director of Government Affairs for National Security Policy at Verizon in Washington, D.C.  In 2007 Sachs was named a member of the Commission on Cyber Security for the 44th Presidency.  Cenzic’s Chief Marketing Officer, Mandeep Khera, asks Marcus a series of questions about the application security landscape, why adoption of app security tools isn’t higher, and the drivers in this market. 

One of the many points Mr. Sachs makes in this 9 minute podcast, is that application security can’t be ignored -- and SSL and firewall technology won’t fully protect your information against hacker attacks.  The hacker community, who used to promote their conquests and attacks to the world 10 years ago has evolved to a subversive, quiet underworld.  Their goal now is to stay silent, as they make millions of dollars for their expertise. 

So how do you know if you’ve been hacked?  No one will tell you until you stumble upon a huge breach and the money is long gone. 

If you have any other questions or topic suggestions about the latest myths out there, send an email to:  mythbusters@cenzic.com

by
Erin Swanson, Marketing
Eswanson@cenzic.com

PCI Security Standards Council issued the much-anticipated Payment Card Industry Data Security Standard (PCI DSS) requirements version 1.2 today.

No big news compared to the rejection of the house bill for $700B economic bail-out on Monday. Actually, no big news at all.  The new version includes a lot of clarifications on the existing 12 requirements but no major changes.

There's an additional emphasis on wireless security, which makes sense given the recent breaches at the wireless network level.  An explanation has been added for network segmentation to focus only on the network that contains the card holder data. Although certainly more practical, I am not sure if it's such a good idea.  It's like protecting your bedroom by putting separate locks on it but leaving the living room, family room, and other rooms open.  Hackers know how to get in from one point of the network and go to the other parts that contain the real stuff.  There is also an additional explanation on 3rd parties/outsourcing which is a great idea. We live in the outsourcing world and we have to hold those 3rd parties responsible - whether they are there for network infrastructure or Web applications.

I really liked the instructions and content for report on compliance.  It gives the merchants and service providers specific instructions and template to use to report on their compliance.  Additional columns for testing procedures and whether something is in place or not is also a nice way to help people go through the process.

Most of the 12 requirements have just been clarified with no major changes.  The infamous and critical section 6 is pretty much the same as before.

Section 6.6 that focuses on Web application re-confirms the requirement is mandatory (PCI council had confirmed this a few months ago in its clarification of version 1.1).  I don't quite agree with the way this section has been worded. You can either have a review (manual or automated) of your applications or have an application firewall. Every one knows that throwing an app firewall in an environment isn't going to solve the problem.  The good guys might get blocked and the bad guys might still get in.  These two have to go together.

Here's what I think they should have in the standard:

1. Make sure you test all your Web applications - new ones, the ones that are going through maintenance, and the ones in production (some of this is covered in section 6.3 of the PCI standard as well as 11.3.2);
2. Prioritize these vulnerabilities based on their criticality based on a quantitative score;
3. Fix the high priority vulnerabilities within 3 months;
4. For the vulnerabilities you can't fix, use an app firewall and configure it based on the known vulnerabilities identified in step 1.

Also, many companies I've talked to are still confused about the penalties and how this the requirements are being enforced.  Some information on that in the standard would have been useful as well.

Overall, I think it's a good step forward.  More clarification, better templates, and explanation of the process flow, can only help.  All I can say is that we still have a long way to go.  I look forward to working with the PCI Council to continue to make this standard simpler and better.
 
by
Mandeep Khera, Chief Marketing Officer
Mandeep@cenzic.com