Blogger: Randall Gamby

Two weeks ago the PCI Security Standards Council released the preliminary details of the PCI Data Security Standard (DSS) V1.2 that’s due out in October.  While many Analysts and Reporters have already written on the topic (I’ll be releasing an extensive update on Burton Group’s PCI coverage around the October release date), they really haven’t commented on what’s still not been addressed by the standard for enterprises still working on attaining compliance.

While I applaud the PCI Security Standards Council in further clarifying and adjusting the standard, a lot of work still needs to be done.  I receive about one or two PCI questions a week from our clients and they seem to revolve around a couple of topics I’ve yet to see addressed:

• Guidelines for selecting a Qualified Security Assessor (QSA) – while there are a large number of QSA organizations listed on the PCI Security Standards Council web site; they can’t really recommend a particular QSA for an individual organization.  This leads a lot of organizations to struggle with determining what criteria they should use in selecting a QSA for their certification.
• The role of the QSA – organizations are also still trying to understand the role of a QSA.  Should they get a QSA involved in the gap and remediation process in advance of certification?  If so, should it be the same QSA that will do their certification (knowing there’s a risk that the QSA will be pre-disposed to only care about certain vulnerabilities)?
• Industry-specific best practices – while each organization may have different infrastructures, in general, most industries try to be consistent with the major functions they perform.  So are credit card transactions handled differently between say, a major retailer with 10,000 POS systems and an insurance company that has hundreds of independent agents receiving remittances? Probably, so what are best practices around these industry-specific configurations?
• Virtualized environments – while the PCI Security Standards Council recognizes that some organizations have moved to virtual services for consolidation and management, the DSS really doesn’t provide guidelines for QSAs to evaluate and certify these environments.
• Monitoring and audit – while the PCI DSS recommends minimum timeframes for scanning, doing pen tests, etc. what are the real levels of monitoring and audit needed for ensuring security?  With the Hannaford and Okemo breaches that occurred (both where PCI compliant), neither discovered the problem until months after the breaches had happened.  So identifying what should be scanned and tested and if some of this should be on a continuous basis still requires refinement.
• PCI as part of an overall security model – what are the best practices around merging PCI security requirements into an enterprise’s overall security model?  Should it be maintained separately? Should some components be integrated with similar security mechanisms?  Should PCI be at the top of the security model and other configurations be based upon its requirements?  There are really no answers coming forth on this topic and the other question is where will they come from? Surely enterprises won’t expect the PCI Security Standards Council to tell them how to run their security services.

I will be providing Burton Group’s perspective on most of these questions in my upcoming report, but rather than relying on third parties to resolve these, I’d hope that the PCI Security Standards Council will be able to continue to provide answers to the questions they can in future updates, and releases, of the PCI DSS.

For those of you who aren’t familiar with XSS Filter, a brief summary is that it is a client-side defense against reflected cross-site scripting (XSS) attacks.  It works by recognizing that reflected XSS attacks inject script into the string that the browser sends to the targeted web server.  If the server doesn’t neuter or strip out the injected script, it gets sent back to the browser and executed in the context of the target web page.  Bad things then happen.  At a high level, XSS Filter remembers the string that the browser sent to the server, and looks at the server’s response to see if any of the script was actually in that string.  If it was, then XSS Filter decides that it got there because it was injected by an XSS attack and blocks the script from executing.  The rest of the web page renders as usual.  This is a vastly oversimplified sketch of XSS Filter – for details, see the post by David Ross, inventor of XSS Filter on the Security Vulnerability Research and Defense blog.

So what does XSS Filter have to do with the SDL?  Well, for almost nine years, since XSS was first discovered at Microsoft, we’ve been trying to figure out effective ways to reduce vulnerability to XSS attacks.  Our focus has been on improving the ways that web page developers code their pages, and we’ve developed a lot of tools and techniques for making web content safer from XSS attacks and for detecting XSS vulnerabilities in live pages.  The SDL requires the use of many of these tools and techniques, and we’re sure we’ve prevented a lot of XSS vulnerabilities from being introduced into Microsoft web pages as a result. 

