This Thursday I’ll be giving a webcast for Core Security on Integrating Web Applications into Your Vulnerability Management Program.

You can register for it over here at WhiteHatWorld.com, and here’s the description:

Along with end-user systems, web applications often present the “weakest link” to attackers targeting sensitive data. However, while many security professionals conduct endpoint vulnerability assessments, fewer adequately manage their web application vulnerabilities.

Please join Core Security and Rich Mogull, founder of Securosis and former Gartner analyst, for a discussion of how to proactively assess your web applications against data breach threats.

You’ll learn:

• Which web-based attacks are posing the greatest risks to organizations today.
• When and where to integrate web apps into your broader vulnerability assessments.
• Why static analysis can miss critical exposures – and how you can fill the gaps.

It’s no surprise that I’m a big fan of Microsoft’s Trustworthy Computing Initiative- something I was skeptical of when it was first announced. MS proved me wrong, and years later we’ve seen a very positive impact. Vulnerabilities are down, response times are up, and products ship in more secure configurations. Yes, they still screw up every now and then, but it’s overall been a huge improvement. Just because I don’t like to use Vista doesn’t mean I don’t appreciate all the security work that went into it, and let’s not forget all the benefits across the rest of the product line. Go count SQL Server 2005 vulnerabilities if you want any proof. You’ll only need one hand, and you’ll have 4 fingers left over (5, if you really look where the vuln came from).

If MS buys Yahoo! and implements TCI, the impact could be enormous. Google isn’t doing a very good job of managing security issues, and if these things hit a certain point they could affect user behavior.

Realistically it will take 3-5 years for the full implications of TCI to affect any product line, but we’ll see incremental improvements fairly quickly. Yahoo!’s security track record isn’t all that bad to start with, and I much prefer their privacy policy over Google’s.

Should Microsoft! use security for competitive advantage (and it work), we can expect Google to respond fairly quickly. They aren’t stupid, and if security affects business they will get on the ball immediately.

None of this, of course, will come to pass if market forces don’t place a priority on security. It doesn’t even need to be a top priority, just somewhere moderately high on the list. There could also be peripheral benefits to a major Web 2.0 company building the tools, techniques, and education for secure coding.

My guess? Nothing earth shattering, but if the deal goes through there will be a net security benefit substantial enough that we’ll all be referring back to it in our blog posts in 5 years.

Technorati Tags: Application security, Microsoft, Yahoo!

While I was traveling home, Martin posted the latest episode of the Network Security Podcast. Our guests this week are Marcin and Andre from http://www.tssci-security.com/. We spend most of the episode talking about web application security issues.

At least, I think we do. Due to technical difficulties related to my travel I got booted half-way through the podcast just as Andre was getting into the good stuff.

Sorry for the problems guys, and thanks again for being on the show. And for getting me drunk and talking me into inviting you on the show. And having me pay the tab.

Um. I think I’m doing this wrong…

Technorati Tags: Application security, Podcast

More on this later, but I’m starting to see the data security market splitting along two lines. One focused on protecting content in user workspaces and productivity applications. It’s starting with DLP but moving towards what I call Content Monitoring and Protection.

On the other side of data security is protecting content in business applications- from your web application stack to internal applications and databases. I’m starting to call this Application and Database Monitoring and Protection, and Database Activity Monitoring is where it’s starting.

Since we need definitions, here’s my first stab for ADMP:

Products that monitor all activity in a business application and database, identify and audit users and content, and, based on central policies, protect data based on content, context, and/or activity.

For CMP, I’m sticking with my DLP definition (DLP is a terrible term, but I’m not going to fight the market):

Products that, based on central policies, identify, monitor, and protect data at rest, in motion, and in use through deep content analysis.

Looks like the ipfw rules project that Chris is leading is pretty popular. We’ve set up a permanent link that we’ll redirect to the latest version as we keep refining this thing.

You can find it here.

Thanks again to everyone who has helped on this project:

windexh8er: http://www.slash32.com/
Rob
Lee: http://thnetos.wordpress.com/
Josh
Chris Pepper http://www.extrapepperoni.com/

Based on extensive feedback, these rules are now much improved over the initial draft. Thanks, all!

All the versions of this post are getting out of hand, so Rich has provided a permanent URL for the current Leopard ipfw post for future reference. Please use that link, so future visitors get the latest and greatest.

Chris

# DO NOT USE THESE RULES without customizing them first!
# Version: 2007/12/12

