Tuesday, January 27, 2009

Some unanswered questions

In the Web security industry there is a consistent flow of current events, many of which lead to the asking of thoughtful questions. Frequently good thoughtful questions are not easy to answer, with no guaranteed they’ll ever be answered satisfactorily. I like to collect these kinds of questions, gather as much relevant information as possible, talk to people in the know, and the results of which will eventually shape my opinions on the subject. Below are a couple of things that have been I’ve been tracking. Perhaps readers her might want to share their thought as well.
  1. Do people trust QSAs who consider PCI-DSS 6.6 met if their organization only uses a network vulnerability scanner with a few web application security checks?
  2. Do organizations with a more mature software security program tend to deploy Web Application Firewalls more often than those who don't?
  3. As a result of economic downturn, what notable security projects are being cut from last years budget?
  4. Will Cross-Site Request Forgery security features be adopted through HTTP standardization, ad-hoc by Web browser vendors, or left solely up to website owners?
  5. Will secure code purchasing standards lead to secure code?

13 comments:

Anurag Agarwal said...

Do people trust QSAs who consider PCI-DSS 6.6 met if their organization only uses a network vulnerability scanner with a few web application security checks?

AA :- People will trust anything which makes them spend less money, gives them less hassle and a free get out of the jail card.

Do organizations with a more mature software security program tend to deploy Web Application Firewalls more often than those who don't?

AA :- Not necessarily. They both have different reasons though. More mature programs deploy it because they want an additional line of defense and less mature do it coz its cheaper this way.


As a result of economic downturn, what notable security projects are being cut from last years budget?

AA :- Training. Unfortunately its still considered a luxury.

Will Cross-Site Request Forgery security features be adopted through HTTP standardization, ad-hoc by Web browser vendors, or left solely up to website owners?

AA :- None of the above. It might be development frameworks who end up providing some sort of solution for this.

Will secure code purchasing standards lead to secure code?

AA :- Nope. They will do something here and there but it will never be a proper implementation of secure coding standards. Besides, why should they. Even MS Anti XSS Library had to convert to a black list filter or American Express had to make their password policy less secure to reduce the call volume.

Note: We have been asking the wrong question all the time. The real question is "When will the freakin user understand the importance of security on the internet?"

Enough rambling :)

-anurag

romain said...

Anurag: well, why the user should care about security? Shouldn't it be built-in?
Shouldn't companies care about the product they are selling?

Andre Gironda said...

romain: yes, we are alive to answer your earlier question.

anurag:

Do people trust QSAs who consider PCI-DSS 6.6 met if their organization only uses a network vulnerability scanner with a few web application security checks?

AA :- People will trust anything which makes them spend less money, gives them less hassle and a free get out of the jail card.


People didn't trust this same tactic when used as ASV -- why would that change now? QSAC's and their QSA's are under more scrutiny and the PCI SSC is establishing more quality controls for these organizations and individuals.

The focus for most QSA's for Req 6.6 is on the same stuff that 6.5 talks about: the OWASP T10-2007 along with the OWASP Guide. Did either you or Jeremiah read PCI-DSS 1.2?

Do organizations with a more mature software security program tend to deploy Web Application Firewalls more often than those who don't?

AA :- Not necessarily. They both have different reasons though. More mature programs deploy it because they want an additional line of defense and less mature do it coz its cheaper this way.


More mature organizations tend to deploy a monitoring-only WAF more often than smaller organizations, who do not often implement either a block-mode or monitor-mode WAF.

I guess this also depends on what you mean by "WAF". I think many mature organizations have the capability to enable a blocking-mode WAF, but leave it off since their pen-tests and code reviews find and fix all issues.

As a result of economic downturn, what notable security projects are being cut from last years budget?

AA :- Training. Unfortunately its still considered a luxury.


Unfortunately for Anurag, he hasn't read the PCI-DSS specification -- which mandates training in several places.

The most annoying security project that is often cut today is the risk analysis. Most organizations are so busy meeting compliance issues, that they never both to address their actual risks.

Will Cross-Site Request Forgery security features be adopted through HTTP standardization, ad-hoc by Web browser vendors, or left solely up to website owners?

AA :- None of the above. It might be development frameworks who end up providing some sort of solution for this.


It will be left solely up to the website owners.

The best way to handle CSRF is to utilize OWASP CSRFGuard or IIS AntiCSRF from Barry Dorrans, which both use a secret token. So it makes sense that it will be left to the website owners.

Will secure code purchasing standards lead to secure code?

AA :- Nope. They will do something here and there but it will never be a proper implementation of secure coding standards. Besides, why should they. Even MS Anti XSS Library had to convert to a black list filter or American Express had to make their password policy less secure to reduce the call volume.


I don't see the relation between proper secure coding standards and the AntiXSS blacklist filter, etc.

This is a loaded question like many of the others. Most of these answers are organization-specific. There is no "one-sized fits all" approach to any operational security issue, especially not application security.

This is why Anurag and Jeremiah hide behind shady blog posts surrounding their own marketing material -- because they still truly believe that they can solve the appsec problem for everyone.

The answer is that there is no "one proper secure coding standard to rule them all" and no, of course it can't be enforced by any regulations or contracts alone.

What we have today is the capability to combine VA, WAF, and SCA techniques and scale them by placing the right technology in the right hands. Give regular developers continuous integration tools that hide underlying software security features. Give lead-developers tools such as LAPSE or CAT.NET -- give them Fortify or Ounce when they can afford it. Create a centralized software security group that contains people like Michal Zalewski: application security engineers with experience -- give them the right tools such as O2, Burp Suite, ratproxy, et al -- let them make continual improvements to these tools and their own tools. Then, get these three teams working together, through self-service portals, web services, and real human interaction.