But while we identify (and the SDL requires) measures that allow developers to avoid classes of vulnerabilities, we also look to identify more sweeping solutions that can either 1) eliminate classes of vulnerabilities, 2) reduce their severity, or 3) reduce the likelihood of attacks being successful.  The process usually starts from deep understanding of a class of vulnerabilities and attacks, and then we broaden defenses from there.  In the case of XSS Filter, David’s years of work researching XSS led him to come up with an approach that blocks many of the most common vulnerabilities to reflected attacks found on the web today.  The solution is compatible with existing web pages (doesn’t “break the web”) and thus we were able to enable it by default for users of Internet Explorer 8.  Because it’s a client-side mitigation, it will help protect users from attacks even though the sites they visit may be vulnerable to XSS. 

Our work on buffer overrun defenses follows a somewhat similar pattern – we started by prescribing coding techniques, banning the use of some APIs, and building tools that detect coding constructs that look like buffer overruns.  As we gained a deeper understanding of how buffer overruns can be exploited, we enhanced the /GS compiler flag and added ASLR in a quest to cause classes of exploits to fail even if a buffer overrun remains.  We’re not yet close to eliminating the SDL requirements for use of tools and coding techniques, but the SDL also requires the use of the mitigations to reduce the severity of vulnerabilities that slip past.  Will we ever get to the point where the mitigating technologies are so strong that we can relax the coding requirements?  Maybe not, but we will continue to introduce technologies that reduce the chances of a successful attack.

Similarly, in the case of XSS, even after IE8 ships, the SDL will continue to require the use of safe web site coding practices and tools such as the Anti-XSS library both to protect users of browsers other than IE8 and to provide protection in recognition of the fact that XSS Filter is a mitigation or defense in depth rather than a complete solution.  But we’ll also be keeping our eyes open (and doing active research) in the quest for an even more effective defense – whether client or server side – that eliminates XSS for good.

This post is a little far afield from the normal content of the SDL blog, but I thought it was important to provide a picture of the role of security science and security research in defining SDL requirements and in making major improvements in software security.  You can read more about our work in security science in the Security Vulnerability Research and Defense blog.

HANSEI - WHAT IS “RELENTLESS REFLECTION?” - And why we’re talking about it in the context of Risk Analysis.

Recall from yesterday’s post about how I got to thinking about the concept of Hansei-Kaizen, “relentless reflection” and “continuous improvement” and how we might apply that to risk management.  It’s a concept born of Toyota and is, in some way, the foundation for “Lean” production.

Call me biased, but I think that Hansei - the act of ‘relentless reflection’ made structured is the analytical function.  And I hate to debate (post-mortem) the father of Toyota quality success when he says that Hansei is the “check” in Plan/Do/Check/Act, but I think that Hansei also applies to the “Plan” of the P/D/C/A or Deming cycle.

You’ll recall the P/D/C/A cycle can be thought of even as an implementation of Scientific Method, in that it is Observation & Hypothesis Creation (P), Experiment (D), Analysis (Check), and Act (Revise/New Hypothesis, etc…).  Well then as such, the Hypothesis creation involves creating a model or creating an expected outcome for data using the currently accepted model.

So in our industry there is an opportunity for Relentless Reflection in both the Observation and Hypothesis (Plan) creation steps, and the Check step.  We create an estimate for control strength, or probable losses in the context of risk- then we go to Experiment step.  That hypothesis can be put it into production, have an audit, have a penetration test, whatever, in the context of the Do step.  BTW - using Hansei/Analytics in Plan is one way that strong analytical functions can really make penetration testing more useful - as a means to test the estimates and inputs into a model.  It’s Penetration Testing 2.0!  (<- tongue fully in cheek, yes)

Those who are versed in the reasons to merge Six Sigma and Lean together are probably already seeing where I’m going with this today.  But before you think that a simple DMAIC function is all that is needed to create proper “Hansei”, let me encourage you to keep reading.

Now if the analytical function can said to be “reflection”, why must it be relentless?