# For more information, see http://securosis.com/2007/11/15/ipfw-rules/
# & http://securosis.com/2007/11/16/ipfw-rules-20071116-revision/#comments

# These rules *MUST* be customized to your requirements.
# In particular, if you have a private home network (behind an AirPort
# Base Station, Linksys WRT54G, etc.), change “10.42.24.0/24″ below to
# your private network range; duplicate rules with different ranges, if use use this computer on multiple networks.
# Additionally, allow only ports you actually use; block unused ports.

# Thanks to:
# Rich Mogull http://securosis.com
# windexh8er: http://www.slash32.com/
# Rob
# Lee: http://thnetos.wordpress.com/
# Josh
# Chris Pepper http://www.extrapepperoni.com/
# Apple (Server Admin is a good way to create an ipfw ruleset)
# http://www.apple.com/server/macosx/
# FreeBSD (where Apple got ipfw) http://www.freebsd.org/

# We don’t really want this, but it’s unavoidable on Mac OS X Server, so
# document it here (serialnumberd).
# 100 allow udp from any 626 to any dst-port 626

# Let me talk to myself over the loopback.
add 200 allow ip from any to any via lo0

# Loopback traffic on a ‘real’ interface is bogus.
add 300 deny log logamount 1000 ip from any to 127.0.0.0/8

# Block multicast unless you need it.
# add 400 deny log logamount 1000 ip from 224.0.0.0/4 to any in

# If we let a conversation begin, let it continue.
# Let my clients go!
add 500 allow tcp from any to any out keep-state
add 510 allow udp from any to any out keep-state
# Block replies, if we don’t recall initiating the conversation.
add 520 deny log tcp from any to any established in

# Allow DHCP responses (keep-state can’t handle DHCP broadcasts).
add 600 allow udp from any to any src-port 67 dst-port 68 in

# Do you never need fragmented packets?
# add 700 deny udp from any to any in frag

# Let yourself ping.
# add 1000 allow icmp from 10.42.24.0/24 to any icmptypes 8

# Server Admin provides these by default.
add 1100 allow icmp from any to any icmptypes 0
add 1110 allow igmp from any to any

# mDNS (Bonjour) from trusted local networks (fill in your own,
# preferably non-standard, networks after ‘from’).
# For Back to My Mac, you might need this from ‘any’.
# add 5000 allow udp from 10.42.24.0/24 to any dst-port 5353
# add 5010 allow udp from 10.42.24.0/24 5353 to any dst-port 1024-65535 in

# ssh — should be restricted to trusted networks if at all possible; if
# open to the Internet, make sure you don’t have “PermitRootLogin yes”
# in sshd_config (at least use
# PermitRootLogin without-password“, please!)
add 5200 allow tcp from any to any dst-port 22

# iTunes music sharing
# add 5300 allow tcp from 10.42.24.0/24 to any dst-port 3689

# AFP
# add 5400 allow tcp from 10.42.24.0/24 to any dst-port 548

# HTTP (Apache); HTTPS
# add 5500 allow tcp from any to any dst-port 80
# add 5510 allow tcp from any to any dst-port 443

# L2TP VPN — is this complete?
# add 5600 allow udp from any to any dst-port 1701
# add 5610 allow esp from any to any
# add 5620 allow udp from any to any dst-port 500
# add 5630 allow udp from any to any dst-port 4500

# iChat: local
# add 5700 allow tcp from 10.42.24.0/24 to any dst-port 5298
# add 5710 allow udp from 10.42.24.0/24 to any dst-port 5298
# add 5720 allow udp from 10.42.24.0/24 to any dst-port 5297,5678

# Server Admin SSL (Mac OS X Server only)
# add 5800 allow tcp from 10.42.24.0/24 to any dst-port 311
# add 5810 allow tcp from 10.42.24.0/24 to any dst-port 427
# add 5820 allow udp from 10.42.24.0/24 to any dst-port 427

# syslog — uncommon
# add 5900 allow udp from 10.42.24.0/24 to any dst-port 514

# ipp (CUPS printing)
# add 6000 allow tcp from 10.42.24.0/24 to any dst-port 631

# MTU discovery
add 10000 allow icmp from any to any icmptypes 3

# Source quench
add 10100 allow icmp from any to any icmptypes 4

# Ping out; accept ping answers.
add 10200 allow icmp from any to any icmptypes 8 out
add 10210 allow icmp from any to any icmptypes 0 in

# Allow outbound traceroute.
add 10300 allow icmp from any to any icmptypes 11 in