You want to write a secure software contract annex: write it around the above paragraph, not some silly Top N List.

Dr Anton Chuvakin said...

Inspired by "Do people trust QSAs who consider PCI-DSS 6.6 met if their organization only uses a network vulnerability scanner with a few web application security checks?"

I personally heard this "gem": "6.6? Yup, have a *web firewall*: our WEB site is protected by a FIREWALL"

Web site + firewall = web firewall! :-)

Rafal said...

@Jeremiah: What notable security programs are being cut? -- Security, sadly. Security budgets are being slashed from what I've seen so far this year... and most organizations, although being pushed out to the web more and more, are doing next-to-zero for web app sec. This troubles me some, as I've heard "we can't afford to do it right, so we'll hold off until things get better"... and while that may be a 'reality' answer - it just hurts to hear.

Jeremiah Grossman said...

@Anton: Re: "Web site + firewall = web firewall!"

Ahahah, thats classic!

@Rafal, the whole darn thing eh!? Eesh, that spells trouble. Fortunately for all of us I think you are wrong. The bad guys clearly aren't going to let that happen. :)

DM said...

Do people trust QSAs who consider PCI-DSS 6.6 met if their organization only uses a network vulnerability scanner with a few web application security checks?

Undoubtedly yes. Lots of organizations just don't have enough security know-how to be able to tell the difference. The real questions is why are the certified as QSAs to begin with if that's the level service being offered.

Anurag Agarwal said...

@romain - Companies will only care about it when the users will make them care about it. If i may compare it with the automobile industry, you will see companies mentioning safety features in their ad as it is important to the users. Unfortunately the same users dont think security is as important in the internet world.
Just my 2 cents.

Andre Gironda said...

Anurag: go read Geekonomics.

MikeMontecillo said...

A couple of thoughts

1. Do people trust QSAs who consider PCI-DSS 6.6 met if their organization only uses a network vulnerability scanner with a few web application security checks?

Generally speaking, YES! A large portion of organizations employ security teams (the primary decision makers revolving around PCI section 6) have backgrounds in network management or system administration. Due to that background, many of them do not understand the intricate details of how application vulnerabilities are detected and even more difficult, how they are remediated. Thus, they see the small number of vuln. findings from their already implemented network scanning solution and fail to recognize the larger issue.

2. Do organizations with a more mature software security program tend to deploy Web Application Firewalls more often than those who don't?

This is hard to say without more research but generally speaking the answer is no. Again this largely points back to the education factor. On the other hand deploying a web application firewall for a large, geographically distributed, diverse web application environment can be an expensive undertaking in terms of implementation. Beyond that this can add an additional "security bump" on the wire, which is causing some concern. On the other hand WAF's are moving and are certainly gaining traction based on the alternative of immediately trying to patch discovered web app. insecurities.

3. As a result of economic downturn, what notable security projects are being cut from last years budget?

There has been some slow down in virtualization security, training, and upgrades but overall the interesting aspect of the economic downturn is that it shows organizations that they are more vulnerable from a financial perspective, now is not the time to be vulnerable from an infrastructure perspective (meaning all IT). Thus,while overall IT budgets are decreasing, security budgets in many cases seem to be on the rise. This creates a volatile political environment for security focused IT groups. Thus, some security projects are moving forward under the guise of a broader management or performance initiatives. This makes your question difficult to answer since the project may not be gone but rather positioned differently.

The problem with this approach is that it reduces security to a "good enough" approach to larger business operations. This means that the solutions that are purchased to meet the needs as defined by the business operations focused project are not differentiated by their threat mitigation capabilities. In other words the project survives but the security initiative is abridged. If I had any guess, I would say that the organizations taking a, "good enough" approach to security will probably be hurting for a better approach within the next few years, five at most.

4. Will Cross-Site Request Forgery security features be adopted through HTTP standardization, ad-hoc by Web browser vendors, or left solely up to website owners?

Hmmm...I don't have enough background to give a real good answer to this, but I think that it would be nice to see HTTP standardization and the Web browser vendors pick up on this, thus my guess would be it will be left to website owners.

5. Will secure code purchasing standards lead to secure code?

Probably not.

JC said...

3) As a result of economic downturn, what notable security projects are being cut from last years budget?

I've seen some indication that training is being cut as well. Which as a provider of security training is painful.

4) Will Cross-Site Request Forgery security features be adopted through HTTP standardization, ad-hoc by Web browser vendors, or left solely up to website owners?

For a while I imagine the burden will fall to website owners with browser vendors eventually jumping on board. I'd love to see a more unified approach but remain skeptical.

Vinicius Cherobino said...

Hi, Jeremiah. How are you?

I'm Vinicius Cherobino from Computerworld Brazil.

I'm interested in doing an interview with you about clickjacking and other hot security topics.

There is any e-mail that I can send the questions to you?

Best Regards,
Vinicius

vcherobino@nowdigital.com.br

bachrach44 said...

This is a late response, but better late than never I suppose. I used to work for one of those large firms that employed many QSAs to do PCI work for our clients. Talking to our clients, I realized that most people did not consider PCI something that needed to be fulfilled in spirit, but rather in name only. They didn't care if they really did everything they were supposed to, or if we looked thoroughly into everything, as long as they got the stamp at the end. Because we actually did try to fulfill the requirements and not just turn into a certificate factory, we actually lost some clients and a lot of potential clients. (We also cost more because of that). Look at who does the most PCI assessment *cough*amberon*cough* and you'll realize that they're the ones that do the least invasive testing, don't bother verifying much of the information provided by the client, and do the minimum amount necessary to fulfill the external scan and web assessment requirements.