One word.  Change. There are essentially four separate “landscapes” or sources of change that we face (more on those tomorrow).  But anyone who has tried to manage system compliance, log management or policy exceptions knows that change is possibly the most difficult thing we security professionals must manage.  And when you think about it, there aren’t too many other business functions like information security where significant visibility and insight about the environment is needed for “complete” information (get bullish on Log Management is my recommendation).

HANSEI STEPS ADAPTED TO INFORMATION SECURITY

This is one of those quality control concepts that we can mangle adopt.  At Toyota, Hansei-Kaizen includes the following basic steps:

1. Initial problem perception
2. Clarify the problem
3. Locate area/point of cause
4. Investigate root cause (using an ask why 5 times approach)
5. Countermeasure
6. Evaluate
7. Standardize

Now it’s important to note that part of this includes the concept of Go See For Yourself, called “Gemba“.  Gemba can be translated as “the actual place” or “the place where virtue or truth is found.” At Toyota this might mean going to the shop floor to see the issue at hand in the production line.  But for us, that’s a problem because we live in the virtual world.  There’s usually not much use in hanging out in the wiring closets to try to see the problems.

But if you combine the concept of Gemba with the concept of “Nemawashi” –the process of discussing problems and potential solutions with all those affected- we can forge a similar concept using risk analysis.  That is discussing the issue and the risk associated with an issue (what some people would call “risk management”) with the business/LOB/data owner and let them accept authority and the risk decision.  We, the risk analyst, our goal is simply to perform items 1-5 (presenting countermeasure options that include transferring or accepting risk).  By going to the line of business and involving them, responsibility is shared.  Also, if you structure organizational behavior right, personal risk is transferred!

This sort of approach is also in harmony with concepts like “mutual ownership of problems,” or “genchi genbutsu,” (solving problems at the source instead of behind desks), and the “kaizen mind,” (an unending sense of crisis behind the company’s constant drive to improve).

One of the criticisms I have with the way most people try to implement DMAIC into “Lean”

REQUIREMENTS

Now to get this done, I really see three significant requirements.

1.)  A change in political structure.

2.)  Models that provide consistent, defensible analysis.

3.)  A Quantitative approach.  This means using actual units of measurement (not just amorphous percents, ordinal scales, etc.)  for risk and it’s subsequent factors.  Sure there are times when Q&D qualitative approaches are acceptable, but policy should be to have quantitative analysis whenever and wherever possible.

That last item - the quantitative approach - is really quite important.  And the reasons why will be discussed further in tomorrow’s post:

“What should we be reflecting about? & What is needed for reflection?”

P.S.  Your comments and suggestions, as always, are welcome.

P.P.S  Those who may be familiar with Lean/SixSigma/Kaizen sorts of mashups may be thinking - “hey, an Analytical step is built into SixSigma”.  Well, yes there is some prevision for analytical functions based on statistics, but I find SixSigma geared towards creating a State of Knowledge about operational processes, not towards creating a State of Wisdom for CISO’s around security & risks “big questions”.  In otherwords, the analytical function in DMAIC is in the context of Kaizen, and a different step than “reflective” analytics.

• Good news: router is now officially a firewall (it has been for a while, but many people are still stuck in "security device" vs "network device" cloud) - see Req 1
• From the "WTH dept": anti-virus is a MUST on ALL platforms - Req 5. Please ship me some of the stuff they are smoking; I want it! BTW, I am going to Amsterdam soon :-)
• WAF or code review for web application security is still a stupid "OR" - Req 6.6. OMG, please, software security folks, teach them the truth.
• Can we kill "plain text passwords" once and for all? Req 8 tries to achieve that noble goal (good thing!)
• Visit your offsite data storage - good (if costly) idea - added to Req 9. Requirements to secure electronic AND  paper media  are solid too.
• Love it, love it! Req 10 explains that logs needs to be actually available: 'three months of audit trail history must be “immediately available for analysis” or quickly accessible' (bye-bye, silly log dumps...)
• Some vulnerability stuff clarified in Req 11, mostly about ASVs and pentesting.
• Scope of security policy is expanded to "employee-facing technologies" (what a term!) - Req 12
• All over: more references to wireless  (WEP, access points, hidden SSIDs, etc) - indeed, recent data losses are often due to insecure wireless.