# My default policy: log and drop anything that hasn’t matched an allow
# rule above
add 65534 deny log logamount 1000 ip from any to any

# Hard-coded default allow rule (compiled into Darwin kernel)
add 65535 allow ip from any to any

I’m working on a project where I’m having to codify some of my thoughts on the rise of the data security markets, and I’m lumping in application security since I consider the line between those two disciplines far grayer than we usually admit.

This is one of those great projects where I get to reuse a lot of material I’ve already posted (like the Data Security Lifecycle), and finally codify some things I’ve been talking and thinking about that I haven’t had the time to post yet.

Here’s the introduction; designed to explain the rising importance of data security markets to a business audience. The last line is a prediction I’ll highlight for the attention-deficit crowd:

Data and business application security will drive most of the new growth of the security market over the next 3-5 years.

Nothing Earth-shattering, and probably common sense to many of you, but you might find this good fodder to help explain the rise of data security to your non-security folks. At some point I need to convert some of this into real numbers, if I can.

The Rise Of Data Security

Over the past few years we’ve seen a dramatic shift in the electronic threats faced by business and government, but only minor shifts in how organizations protect themselves. In the early days of the Internet, most attackers were mere experimenters or vandals, exploring connected systems and leaving behind the virtual equivalent of graffiti. The most damaging attacks tended to be worms or viruses that disrupted the ability to do business without materially affecting enterprise assets on the back end. The information security industry responded with tools focused on easing this immediate pain, securing the electronic perimeter and filtering out this bad traffic. The practice of “Information security” degraded to mere “network security” with a dash of “host security”. Products such as firewalls, IDS, and antivirus came to dominate the security market. This was a logical response to the disruptive risks at the time- attackers focused on damage and disruption using the network as the primary avenue of attack, and the industry responded with tools and technologies to keep systems running and carry out business.

Beginning around five years ago the main threats began developing away from the attacks of the 1990s and focusing on profitable crime as opposed to mindless vandalism, but our approach to security failed to respond in kind. True, profitable cybercrime always existed, but it only became more common than experimentation and vandalism relatively recently. This is a natural evolution driven by three factors:

1. Increased skill among attackers and a sufficient talent pool of technically proficient individuals willing to break the law.
2. A growing volume of financially valuable data online- primarily personal data and corporate intellectual property.
3. Development of criminal markets to facilitate conversion of this data to money.

Bad guys now have effective skills, something to steal, and a place to sell it.

Most of this crime occurs under the covers, outside the public eye. In many cases it’s because enterprises lack the fundamental capability to detect these attacks. In other cases, as opposed to a business outage that’s difficult to hide, organizations see no reason to publicize that they’ve become victims of crime, potentially putting their partners and customers at risk.

Network security is very successful at limiting the risks it was developed for, but the environment has changed, and new tools and techniques are needed.

These failures have been highlighted over the past 2 years by a combination of regulatory changes and a series of dramatic breaches. Since the passing of the California breach notification law in 2003 (SB 1386) there have been hundreds of reported disclosures of private information- over 500 in 2006 and 2007. The Sarbanes-Oxley act in the United States and similar laws in other nations have highlighted the importance of securing corporate financial data. The Payment Card Industry Data Security Standard (PCI-DSS) requires companies to better protect credit card data to limit financial fraud. Over 34 U.S. states and Japan have passed breach notification laws similar to California’s, with more nations expected to follow (Australia is in active debate). Other notable laws (mostly in the US) include HIPAA for healthcare, and the Gramm-Leach-Bliley Act for financial services. On the breach front, companies such as SAP and Oracle are ensnared in major industrial espionage lawsuits (Oracle vs. SAP) and nary a day passes without a new headline of supposed Chinese hackers stealing state and industrial secrets from western nations.

The combination of the increase in cybercrime, changing regulations, and public exposures is increasing the attention and resources dedicated to data security. Over the next three years it’s expected that data security issues (and the related application security) will account for over 60% of new enterprise security spending- this includes spending on new technologies, and excludes maintenance of existing technologies such as firewalls and antivirus, which account for most current security costs. Data and business application security will drive most of the new growth of the security market over the next 3-5 years.

Thanks to the feedback, I’ve tweaked these rules a bit. I realized I was blocking DHCP, so I added that as well.

Get the latest rule set.

Chris

# DO NOT USE THESE RULES without customizing them first!
# Version: 2007/11/16

# For more information, see http://securosis.com/2007/11/15/ipfw-rules/

