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.

So I have a few humble thoughts about free security tools over on the Savvis Blog that you as a cloud customer can use to fill in gaps that sometimes occur during a transition to a cloud environment.  I won’t reproduce the content here, but wanted to pass along the link.

You can check it out on the Savvis blog at this link.  It’s entitled, “5 free security tools every cloud user should know about“.

Image source: savvis.com

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.

This month for eCommerce Times, I outline a few strategies for planning ahead of time for security resource dropoff during the holidays:

The end of the year is one of the riskiest times for information security. Attack levels rise right at the time IT staff attendance typically takes a dip. Adjusting to this critical period isn’t easy, but collecting the right information now can help you take a better course of action when this season rolls around next year.

If it sounds interesting to you, check out the full article here.

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

Apologies to individuals who have tried to comment the past few days but have found themselves unable to.

Bad news is that once again, WordPress unexpectedly reset the comment settings without a peep (leaving me in the dark until people started complaining about it.)  Good news is that this instance of that foolishness brought the situation to a head, giving me the motivation to move comments over to Disqus.  So there you have it: new comments, at Disqus.

Please to enjoy.

Image note: From the Skyrim trailer shot-by-shot analysis over at MaximumPC.  Get it?  Because… like it’s a troll… and, you know, comments… oh, never mind.