Overall, a minor change that, sadly, doesn't touch a few KEY areas, such as virtualization, for one.

For example, Reconnex that was recently absorbed by McAfee, touts "information protection" before compliance. Similarly, my friends from nexTier only mention "compliance" on a few pages. Even newly unveiled DLP resource  (DLP In-Depth portal) only contains a little bit  of information on how DLP solutions help with various compliance projects. People tout "data protection", " data security", "data governance" (aka "we know big words - bigger than you") or even "data risk management" (aka "we are confused about what we sell")

I decide to explore this curious phenomenon.

Initially, I thought that it was reverse compliance at work? People not wanting to know what content packs up and leaves their network. Then I thought that maybe DLP vendors just aren't "the bandwagon jumping kind" (yeah, right!) Then I thought that they are "beyond compliance" already :-)

But you know what? I actually think that it is something different, much more sinister. It is the ominous checklist mentality (here too)!  You know, DLP is newer than  most regulations (PCI DSS, HIPAA, FISMA, etc) and - what a shock! - the documentation for these mandates just doesn't mention DLP (or CMF) by name. Sure, they talk about data protection (e.g. PCI DSS Requirements 3 and 4), but mostly in terms of encryption, access control, logging (of course!).

Also, PCI DSS directly and explicitly says "get a firewall", "deploy log management", "get scanned", "install and update AV" - but where is DLP? Ain't there...

Yes, Virginia, folks who "go by the book" and just "do the minimum" are missing out on the chance to procure DLP while their compliance budgets are still flowing. To me that means that many still don't get the "compliance+" model - buy for compliance -> use for security, operations, having fun, etc. Think what a good DLP solution  will do for you in discovering regulated data across the entire organization, blocking those pesky email with SSNs, PHI (hi, HIPAA) and CCs (hi, PCI) as well as solving plenty of other problems ...

Today I challenge our CEP/ESP/EP vendors (or SIs) to create the following solution to detect and block rogue bots on Apache web sites.   I will install and test each submitted solution on The UNIX Forums and post the results here.

Here are some basic requirements:

1. Your solution must run on Linux and be installable and configurable remotely with SSH or HTTP.  There will be no physical access to the server. No exceptions.
2. Preferrably, the configuration can be done with a Web-Based Interface (WBI) - a browser.
3. Your solution will listen to continuous updates to the Apache2 access log, exact location configurable in your solution, and identify robots ( bots), also known as spiders, from the log.
4. Your solution will provide a confidence metric, key indicator (KI), for each bot detected, from 0 to 10, where 10 indicates “absolutely a bot,” 0 is “absolutely not a bot.”
5. Your solution will update the IP address of each bot and KI you identify in a file/table called, for example, ./bot_scorecard.txt where each line is an IP address of a bot, followed by a semicolon (or other delimiter of your choice) and the confidence factor, for example,  10.0.0.1;10 means that 10.0.0.1 is a bot, 100% sure.
6. Your solution must compare bots detected to a file/table called, for example, ./bots_allowed.txt and ./bots_denied.txt that are in the format IP address/mask, for example 10.0.0.1/24, or 10.0.0.1/32.
7. If the KI “confidence factor” of the IP address of your detected bot is higher than the tunable “is a bot” KI, then your solution should update the tables/files and then call iptables and block the bot.
8. It should send an email to one or more email addresses with a message, for example:  “New Bot Detected - Confidence 8″ with IP address, etc. in the message.  Another example would be an email, “Bot Blocked” - with details, etc.
9. You cannot automatically block any traffic that is not a bot.  Blocking one “non-bot” results in failure, no exceptions.
10. The Prize:  The winner will get their logo (w/link) on this site in a block called “Bot Hunter Winner” (or something like that.)

These are some basic requirements; I don’t want to restrict your thinking or solution, so be creative!  Feel free to ask any questions in the comment section of this thread.

Remember, sometimes you may have to manage the state of IP addresses for days, or hours, before you can accurately deterimine if it is a bot based on behavior alone.   So, you will need to work with both long and short time windows.  Latency is not important. Detection accurate is importance.

Anyone care to submit a solution for testing?