# These rules *MUST* be customized to your requirements.
# In particular, if you have a private home network (behind an AirPort
# Base Station, Linksys WRT54G, etc.), change “10.42.24.0/24″ below to
# your private network range.
# Additionally, allow only ports you actually use; other ports should be
# blocked by the ipfw firewall.

# Thanks to:
# Rich Mogull http://securosis.com
# windexh8er: http://www.slash32.com/
# Lee: http://thnetos.wordpress.com/
# Chris Pepper http://www.extrapepperoni.com/
# Apple (Server Admin is a good way to create an ipfw ruleset)
# http://www.apple.com/server/macosx/
# FreeBSD (where Apple got ipfw) http://www.freebsd.org/

# We don’t really want this, but it’s unavoidable on Mac OS X Server, so
# document it here (serialnumberd).
# 100 allow udp from any 626 to any dst-port 626

# Let me talk to myself over the loopback.
add 200 allow ip from any to any via lo0

# Loopback addresses on non-loopback interfaces are bogus.
add 300 deny log logamount 1000 ip from any to 127.0.0.0/8
add 310 deny log logamount 1000 ip from 224.0.0.0/4 to any in

# Block multicast if you don’t use it.
# add 400 deny log ip from 224.0.0.0/4 to any in

# Accept responses to my client programs.
add 500 check-state

# If we let the conversation begin, let it continue.
add 600 allow tcp from any to any established
# Let my programs go!
add 610 allow tcp from any to any out keep-state
add 620 allow udp from any to any out keep-state
# Block bogus inbounds that claim they were established.
# add 630 deny log tcp from any to any established in

# Change this to DENY fragments if you don’t need them.
add 700 allow udp from any to any in frag

# Allow DHCP responses (DHCP broadcasts, which seems to defeat
# keep-state).
add 800 allow udp from any to any src-port 67 dst-port 68 in

# add 1000 allow icmp from 10.9.7.0/24 to any icmptypes 8

# Server Admin provides these by default.
add 1100 allow icmp from any to any icmptypes 0
add 1110 allow igmp from any to any

# mDNS (Bonjour) from trusted local networks (fill in your own,
# preferably non-standard, networks after ‘from’).
# For Back to My Mac, you might need this from ‘any’.
# add 5000 allow udp from 10.42.24.0/24 to any dst-port 5353
# add 5010 allow udp from 10.42.24.0/24 5353 to any dst-port 1024-65535 in

# DNS (note TCP is required, but this one should scare you — much
# better to only allow packets from your trusted nameservers, if you
# always use the same ones).
add 5100 allow tcp from any to any dst-port 53
add 5110 allow udp from any to any dst-port 53
add 5120 allow tcp from any to any dst-port 53 out keep-state
add 5130 allow udp from any to any dst-port 53 out keep-state

# ssh
add 5200 allow tcp from any to any dst-port 22

# iTunes music sharing
# add 5300 allow tcp from 10.42.24.0/24 to any dst-port 3689

# AFP
# add 5400 allow tcp from 10.42.24.0/24 to any dst-port 548

# HTTP (Apache); HTTPS
# add 5500 allow tcp from any to any dst-port 80
# add 5510 allow tcp from any to any dst-port 443

# L2TP VPN
# add 5600 allow udp from any to any dst-port 1701
# add 5610 allow esp from any to any
# add 5620 allow udp from any to any dst-port 500
# add 5630 allow udp from any to any dst-port 4500

# iChat: local
# add 5700 allow tcp from 10.42.24.0/24 to any dst-port 5298
# add 5710 allow udp from 10.42.24.0/24 to any dst-port 5298
# add 5720 allow udp from 10.42.24.0/24 to any dst-port 5297,5678

# Server Admin SSL (Mac OS X Server only)
# add 5800 allow tcp from 10.42.24.0/24 to any dst-port 311
# add 5810 allow tcp from 10.42.24.0/24 to any dst-port 427
# add 5820 allow udp from 10.42.24.0/24 to any dst-port 427

# syslog
# add 5900 allow udp from 10.42.24.0/24 to any dst-port 514

# ipp (CUPS printing)
# add 6000 allow tcp from 10.42.24.0/24 to any dst-port 631

# MTU discovery
add 10000 allow icmp from any to any icmptypes 3

# Source quench
add 10100 allow icmp from any to any icmptypes 4

# Ping out; accept ping answers.
add 10200 allow icmp from any to any icmptypes 8 out
add 10210 allow icmp from any to any icmptypes 0 in

