As the second law of thermodynamics tells us, all things trend toward chaos and this is no less true with a virtual environment. Sprawl can have a real security impact, and it takes discipline and planning to control sprawl — discipline and planning that won’t occur without someone from the security team actively monitoring the problem and formulating strategies for how to address the issue.

VVirtualization has been one of the most rapidly and widely adopted technologies in recent memory. It’s huge, and it’s here to stay.

And as security professionals know, setting up a virtual environment securely isn’t easy. Significant effort goes into tasks like evaluating off-premise service providers, ensuring regulatory compliance, and standing up technical controls like monitoring and encryption. But in the excitement to stand up the new environment and get security to an acceptable “target state,” organizations sometimes don’t address security hygiene long-term. In other words, security is in high gear while the environment spins up, but it doesn’t lay the groundwork for what happens once things are chugging along.

Read the rest of Ed’s article over at E-Commerce Times.

[Excerpted from "Security Via HIPAA Compliance," a new report By Diana Kelley and Ed Moyle, posted on Dark Reading's Compliance Tech Center.]

Healthcare compliance requirements can be a driver to improve your organization’s overall security. Here’s how:

If your security organization is in the healthcare space, you inevitably are wrestling with the Healthcare Information Portability and Accountability Act (HIPAA). HIPAA compliance is one of the biggest challenges healthcare IT organizations face — but it also could be an opportunity to advance your security agenda.

For security professionals to leverage compliance investment and activities for broader benefit, they must understand what’s driving current compliance investment.

First, it bears saying that the standards outlined in the HIPAA Security Rule are designed to address broad swaths of industry—from small clinics and physician offices to the largest institutional care providers and insurance companies. Because of this, the high-level security control objectives outlined in the Security Rule (standards) as well as the supporting controls are extremely broad and lacking in technical specificity.

How can security organizations make use of compliance activities?

Check out the rest of the excerpt at Dark Reading or download the entire report at the DR Compliance Tech Center.

In interesting research news, there’s a paper out from Accuvant that attempts to compare the relative security merits of the “big three” browsers: Chrome, FireFox and Internet Exploder Explorer.  It’s an interesting read, so I suggest checking it out.

Now, I admit that I was skeptical when I first started reading it.  Not only can the “which product is more secure” evaluations be a little spurious, but this particular report is also actually sponsored by Google, so… well… you can see how one might wonder about that…  At least without a deeper dive.

However, after reading it in more depth, I think they’ve done a reasonable job in impartially analyzing the question in their scope.  In other words in analyzing the “software security” side of the argument – put another way, the resistance of the product to attack via coding or software architecture vulnerability.  Note that’s not the same as security features — or security of the product overall.  Security features are another matter entirely.  But I think it’s useful to bring it up because the industry press coverage doesn’t really seem to be discriminating between the two.  And they really are different questions.

As an example of what I mean by this, consider the SSL/TLS implementation of the various browsers.  This isn’t in the scope of the Accuvant analysis (since it doesn’t directly relate to attack resilience)… but it would be relevant, I’d think, to the broader “which is more secure” question.  Like, I’ve griped in the past about the fact that until recently Chrome supported SSL 2.0 by default (seems like a major no-no in my humble opinion) and the fact that FireFox is the only one of the big three to have OCSP checking enabled by default (again, haven’t looked at these settings in a while so maybe this is a moving target in light of the certifipocolypse a while back).  These aspects of “browsing security” (note how that’s  different from “browser security” – at least as evaluated through resistance to software-directed attack) would have been a “score one” for FireFox in my estimation.

But again… not in the scope of their analysis.

So the point is: I’m impressed with the fact that they’ve tried to come up with an actual methodology to evaluate the security of the underlying codebase.  And I’m also interested in their conclusion.  Although I’d recommend sticking close to their actual research vs. how the industry press seems to be spinning it.

Image source: itsalltech.com

In light of continued shenanigans in the CA community, apparently the CA/Browser forum has put out some guidelines for certificates that are going to be trusted by default in various browsers.

The document is here if you want to check it out.

I get it why the CA’s want this.  It’s important that people believe they’re taking action.  It’s an entry-heavy, low-maintenance business.  Meaning, you invest a lot in the beginning and milk it over a long period of time.  But yet, there’s no reason why CA’s have to exist.  The exist right now because of inertia; because it’s easier to go with the status quo than it is to change the way the process works.

There’s no technical reason why another approach couldn’t work equally well or better (it does for PGP).  Ripping down the underpinnings now is a perfectly viable option – and one CA’s really don’t want.  Because changing it would choke the revenue stream of the long-time players and would mean that newer players may not even recoup their outlay.

But yet… the guidelines.  First, it’s a voluntary industry association.  Their only enforcement authority is in getting the browser folks to require an audit that conforms to this.  From the press release:

Following adoption of Version 1.0 of the Baseline Requirements, the CA/Browser Forum will request that all browser and relying party application software developers incorporate the Baseline Requirements into their accreditation and approval schemes as requirements for all applicants who request that a selfsigned root certificate be embedded as a trust anchor in their software.  The CAB Forum also intends that the ETSI ESI Committee and AICPA/CICA Task Force on the WebTrust Program for CAs will coordinate revisions to their respective audit standards such that the Baseline Requirements will become auditable requirements starting in June 2011.

Yes, yes.  I’m sure everybody with a browser or utility SSL implementation are going to immediately comply… And as to what it addresses?  Not enough.  On the plus side, they realize this:

CA and browser members of the CAB Forum acknowledge that the current version lacks provisions in some key areas, and they anticipate working in the coming months to overcome these deficiencies.

That’s an understatement – like a “hurricanes might bring humidity” kind of understatement.  But at least they get it that it’s missing stuff.

All in all, I have mixed feelings.  I’m not the kind of guy who’s into changing stuff just because… but there really are some serious flaws in both the technical and business sides of the CA infrastructure that foster low assurance.  And this document doesn’t change any of those things.  The financial incentive for CA’s to have poor security (to drive price competition) is still there – it arguably just raises the bar a little bit.  Now, the financial incentive (assuming browser folks require this) is to be just close enough to compliance to minimize costs.  I.e., to stay as close to”not compliant” as their auditors will let them.  I’m not sure that’s going to solve the problem.

I’ll wait to see what future revisions have in store, but in the meantime I’m skeptical.

Image Source: freerepublic.com

So if you recall, I received an inquiry the other day to take a bit further my post where I was quacking about credit unions.

As a refresher, the gist of that discussion was that I found it to be somewhat lame that credit unions were complaining about how they have stringent technical controls whereas merchants don’t. My meta-point was that merchants (at least for card-based payments) have some very stringent (i.e. technically prescriptive) security controls by virtue of PCI compliance.  Credit unions, on the other hand, by virtue of their regulatory context, have more “interpretive latitude” in how technical security controls get implemented.  Meaning, they should try on PCI compliance before calling out merchants (especially the big ones) for having it soft.

To get some additional context on this point, I reached out to a former colleague who’s now an auditor for credit unions and community banks.  I’ll keep his name off the record – not because he asked me to necessarily, but because he asked that I not identify his employer… and anybody with a browser and a linkedin account can look at my background, guess who he might be, and determine his place of employment.  So let’s just call him “Papa” – for “Papa Smurf”, his nickname when we worked together.  Anyway, mega-thanks to him for going through this with me.

Anyway, below is the record of the discussion I had with him.  I’ll pull out some of the material that I think highlights or negates my point from earlier in a subsequent post (since we really got into detail and covered a lot of ground in our discussion):

Can you briefly describe the type of work that you do with credit unions?

Typically under contract, what we do is a full-scope risk assessment.  Under the current regulations, a credit union, unlike a bank, does not have to have an IT audit.  They are instead required to have an “IT risk assessment”.  This risk assessment looks at approximately 27 control objectives that come out of COBIT.  The objective is the same as an audit – the difference is that during a risk assessment, you don’t collect work papers and the client is responsible to complete specific areas of a risk assessment themselves.

We have credit unions that request an IT audit over and above a risk assessment.  Audit is basically a “black & white” evaluation exercise (you either “have it” or you don’t – you meet the bar or you do not); An IT Audit is based on COBIT, a methodology from ISACA (Information Systems Audit and Control Association) to evaluate the controls  and how they comply with the FFIEC IT Audit guidelines.  A risk assessment on the other hand is based on the National Institute of Standards and Technology’s (NIST) Special Publication 800-30 and follows the guidance provided in the FFIEC Information Security Booklet to evaluate the risks and safeguards in place to support the bank or credit unions Information Security Program.

How many banks and credit unions would you say you’ve worked with in the past two years?

Probably around 24.  About one per month.

What specifically is required of a bank or credit union with respect to security controls?  What standards do they need to adhere to? 

Credit unions are regulated by the NCUA (National Credit Union Association).  The difference is that credit unions are non-profit.  Regulatory-wise, there’s no difference between a credit union and a bank and from a financial aspect, they both provide services to customers/members and the business community such as loans (car, mortgages), savings, checking, etc.  The FFIEC is the inter-agency chartered to provide guidance to all banking institutions.  FFIEC includes OCC, FRB, Federal Deposit, and the NCUA.  It also used to provide governance to OTS, but that’s gone because there are very few thrifts ( savings and loans – think: “It’s a Wonderful Life”).

In terms of our risk assessments, we take into account items from COBIT as well as guidance from PCAOB in addition to industry best practices.  We use  best practices because they change faster due to technology and procedure than the guidance from the FFIEC and elsewhere.  The fact that it is not FFIEC guidance, doesn’t mean it’s not useful for these organization to consider.  For example, we sometimes use the PCI DSS as a best practice guideline for what these organizations should look to from a best practices standpoint.  The DSS has straightforward questions looking for straightforward responses.

What’s the role of the FFIEC examiner handbook?  How much teeth do those controls have?  How do those rules compare to PCI DSS?

FFIEC guidance is high level in terms of technical content.  While it is called ‘guidance’ they are standards and the banks and credit unions must comply with the guidance. They are examined using the FFIEC as the source document for compliance.  PCI is not a regulatory requirement – it is private enterprise (Visa, MC, Amex) that established specific rules that a card issuer/merchant must follow.  That doesn’t mean that nothing goes wrong – all you need to do is look at the  TJ Max and Hannaford incidents.  Under PCI, card issuers/merchants  are required to comply to the requirements and have an annual PCI audit done by persons certified directly by PCI. More than that, I am not sure – nothing in the PCI documentation indicates you will lose your right to be a card merchant but there must be some ramifications.

What happens when a credit union doesn’t comply?

When a credit union is being examined by the NCU, assuming a  full-scope exam, it would include all areas of IT including BCP/DR, handling of member (customer) information, data at rest/in transit, user (employee) access controls, and LAN/WAN networking.  .  However, in the past few years, my take has been that they are focusing more attention on the financial  side rather than IT.  So when it comes to IT – the credit union gets a pass because areas were not examined but that doesn’t mean when we do an audit or risk assessment we will let it pass – we cannot because of the COBIT, NIST, FFIEC, and other guidance factors.

FFIEC guidance – even though it’s guidance – is required for these organizations to meet it.  Incident response for example, is a requirement.  But there’s some interpretive latitude relative to the degree or depth of that plan.

Is there any “wiggle room” when an organization can’t meet the guidance?

The rule of thumb I use relative to Incident Response is a clause in the FFIEC guidance that speaks to “size and complexity”.  A smaller credit union might not have the same level of technical expertise, IT staffing, or funds to purchase something like enCase (the forensic product) to do investigations; they might not have the money to support it, to train users, licensing fees, etc. – you have to measure their response plan and ability to support it based on what makes sense for an organization their size.

However, BCP/DR for example, requires a  recovery and a continuity plan.  They have to have a plan in place.  On the other hand, there is no regulatory requirement for a bank to have a generator.  When I got into this line of work, I thought there was because it makes sense.  However, there isn’t.  When you have a power outage in an area, you’re not opening your doors.  There’s guidance and then there’s a flaw in the guidance.  There are some that do, but many banks and credit unions do not.

What’s the role of GLBA?

GLBA says that customer information (name, ssn, etc.) otherwise referred to as non-public personal information and it must be protected.  This is information that is not commonly found such as in a telephone bill, a telephone book, or a car rental agreement.  The primary objective of an information security risk assessment is to identify, evaluate, and prioritize threats to information assets and vulnerabilities in the control environment.  The risk assessment represents the foundation of the Information Security Program and is an ongoing process that highlights needed program enhancements.

This entire process requires the bank/credit union to have appropriate policy and procedures in place to provide guidance to all employees on how to handle and control customer (member) information.

Not having formal policy, but having documented procedures isn’t great, but it is a start.  The Board of Directors are expected to develop, or have developed for the bank/credit union, policies that they, the BOD are required to review, and approve and have implemented.  If they don’t, they cannot protect the information properly and I would write it up  a high or medium priority in a risk assessment I’m doing.

Protection of all media (optical, magnetic, or paper) at rest (sitting in a cabinet or database) or in transit (sent from main office to backupsite, etc.) has to be protected as well.  It must be secured such that only persons who need access to it, do.  This is commonly referred to as the rule of least privilege.   I did one audit for example where regulatory required documentation was stored in one central room and a number of individuals had access.  They stored non-perishable foods, holiday decorations, etc. in the same room.  That was an issue.  The paper materials should be in a secured location – either in a secured desk, locked room, cabinet, etc.

So today we have some excellent coverage via the always-interesting Mocana DeviceLine blog (have I blog-rolled them enough do you think?) covering a technical deep-dive on Google Wallet from ViaForensics.  An interesting read.

According to their inquiry of how Google Wallet works, they’ve determined that there’s some scary data stored cleartext on the phone, including:

• Card type and last 4
• Card holder name
• Current balance
• Available to spend
• Statement balance
• Payment due date
• Citi contact number

Well, that’s interesting. Folks might object to this kind of data being stored in cleartext within Google Wallet (I sure do), but I’d like to point out that the problem isn’t so much Google Wallet (although, guys… really?  Statement Balance?  Really?)  but instead the fact that mobile devices are blurring the lines between what’s a payment application vs. what’s not.

You see, right now, shy of actually storing the whole credit card number, there’s not really much guidance on what is or is not acceptable here from a protection standpoint.  Technically, Google Wallet falls into what the standards council has defined as a “Category 3 Payment Acceptance Application.”  What is a Category 3 mobile payment acceptance application, you ask? Per the council:

Payment application operates on any consumer electronic handheld device (e.g., smart phone, tablet, or PDA) that is not solely dedicated to payment acceptance for transaction processing.

Sounds like Google Wallet, amirite?  So how do you validate such an application?  For example say Google wants to do the right thing and have someone review their app to avoid these kinds of shenanigans… to ensure that the security of the application is consistent with the defined requirements of PCI?  Short answer: you can’t.  Longer answer —  from the council:

The PCI SSC recommends that mobile payment acceptance applications that fit into Category 3—and are thus not eligible for PA-DSS validation at this time but are intended for use in the cardholder data environment—are developed using PA-DSS as a baseline for protection of payment card data and in support of PCI DSS compliance.

OK, so you can’t validate it.  They recommend that you maybe skim through the PA-DSS to check out how to protect cardholder data from an application standpoint, but it’s discretionary… So you can’t validate to PA-DSS.  Unfortunate.  So what is the oversight for these apps? Who’s responsible?  From the same document:

Applications used for payment-initiation—for example, those downloaded by consumers onto their mobile phones and used for consumers’ personal shopping—are seen as similar to the payment card in a consumer’s wallet. The Council’s purview does not currently extend to, nor is PA-DSS applicable to, consumer-facing mobile payment initiation applications.

And there you have it.  My reading of this is that — at least currently — the expectation that we should have for security of “consumer-facing mobile payment initiation applications” is the goose-egg.  In other words, Google didn’t cross a regulatory boundary.  One might argue that there should be a regulatory boundary here… but if there is, I can’t find it.

Anybody disagree?  Would love to hear from a PA-QSA on this.

Image source: gyakutenphoenix.deviantart.com

So the other day I came across this article that proudly pronounced “fraudsters defeat two-factor” as well as an extremely lucid response via the WikID blog.  It’s worth reading the original article for folks implementing phone-based OOB two-factor authentication (since it highlights an interesting misuse-case) and it’s also worth reading the excellent follow-on piece that puts it in perspective.

Anyway, I won’t belabor this point other than to point out that the WikID folks are right on the money, but for those folks who follow the two-factor market space and who missed this discussion, I thought it was worth calling attention to.

Image source: coolchaser.com

So there’s a really interesting paper out about detecting “capability leaks” in Android smartphones courtesy of the folks over at North Carolina State.   It’s called (unsurprisingly enough) “Systematic Detection of Capability Leaks in Stock Android Smartphones” and it’s a great read.

So these guys built a tool (called “woodpecker”) that snakes around inside popular Android phone platforms looking for places where the phone is configured so as to violate the Android permission enforcement model.  Go read it… you’d be surprised what they’ve found.

Now, I’m not going to steal their thunder and I highly recommend you go read the original source material, but to whet your appetite, take a look at this table from their report summarizing what they found:

Pretty wild, right?  Apparently most of the platforms out there have situations that do violate the permission model, thereby allowing apps to do stuff that maybe the user doesn’t want.

Of course, I’ve made the point a few times that users tend not to care about permissions anyway.  I mean, the case of a Sudoku app that wants “full internet access” I can sort of get… maybe they want to show me ads or whatever.  Or maybe I can forgive the fact that Skype wants to be able to “MANAGE THE ACCOUNTS LIST”, “USE THE AUTHENTICATION CREDENTIALS OF AN ACCOUNT”, ”DISABLE KEYLOCK”, and “DISCOVER KNOWN ACCOUNTS”.  Maybe… just maybe (because they’re Skype), I’ll (reluctantly) agree to let them “MODIFY GLOBAL SYSTEM SETTINGS” and “RETRIEVE RUNNING APPLICATIONS”… much though I’d rather they didn’t.

But seriously… doesn’t it scare anybody else that “Funny Jokes for Kids” needs “FINE (GPS) LOCATION”, “FULL INTERNET ACCESS”, and “READ PHONE STATE AND IDENTITY” (i.e., “An application with this permission can determine the phone number and serial number of this phone…”)?  Um, really?  So,  here’s an app, with an install base of “100,000 – 500,000″ (from the overview page on the market) that’s targeted to “children 8 and under” that can:

• Uniquely identify you (or your child),
• Determine fine-grained geographical location, and
• Communicate those details to whomever it wants

Nope… that’s not scary at all.  Perfectly reasonable, right?  Bah.

I blame the user community… and I include myself quite squarely in this category.  For example, I routinely install apps with only a cursory glance at the permissions; the times that I happen to glance at what the app wants to run (that are, quite frankly, “crazysauce” in many cases), I usually install them anyway betting on the fact that it’s probably innocuous.  And I actually care about this stuff.  But “joe average” user?  Not likely to even read it… or care about it if they do.

Until users start to actually care about permissions, I’m not sure the enforcement model – and how well it does or doesn’t work – is going to matter much.  But it would be nice to know it worked when/if they do.

Image source: oakcreekprintworks.com

So today the CUNA (Credit Union National Association) issued a letter from their president to Congress (as part of the record for a hearing on data protection for small businesses) calling for merchants to have the same “same high standards for data protection” as financial institutions.

From the letter:

As we describe below, credit unions are subject to very high data security standards under the Gramm-Leach Bliley Act of 1999 (GLBA)… However, merchants are not required to follow these standards, and until they are held to the same standard, consumers will remain vulnerable to a system that does not protect their information.

So the beef here is that Merchants — specifically in reference to debit transactions – don’t have data security requirements with teeth.  OK, I get that.

But compare GLBA (as outlined via the safeguards rule and the  FFIEC IT Examination Handbook) with the PCI DSS.   Yes, it’s true that most financial institutions have better procedural controls compared to merchants — because merchants don’t generally have the same challenges as financial institutions do.  But merchants do have a requirement for technical controls.   In many cases, a more prescriptive, defined, with less “we don’t want to do it” wiggle room as what FI’s have to adhere to.  By virtue of the PCI DSS,  merchants who process credit cards — tend to have better technical controls  than many financial institutions.

So here’s what I’d say: sure, let’s get merchants to adhere to same  data security requirements as financial institutions when it comes to debit transactions.  But I’d recommend that we make that conditional on the inverse requirement.  Namely, that the current  requirement merchants need to adhere to for credit cards be required of FI’s.  Specifically, that financial institutions be required to implement the technical controls of a highly-prescriptive technical standard (like the PCI DSS) in the entirety of their processing environment.

Seems fair, don’t you think?

The Ponemon healthcare study, the Second Annual Benchmark Study on Patient Privacy and Data Security (sponsored by ID Experts), has been gaining quite a bit of attention in the press and in the blogosphere over the past few days.

Overall, it’s an interesting report (as most Ponemon reports are). And I for one am pleased that folks out there are interested enough in the intersection of HIT and security to go out and read it… even more pleased that so many people find the topic interesting and valuable enough to write about it.

But all that being said, there’s something about it that’s leaving me scratching my head.  And I don’t mean to call into question the value of this (excellent) document… but let me walk you through what I mean so you can see what I’m talking about.

First, hold in your head for a minute the very dire picture of HIT security as reflected by the Ponemon survey.  Results that we can be reasonably confident in, by the way, since they’re reflected independently in other data collected on the same topic.  So security in HIT sux, healthcare security’s the devil, etc.  Got it?  Good.  Put a pin in that for a minute…

Now go take a look at what providers are doing and spending in security.  We can do this because the HIMMS Security Survey tracks it for us – using the same measuring instrument as Ponemon (a survey of those in healthcare).  Now, a close-reading of the HIMMS reports can tell us a lot about what’s happening behind the kimono at providers and how/what they’re doing from a security standpoint.  Take a look, for example, at the recently-minted 2011 Security Survey, but also as a backdrop – and a baseline - last year’s as well.

While a lot has remained unchanged year-to-year, there are a few trends that the survey calls out:

• Increased security budget for two years running  (2011, page 4 – 2010, page 4)
• Decreased use of user-dependent access-gating security controls [implying increased use of automation] (2011, pages 11-12)
• Better detection of security incidents (2011, page 15)
• Increase in encryption overall [though desktop encryption remained constant] (2011, page 19)
• Increased use of – and derived value from – audit logging (2011, page 14)
• More providers using IDS (2011, page 14)
• Decreased incidence of medical identity theft (2011, page 20) [Note:  compare the HIMMS 35% decrease of medical identity theft to the Ponemon survey's cited 26% increase... Not sure what that's about.]

These are all positive things — at least according to traditional wisdom.

So what’s up with that?  Can it be the case that investment is up, security controls are more prevalent, but yet derived value is down?  I’m not sure I buy that.  Yes, yes… spending is not a reliable metric of effectiveness (if it were otherwise, our cable company would be exemplary).  But surely, we’d expect more spending plus more controls to equal better security?  Right?

Unless…

Unless the barometer that the Ponemon study uses (i.e. breach disclosures, breach impact) are actually indications of better security overall, instead of worse.  Could it be the case that data breaches are on the rise because we’re finding them more? Because we’re looking for them since not doing so violates federal law?  Could it be that the cost to respond to breaches is up because we’re doing more about it when we find them?  Those things also explain the Ponemon data, but make more sense in light of the HIMMS report.

Now, I’m not arguing with anybody’s conclusions here… I’m the first in line to say that security in healthcare sucks on ice.  All I’m saying is that there are only three conclusions we can draw:

1. One of the two surveys is inaccurate or an outlier [unlikely]
2. The two surveys suggest that value per security dollar invested is on the decline industry-wide [also unlikely]
3. The two reports are saying the same thing — but instead of the conclusion that security is on the decline dismal, the data points in the Ponemon report actually reflect positive outcomes instead of negative ones.  I’m going to suggest that this one is Occam’s Razor.

Or maybe something else entirely? Meh… just my opinion.

Image Source: bored.com