# Allow me to traceroute.
add 10300 allow icmp from any to any icmptypes 11 in

# My default policy: log and drop anything that hasn’t matched an allow
# rule above
add 65534 deny log logamount 1000 ip from any to any

# Hard-coded default allow rule (compiled into Darwin kernel)
add 65535 allow ip from any to any

Rules revised.

As suggested by windexh8er, here’s a set of ipfw rules to customize for your own Macs or FreeBSD systems. Note that your private home network should have a non-standard IP range, both to support VPN across standard IP ranges, and for improved security, so your personal allow rules don’t match other networks you may find yourself wandering through.

The rules are below, but you’ll probably have an easier time if you download the rule file from http://securosis.com/wp-content/uploads/2007/11/ipfw-securosis.txt.

In WaterRoof, you can import these rules with “Tools > Rules Configuration > Import rules from file..”. To check your ipfw rules, use “sudo ipfw list“. When you’re satisfied with your rules, install them for future reboots with “Tools > Rules Configuration > Save to startup configuration” and “Tools > Startup Script > Install Startup Script”.

# DO NOT USE THESE RULES without customizing them first!
# Version: 2007/11/15

# For more information, see http://securosis.com/2007/11/15/ipfw-rules/

# These rules *MUST* be customized to your requirements.
# In particular, if you have a private home network (behind an AirPort
# Base Station, Linksys WRT54G, etc.), change "10.42.24.0/24" below to
# your private network range.
# Additionally, allow only ports you actually use; other ports should be
# blocked by the ipfw firewall.

# Thanks to:
# Rich Mogull http://securosis.com
# windexh8er: http://www.slash32.com/
# Lee: http://thnetos.wordpress.com/
# Chris Pepper http://www.extrapepperoni.com/
# Apple (Server Admin is a good way to create an ipfw ruleset)
#   http://www.apple.com/server/macosx/
# FreeBSD (where Apple got ipfw) http://www.freebsd.org/

# We don't really want this, but it's unavoidable on Mac OS X Server, so
# document it here (serialnumberd)
# 100 allow udp from any 626 to any dst-port 626 

# Let me talk to myself over the loopback
add 200 allow ip from any to any via lo0 

# Loopback addresses on non-loopback interfaces are bogus
add 300 deny log logamount 1000 ip from any to 127.0.0.0/8
add 310 deny log logamount 1000 ip from 224.0.0.0/4 to any in 

# Block multicast if you don't use it
# add 400 deny log ip from 224.0.0.0/4 to any in 

# Accept responses to my client programs
add 500 check-state 

# If we let the conversation begin, let it continue
add 600 allow tcp from any to any established 

# Let my programs get out.
add 700 allow tcp from any to any out keep-state
add 710 allow udp from any to any out keep-state 

# Change this to DENY fragments if you don't need them.
add 800 allow udp from any to any in frag 

# Block bogus inbounds that claim they were established
# add 900 deny log tcp from any to any established in 

# add 1000 allow icmp from 10.9.7.0/24 to any icmptypes 8 

# Server Admin provides these by default
add 1100 allow icmp from any to any icmptypes 0
add 1110 allow igmp from any to any 

# mDNS (Bonjour) from trusted local networks (fill in your own,
# preferably non-standard, networks after 'from')
# For Back to My Mac, you might need this from 'any'
# add 5000 allow udp from 10.42.24.0/24 to any dst-port 5353
# add 5010 allow udp from 10.42.24.0/24 5353 to any dst-port 1024-65535 in

# DNS (note TCP is required, but this one should scare you -- much
# better to only allow packets from your trusted nameservers, if you
# always use the same ones)
add 5100 allow tcp from any to any dst-port 53
add 5110 allow udp from any to any dst-port 53
add 5120 allow tcp from any to any dst-port 53 out keep-state
add 5130 allow udp from any to any dst-port 53 out keep-state 

# ssh
add 5200 allow tcp from any to any dst-port 22 

# iTunes music sharing
#add 5300 allow tcp from 10.42.24.0/24 to any dst-port 3689 

# AFP
#add 5400 allow tcp from 10.42.24.0/24 to any dst-port 548 

# HTTP (Apache); HTTPS
# add 5500 allow tcp from any to any dst-port 80
# add 5510 allow tcp from any to any dst-port 443 

# L2TP VPN
# add 5600 allow udp from any to any dst-port 1701
# add 5610 allow esp from any to any
# add 5620 allow udp from any to any dst-port 500
# add 5630 allow udp from any to any dst-port 4500 

# iChat: local
#add 5700 allow tcp from 10.42.24.0/24 to any dst-port 5298
#add 5710 allow udp from 10.42.24.0/24 to any dst-port 5298
#add 5720 allow udp from 10.42.24.0/24 to any dst-port 5297,5678 

# Server Admin SSL (Mac OS X Server only)
# add 5800 allow tcp from 10.42.24.0/24 to any dst-port 311
# add 5810 allow tcp from 10.42.24.0/24 to any dst-port 427
# add 5820 allow udp from 10.42.24.0/24 to any dst-port 427 

# syslog
# add 5900 allow udp from 10.42.24.0/24 to any dst-port 514 

# ipp (CUPS printing) 

# add 6000 allow tcp from 10.42.24.0/24 to any dst-port 631 

# MTU discovery
add 10000 allow icmp from any to any icmptypes 3 

# Source quench
add 10100 allow icmp from any to any icmptypes 4 

# Ping out; accept ping answers
add 10200 allow icmp from any to any icmptypes 8 out
add 10210 allow icmp from any to any icmptypes 0 in 

# Allow me to traceroute
add 10300 allow icmp from any to any icmptypes 11 in 

# My default policy: log and drop anything that hasn't matched an allow
# rule above
add 65534 deny log logamount 1000 ip from any to any

# Hard-coded default allow rule (compiled into Darwin kernel)
add 65535 allow ip from any to any

Jeremiah posted these questions on dealing with website vulnerabilities. Here are my quick answers (I have to run- sorry for the lack of links, but you can Google the examples):

Lets assume a company is informed of a SQLi or XSS vulnerability in their website (I know, shocker) either privately or via public disclosure on sla.ckers.org. And that vulnerability potentially places private personal information (PPI) or intellectual property at risk of compromise. My questions are:

1) Is the company “legally” obligated to fix the issue or can they just accept the risk? Think SOX, GLBA, HIPAA, PCI-DSS, etc.

Definitely no for intellectual property. Definitely no for SOX- SOX says you’re free to make as many dumb mistakes and lose as much money as you want, as long as you report it accurately. Other laws are a toss-up, but generally there is no obligation unless there is evidence that a breach occurred. For PCI-DSS you have to remediate or document compensating controls for any network vulnerabilities at the time of your audit (and this expands to applications with 1.1), but there is no definitive requirement for immediate remediation. California AB1950 is the big question mark in this area and I’m unsure on enforcement mechanisms.

The regulations are very unclear and unhelpful here, and it’s quite likely a company can accept the risk. But if a breach occurs, they may be held negligent. Take a look at the PetCo case where the FTC mandated a security program after a breach, and Microsoft/MSN. The companies were held liable for losing customer data, but not because of any of the usual regulations.

There is almost no case law that I’m aware of.

2) What if repairs require a significant time/money investment? Is there a resolution grace period, does the company have to install compensating controls, or must they shutdown the website while repairs are made?

No. Most regulations only require breach notification or remediation of flaws discovered through auditing. Reasonable person theory probably applies if there is a breach with losses and it goes to court. I’ve read all of the regulations- none mention a specific time period.

3) Should an incident occur exploiting the aforementioned vulnerability, does the company bear any additional legal liability?

They may carry liability due to negligence. See the cases I mentioned above.

4) If the company’s website is PCI-DSS certified, is the website still be considered certified after the point of disclosure given what the web application security sections dictate?

Unknown because there are no public cases that I can find. I believe you remain certified until the next audit. In the case of Cardsystems, they were PCI certified when the breach occurred and immediately re-audited and de-certified following public disclosure of the breach. That’s one problem with PCI-DSS- it’s very audit-reliant and changes between audits don’t directly affect certification.

5) Does the QSA or ASV who certified the website potentially risk any PCI Council disciplinary action for certifying a non-compliant website? What happens if this becomes a pattern?

No known cases of disciplinary action, but an audit insider might know of one. Disciplinary action will most likely only take place if the audit failed to follow best practices and a large breach occurs, or if there is (as you mention) a pattern. None of this is formalized to my knowledge.

I’ve spent a lot of time researching and discussing all the various data protection and breach disclosure regulations. Organizations generally only face potential liability if they either falsify documentation for auditing or certification, or suffer a breach and are later shown to be negligent. I am unaware of legal enforcement mechanisms if there is a known vulnerability, but no definitively unapproved disclosure of information.

This is an inherent risk of audit-based approaches to data protection.