Branden Williams' Security Convergence Blog

OK folks, bring on the love. Ready? I'm going to stick my neck way out there.

PCI is easy.

*GASP*

OK, taking a company that ignored security (or only focused on one particular element of a good security program) to compliance is hard, painful, and will result in lots of kicking and screaming and other tantrum like actions. Why? See this post.

But take PCI DSS on the surface. It's prescriptive (potentially overly so in some cases), it is based on a good, common set of security practices that, quite frankly, you should already be doing, and its impact to your organization can be limited dramatically depending on how you approach it. If you look at the high level twelve requirements for PCI, all of them map into ISO27002 standards. Want to know what an assessor will ask you, or exactly what you have to do to comply with a particular requirement? Read the testing procedure! It's right there!

One of the issues customers and industry folks have with PCI is they will pick one particular area of PCI and latch on to it as a problem. "I can't do PCI because of X," or "Y is TOTALLY insecure.... if I do Z, I am more secure but not compliant?"

Sometimes these conversations come from people who simply do not want to go through the effort of PCI DSS and are trying to delay taking any action to resolve a gap. Maybe they think if they delay it long enough, they will be promoted out of the job, and it will be someone else's problem. I once had a (former) customer tell me he could not wait to be done with PCI so he could get back to security. What this gentleman didn't know is that PCI was the only thing delaying him being pwned because his security was so poor.

I think if the folks screaming about PCI would stop for just a second and take a look at the item for which they scream (ain't ending in no preposition here, baby! YEAH!), they would realize that (in most cases) good security practice tells them to do the same thing! If we are truly security professionals, or if we care about security at all, shouldn't we focus on improving security in our companies? The answer is Yes, and if the method by which we motivate our companies is the stick of PCI, why not use it?

Posted by Branden Williams at 5:47 AM | Permalink | Comments (0)

On Monday, I told you all about a MasterCard fine schedule but I was unsure on when it was going to start. Well, as it turns out Level 2 and 3 merchants are being fined NOW, not sometime after the December 2010 date.

That's right, some Level 2 merchants have already received their first $25K fine from MasterCard under their new fine program. Apparently, that's how many of the acquirer's found out about the program!

Posted by Branden Williams at 4:43 AM | Permalink | Comments (2)

Time for a throwback! This year, I posted my new article "The Art of the Compensating Control" over a three week period back in April. A reader recently contacted me about a claim I make in Part 4 of the posting. He says:

In your April 2009 blog The Art of the Compensating Control (Part 4) Tax day special, you stated that using the random function in COBOL to generate your key was in a sense, "a really bad idea". I have no knowledge of encryption so I don't see the fault with the process. How would this be equivalent to only 53 bits of encryption?

Excellent question! The basis of this post relies on a tool by Mandylion Labs called the Brute Force Calculator.

True 128-bit encryption means that the key is 128 "bits" of data long. A bit of data can either be a 1 or a 0. 8 bits make a byte, 1024 bytes make a kilobyte, and so on. An example 128-bit key might look like...

0010100010101011001010001010101100101000101010110010
1111101010110010100010101011001010001010101100101000
101010110010100010101011

Theoretically, this would be truly random, and you can use the entire "key space" offered by the key size and the algorithm you wish to use because you are placing a 1 or a 0 in each of the 128 bits.

Now let's look at how ASCII-based numbers (or if you like, EBCDIC) are represented in binary. Each ASCII character (or number in our case) is equivalent to 8 bits of data, or 1 byte of data (yes, technically 7 with 1 bit of parity). For example, the binary value for the ASCII character '1' is '00110001'. So now, 16 digits (128-bits / 8 bits [because each number takes 8 bits to be represented in binary] = 16 positions), or characters, would be all you can use to make up your key. If you know that your key is based on binary representation of ASCII numerical values, then you effectively know that each 8 bits of data can only be one of the following values:

• 0: 00110000


• 1: 00110001


• 2: 00110010


• 3: 00110011


• 4: 00110100


• 5: 00110101


• 6: 00110110


• 7: 00110111


• 8: 00111000


• 9: 00111001

Using the calculator referenced above, you can calculate the "effective" key strength by understanding that 16 digits gets you a total of 10 quadrillion (10 with 15 zeros behind it) possible combinations. By taking that number and performing a logarithm using a base of 2 (because remember, binary numbers can be either 0 or 1, two different values) you find that 10 quadrillion effectively equals just over 2^53, or 53-bits of effective encryption. For comparison, if you are able to use the entire 128-bit key space, the total number of possible keys would be 340,282,366,920,938,000,000,000,000,000,000,000,000. That's a pretty big number!

So using the assumptions in the calculator (which may be outdated by way of computing power, especially in light of the recent improvements in GPU processing), 1,000 machines could crack it in less than 300 hours.

Granted that these examples are painting one particular picture. Yes you could get creative and just pull the last two digits of the binary values and use MORE digits, but isn't that the point? Create a better, more random key? If you are going down that road, why not just ask your user to type randomly on a keyboard while generating your key, then measure the time between keystrokes, combine it with the random number generator on your machine, and get about the closest you will get to true randomness with 128 0 or 1 rounded values?

Give the calculator a try! There are some other great things you can do with this sheet like calculating how effective your enterprise password scheme would be against a (non-rainbow table based) brute force attack.

Posted by Branden Williams at 5:43 AM | Permalink | Comments (3)

OK, SOMEONE out there has some explaining to do. Like, right now. Who poked MasterCard hard enough to wake them from hibernation?

When it comes to actions against merchants, MasterCard has typically been much quieter than Visa. We've had several customers come to us with new fines from MasterCard that will begin sometime in the next 18-21 monthsNOW.

Why the ambiguity? None of our customers seem to have a date when the fines start! This is a huge assumption here, but I will suggest that the fines would start after the 2010 deadlines for Level 1 & 2 merchants.

Revisiting those deadlines, Level 1 & 2 merchants must produce a Report on Compliance from a QSA by December 31, 2010. Non-compliant Level 1 & 2 Visa merchants are currently being fined under the Visa Compliance Acceleration Program (CAP) as follows:

• Level 1 Merchant: $25K/mo ($300K/yr) plus tiered merchants bumping down one tier (total $$$ unknown)


• Level 2 Merchant: $5K/mo ($60K/yr)

Level 1 & 2 merchants will be treated the same. We already know they are the same from the new reporting and validation requirements, but they will also be the same from a fine perspective! Level 3 merchants, currently NOT fined by Visa, will also be subject to fines (though in a much smaller amount than Levels 1&2). My understanding (though their appears to be some question about this) is that these fines are assessed quarterly until compliant¹.

• Level 1 & 2: $25K, $50K, $100K, $200K ($375K/yr)


• Level 3: $10K, $20K, $40K, $80K ($150K/yr)

MasterCard rolled out another change to acquirers as well, and require newly boarded Level 1 & 2 merchants to provide a compliant ROC from a QSA before they are allowed into the network. So those Level 2 merchants that have been changing processors every year, it finally caught up to ya!

None of this information is published on the MasterCard SDP website, nor was I able to get this information directly from MasterCard, so your best bet is to contact your acquiring bank to understand how this new policy from MasterCard will affect your business.

_________________________________
¹ OK smart guy, I know what you are thinking. What happens in Quarter 5?!? Again, this seems a bit unclear but it appears that the fines reset to the lowest amount and continue their normal escalating procedure.

Posted by Branden Williams at 5:19 AM | Permalink | Comments (2)

Portions of this post originally appeared in the March 2009 Issue of the ISSA Journal.

We just got our first severe weather scare of the year in Texas. A tornado was reported less than five miles from my house by spotters on February 11th. Some of my customers have facilities in Tornado Alley and have heavily fortified their data centers to take a direct hit by a tornado. Usually, the secondary data center is also in Tornado Alley.

Why would you put two data centers in harms way? When you run the probability calculations, the likelihood of both being destroyed is about the same as an intersection in Montana having a Starbucks on every corner ((OK, I'm going out on a limb here... if I'm wrong, just disregard the analogy and pretend like this would never happen.)).

Other parts of the world have different types of concerns like earthquakes, cyclones, and monsoons. Any of these events could easily damage or wipe out a company's operations. Companies that still believe it won't happen to them will be dealt a swift lesson in humility should an event catch them unprepared (see this post for another look at the same problem.).

The events of September 11th reminded us of an aspect of BCP/DR that we often overlook. What do we do with all the items that are not destroyed in a catastrophic event? Nature does strange things. Who would have imagined that a data theft could occur from papers flying around Manhattan after the towers came down?

Here are some of the things you need to think about when working on your BCP/DR plan.

Set up your recovery site appropriately. If your business is such that you can survive well without a particular site for a few days, then a hot site setup is not required. If you do need a hot site, then you must consider the physical and electronic security implications of synchronizing data.

Secure the backup site. If you choose to use a hot site for immediate failover, you must treat the hot site the same as your primary site. You should ensure the same level of physical security exists there to prevent burglary or theft, and that you have secured the data in transit between the sites to prevent electronic theft. Hot sites without live processing present so many challenges that several of our customers prefer to load balance between sites instead of having a primary and failover.

Reduce or eliminate risk to physical assets. If your location is in a disaster zone and sustains damage, looters will not be far behind. This means that whatever walls you depended on to keep your location secure may be damaged or destroyed. If someone is wading through a parking lot and happens to notice some nice computer equipment ready for the taking, he may be motivated to take it. Depending on where it ends up, that could easily spell a breach! Any physical asset that is at your location could be stolen. Don't leave those mounds of paper records lying around for the taking.

Make sure your communications hub is on alert. HAM radio operators will tell you that when all else fails, amateur radio will get through (I am also guilty of saying this and chasing an occasional storm or two). Depending on your requirements, it might be a good idea to have a scanner tuned to local emergency response and amateur radio frequencies (including Skywarn) for a localized disaster. You may even decide to invest in GMRS equipment to keep your emergency personnel in touch in a localized area if your cell phone fails.

Have supplies! Katrina devastated New Orleans. But during the crisis, one Internet provider stayed alive, and the guy in charge blogged about it. Read about his adventure and you will get an idea about what kinds of supplies you might need.

Remember that in times of economic crisis, small incidents are magnified. Is your company well positioned to survive a disaster caused by nature? If not, now is a good time to revisit and make sure your board has all the information they need in order to make the best decision for the business.

Posted by Branden Williams at 8:46 AM | Permalink | Comments (0)

The following is a guest post by Bindu Sundaresan, a consulting manager in our Risk & Compliance consulting practice.

With the current "non-stimulating" economy, there is a lot of talk about the "stimulus" bill which is impacting all areas of the US economy. One such impact is the reason for today's blog post.

A portion of the new economic stimulus bill, called the Health Information Technology for Economic and Clinical Health Act (the "HITECH Act"), will have a significant impact on Health Insurance Portability and Accountability Act of 1996(HIPAA). This new law revives HIPAA (which has been around for over a decade), but has many a time gone unnoticed/ not strongly enforced, and no incentive to comply, amongst the other regulatory demands.

Changes to HIPAA become effective one year after the enactment of the HITECH Act—February 17, 2010—but proactive actions have to be taken by healthcare providers and their partners in order to comply with the new law.

There is the need for some reworking and rethinking by "covered entities" and "business associates"- the terms that HIPAA created for the parties dealing with health information.

"Covered entities" include physicians, hospitals, health plans and health care clearinghouses, who store, process, or transmit health information.
"Business Associates" are those who use health information to perform services on behalf of a covered entity, such as legal, accounting, consulting or administrative work.

Highlights from the HITECH's impact on HIPAA:

• Expanded obligation and direct regulation of business associates
• New restrictions on use and disclosure of Protected Health Information (PHI), including sale and marketing
• Affirmative Notification of Breach Requirements
• Increased Enforcement and Penalties, including applicability to Business Associates
• Federal security breach notification requirement
• Useful Tips to get the ball rolling:
• Develop an inventory of your current Business Associates and third party vendors.
• Develop a PHI data flow map that maps PHI data to critical systems and assess whether the systems can meet the new standards
• Identify entities with which you share PHI that may be subject to the same privacy and security rules as covered entities and carefully manage data exchanges with them
• Get your Legal department involved now and draft new legal agreements for business associates that comply with the Act
• Update your HIPAA privacy and security policies and procedures
• Develop or modify your existing Breach Notification Policy to comply with state and federal breach notification provisions.
• Develop a comprehensive Incident Management policies and procedures framework that help achieve compliance with not only HIPAA but also other applicable regulatory requirements, industry standards, and internal requirements

Posted by Branden Williams at 6:38 AM | Permalink | Comments (2)

You know, it's kinda funny. Everywhere I go, I see how polarizing PCI DSS is. If you deal with PCI often, think about your interactions with others when discussing PCI. This is a response you have probably never heard: "Well, that PCI thing is OH-KAY. I'm not really thrilled one way or the other..."

More likely it was something like "That F&*@ing PCI DSS! I hate it!" or "God bless those PCI DSS Overlords for giving me a stick to whip my company into shape!" I tend to hear the former much more than the latter, but that demonstrates the wide difference in corporate cultures faced with PCI DSS.

Those of you screaming and complaining about PCI should stop for just a second. Do you remember why you are so upset with it? Is it like one of those big fights that you get into with your best friend, and three days later you can't remember why you were fighting in the first place? For some of you out there, maybe three years later?

Sure, PCI comes across as a big industry-wielded hammer. And when the only tool you have is a hammer, everything looks like a nail.

I think the biggest complaint I've heard about PCI (and CISP/SDP before that) was someone at a merchant or service provider screaming "HOW DARE THEY TELL ME HOW TO RUN MY BUSINESS!" Yes, screaming. Not kidding about that part folks.

When used properly, PCI can be that "stick" (as opposed to the carrot--both being motivational tools) that we security professionals have been wishing for! Using the carrot (instead of the stick) to push security along has been mildly successful in most companies.

The stick is much more effective.

As Visa learned with their Compliance Acceleration Program, if you can affect the business's bottom line with a stick, it's amazing how fast businesses will comply. Without the stick, merchants and service providers suffer from "Analysis Paralysis." In this context, they will do everything they can to over-analyze a compliance gap without taking any action to actually close the gap, thus costing them significantly more in the long run.

I hate to say this, but most of the Analysis Paralysis is actually a defense mechanism. "If I sit here an try to find a way out of fixing this gap, or I delay its decision long enough, maybe I will have gotten that promotion and it won't be my problem anymore!" Except, when the Reaper comes (that compliance deadline), Analysis Paralysis can bite employees hard. Had they taken the energy they spent on delaying the inevitable and put it towards addressing it, the soft costs associated with the fix would be dramatically lower.

"OK, so enough with the rant Brando," you are thinking right about now, "tell me what I'm "DYING" to hear. Why is this good for me?!?"

PCI is good for retailers because retailers traditionally don't think about information security when you talk to them about security. They think about shrink and fraud prevention. It's just a different mindset. But PCI DSS is NOT the scariest regulation or stick out there. In fact, PCI DSS is pretty tame when you compare it to the state data breach laws most companies are governed by nowadays (many companies not realizing they have to do something about these laws).

PCI forces the issue with companies that have immature information security programs. It calls information security to executive's attention, and forces them to take a hard look at how they currently address it. Every C-level executive I meet in the context of PCI and Information Security tells me "I don't want to be THAT CFO/CIO/CEO with my picture on the Wall Street Journal because a big breach happened on my watch."

Just like getting physically (or financially) fit, talking about change does nothing. You have to feel the burn of change! You have to EARN it. Complying with PCI and other initiatives is painful, but if you do it right, you can make sure your efforts go the distance and ultimately improve your entire data security posture.

Posted by Branden Williams at 7:10 AM | Permalink | Comments (0)

Why is Requirement 11.2 one of the most failed by merchants and service providers alike?

Requirement 11.2 has shown up here a few times, but after looking back, I never really explored the issues in detail. Those who have been unfortunate enough to attend one of my sessions where this topic came up know where you can make a mistake.

Requirement 11.2 mandates quarterly scans for all hosts in scope for PCI, both internal and external. Scope reduction techniques like segmentation can do wonders for limiting what needs to be scanned, but makes the biggest impact internally. In one of my case studies, I talk about a customer that reduced the number of in-scope systems to less than 1% of their infrastructure thanks to good network segmentation. From a risk & compliance perspective, that alone pays for any added cost associated with new equipment and maintenance.

So what's the big deal? I mean, seriously, how freaking hard is it to scan a few systems? Isn't that how security became mainstream in the first place? Vulnerability scanning? ((Tongue in cheek of course!))

The fact is, of all of the requirements in PCI, 11.2 is one that companies struggle with more than they care to admit. In more than half of the PCI assessments we did in 2008, Requirement 11.2 came up as an initial gap. If it's just scanning, why can't we get it right?

Two reasons.

Reason the First: You scanned, but you forgot to obtain CLEAN scans for every quarter. Remember, the testing procedure for Requirement 11.2 states that QSAs must "Verify that the scan process includes rescans until passing results are obtained." Just scanning is not enough, you have to scan, patch, and re-scan until you have a clean scan ((How many times shall we put "scan" into a sentence?)). Most companies do well on their external scans; it's the internal ones that trip them up. The reasoning on why this occurs is usually something like, "Well, the firewall blocks that type of connection, so you can't exploit it from the outside anyway."

Sorry chief, that doesn't cut it.

The hardest part for companies to deal with is managing the vulnerability lifecycle. Companies must play all four parts of the vulnerability management quartet: Discover, Patch, Retest, and Close. Companies tripped up by this requirement typically stop at the first or second part, leaving the rest unplayed. Try listening to a song you know well, but instead of all of the instruments, imagine what it would sound like if played by only two instruments instead of four.

Vulnerability Management is exactly that, a management process that must oversee the tactical steps required to comply with 11.2.

A QSA will require four quarters of CLEAN scans!

Reason the Second: You scanned externally, but forgot to scan INTERNALLY. Yep, strange as it is, this is actually as common as Reason the First. Back in 2004 when I first started doing CISP assessments, companies faced with complying with the monthly scan requirement (at the time, Requirement 10.2) always found some geeky tech guy from their version of the Pit of Despair to do this work. As a testament to how far information security has come in retail, guys like that are not relevant anymore. That guy has gone on to earn an MBA and maybe is a manager or director now, or maybe he just left retail and went to a company more suited to his skillset. Regardless, that guy left a gap that remains unfilled.

Expanding on the management problem described above, internal scans suffer the most. Countless companies I have worked with put internal vulnerability management on the back burner and only focus on external security threats. Remember the Armadillo Network Model? Hard crunchy exterior, soft chewy middle? Works great if you have no insider threat, and there is no chance someone might accidentally open up a vulnerable service through a mis-managed firewall change.

A QSA will require both internal AND external scans!

Don't let your next PCI Review become a PCI COMPLIANCE FAIL because this critical periodic maintenance requirement was overlooked.

Posted by Branden Williams at 6:00 AM | Permalink | Comments (2)

The following is a guest post by Matt Wilgus, Technical Services Practice Manager for VeriSign's Global Security Consulting group.

While the aforementioned question rarely gets formally asked, it is a decision information security offices deal with all the time. Often the security office also handles compliance initiatives. Given the limited resources, is it better to comply with requirements, if the opportunity cost is investing in a project which could bolster security, but not meet compliance initiatives?

If an organization is secure than the organization should likely appear secure; however, this is not always the case. The extent an organization is secure is open to perception and often boils down to risk tolerance and risk acceptance. However, what really drives tolerance and acceptance? An understanding of the business environment is the primary driver, but legislative and regulatory standards also come into play. These standards mandate organizations implement a certain level security in order to conduct business. Organizations deploy a combination of qualitative and quantitative methods to determine if they can accept the risk in a network, application or environment. Third parties also use similar methods to determine the security of an organization.

Over the past 15 years there has been plenty of legislation and regulation to bolster security in nearly every industry (e.g. HIPAA '96, GLBA '99, CISP '99/'04 PCI, NERC '03) and nearly all companies face some compliance requirements. Some of the regulation focuses more on privacy than security; however, there are plenty of commonalities. Additionally, there are federal and state related security standards (e.g. FISMA 800-53, SB 1386) and independent programs from the ISF, ISACA, ISO, etc.

The aforementioned items have improved security and generally set a decent bar, but many argue that organizations now only attempt to meet the standard. If compliance requirements didn't exist, most organizations probably would not have better security than they do today, but some would. If compliance regulations did not exist, security could become a differentiator amongst competitors. There could be a free market on security standards. One benefit would be an organization could better quantify what a security feature is worth, rather than being seen as a cost of doing business.

So it is a decision time between two solutions. Invest in Solution A with excellent coverage on compliance, but provides little in terms of additional security benefit, or invest in a Solution B with little compliance relief, but dramatically improves the quality of security? The security purest would choose the latter; however, doing so probably underestimates the "consider yourself accountable" effect (a.k.a. CYA). It also underestimates that not meeting compliance regulations creates a never ending project.

For the few organizations not governed by any regulations (i.e. those cash only, privately held, single employee entities), try to be secure. For all others, appearing secure may be good enough.

Posted by Branden Williams at 6:13 AM | Permalink | Comments (1)

The following is a guest post by Shaun Fothergill, the EMEA Practice Manager for VeriSign's Global Security Consulting group.

The tidal wave of regulatory compliance issues has intimidated the brave and petrified the frail, those who once played lip service to these issues are now looking for very serious answers from very serious questions. How do I comply? What do I need to do? What will it cost me? How do I keep compliant?

The problem is that there are so many regulatory issues we need to consider and each of these seemingly having their own security nuance that needs to be addressed.

Listed below are just some of the compliance issues businesses need to take into account:

• Data Protection Act?
• Human Rights Act?
• PCI DSS
• Access to Health Records Act?
• Sarbanes Oxley?
• International Accounting Standards?
• Proceeds of Crime Act?
• Patriot Act?
• Financial Modernisation Act (GLB)
• Money Laundering Regulations?
• RIP Act?
• Electronic Communications Act?
• Electronic Signatures Regulations?
• Electronic Commerce Regulations?
• EU Privacy directives?
• HIPAA?
• Companies Acts?
• Basel I and II?
• Freedom Of Information Act?
• Disability Discrimination Act?
• EU 8th Directive?
• Mork and Mindy common alien law?

The PCI imperative is just one compliance issue that is gathering even more momentum, in the US many institutions are now deploying compliance solutions based on many days and months of gap assessment and remediation planning. Similar initiatives are appearing in Europe and no doubt will impact Asia Pacific in the months and years to come.

But what is really at stake? What should a business really consider? What makes compliance an opportunity and not a problem? How can the pain be used positively?

Solid common sense compliance is fundamentally part of IT Governance, and IT Governance is part of business governance that is fundamentally part of sound efficient business practices.

If sound and effective business practices lead to an IT infrastructure that is more closely aligned and effective then perhaps there is another view that places regulation at the heart of making positive and effective change for business. Whilst governance and compliance are very real and serious needs there is a bigger opportunity for business and IT to collaborate and be more cost efficient. IT alignment within a business is crucial if the overall business is to be "compliant." If we consider that, then the wave of regulation is going to "hit" the organisation no matter what we think or do, would it not be better then to consider the IT/Business efficiency possibilities of regulation?

Compliance is NOT just a security issue, compliance issues reside across the entire IT stack and requires the ability to "translate" the business and compliance requirements into real solutions across the entire IT supported business. IT should where possible support a business as it addresses the regulatory landscape appropriate for its industry. Keeping in mind the "business" owns the requirement to comply.

In my view, businesses requires a framework to address the compliance stack, a baseline of IT controls and an enterprise wide management structure to keep it that way.

Many businesses have not taken the advantages of common control requirements across a range of IT compliance issues. Does your organisation have a baseline set of controls that can be managed thus providing you the ability to manage your IT infrastructure effectively? Do you have a baseline? Common industry frameworks exist, ISO270001(BS7799), ITIL, COBIT and risk processes such as COSO. All these can be leveraged to support the development of a common control construct.

For countless years IT has generally been so pressured to implement rather than have the time to design effectiveness into the systems they support for business. Perhaps now is a perfect time to work with industry frameworks ones that drives cost effectiveness and business/compliance alignment.

Its my belief that a solid compliance framework (DNA) can be used to exploit the overlap across a range of compliance issues and build in a set of common control requirements--a compliance framework and baseline. Regulation can therefore be used to crystallize focus and add significant momentum to the business.

The "opportunity" or "catalyst" should be to build a common operational control framework that could support a myriad of regulations, then demonstrate control effectiveness and exploit the common requirements thus leading to tighter effective alignment between IT and business.

IT can manage and be measured against these common elements, automate costly processes thus providing a cost effective and flexible secure IT structure tighter aligned to IT.

Compliance and regulation issues will always be with us so there is a real opportunity to build in greater business and IT effectiveness, by exploiting and building a common compliance DNA. If we build into our architectures a common set of controls, we will gain much greater business advantages. Those with insight and drive have already began this process.

These types of initiatives may just provide the opportunity to do something outstanding - construct a secure IT and Business Compliance DNA.

Posted by Branden Williams at 6:22 AM | Permalink | Comments (0)

Please join me on July 7 for an informative webcast on Maintaining PCI Compliance! To register or attend, please go to: http://www.brighttalk.com/webcasts/4431/attend.

Now that Level I merchants have undergone a few annual Payment Card Industry (PCI) assessments (and Level 2 merchants are soon to be doing the same), they are addressing the realization that a mature, sustainable compliance program requires more than once-a-year rallying to prepare for, participate in, and pass an assessment. Daily operational focus and ongoing effort are vital to protect investments in compliance, manage risk, and minimize the business disruptions and costs associated with achieving and demonstrating compliance year after year. This presentation discusses best practices for building a compliance program that can be supported and maintained year-round while also alleviating the burden on IT staff. When implemented effectively, the practices can help your company mitigate risk, reduce costs, and boost confidence in compliance by developing a cohesive plan for ongoing PCI assessment, maintenance, and refinement.

Posted by Branden Williams at 12:43 PM | Permalink | Comments (0)

The following is a guest post by Fred Langston, Sr. Product Manager for VeriSign's Global Security Consulting group.

With the stampede to the next big thing gaining speed, Cloud Computing and Cloud Services face the standard, yet utterly preventable, horse-before-the-cart security conundrum. Anytime paradigm-shifting technology that saves money and decreases operational costs hits the market, two things are certain - 1) your company, just like 99% of the other companies in your vertical, will be running with the pack straight towards rapid adoption, and 2) security tools, techniques, and control technologies to find and mitigate the huge business risks associated with the new cloud services are:

• Lacking in essential functionality, scalability, or cloud-wide scope
• Not based on well-vetted best practice policies or standards specific to each particular cloud environment (because none exist yet!)
• Not able to provide the same level of visibility and granularity in security controls your company currently employs in their non-cloud, non-virtualized IT environments

Most likely, little (if any) thought has been given by the business about exactly what your company's security requirements are for most cloud computing projects other than, "Our Cloud Services provider has assured us that..."

So, what are the InfoSec troops, fighting in the trenches, able to do to create the most secure use of Cloud Services possible, other than losing sleep? Well, anyone that knows me knows I'll spout a best practice solution for everything under the sun given a sliver of an opening. It's my nature. But, not here.

Cloud services seem to me to impose on us a devilishly more complicated, already barely tenable enterprise security tableau that we must design, implement, and operate in perpetuity. Like security's not already hard enough or not already too expensive for management. Should we just resign ourselves to the fact that essentially we can no longer provide the security we expect for those outsourced cloud services, that it's Contract's and Legal's and Audit's problem now and not ours? Or, do we demand the right to dig? To dig deep into the cloud service provider's...well, everything?

Why would we not hold a Cloud Services vendor, who's running their security infrastructure in a very similar if not identical manner as a Managed Security Services Provider (MSSP), to the same standards of service that we demand of every MSSP in the space? How logical is that? If they really are protecting the systems, networks, and data to the level they promise to contractually, why would they not have the same set of data ready to share with us about security operations in 'our cloud'? Only the Cloud provider can provide this information and that makes them an MSSP for the Cloud as well, by default. They have the firewall logs, IDS/IPS alerts, configuration data and the like for our cloud.

So, as an MSSP, I have to ask, "Where's my daily aggregated alerts, change control logs, Firewall Rule changes etc, etc?" Seems to be a double standard we really can't continue to live with if we plan on holding the line against the 'bad guys'.

Posted by Branden Williams at 6:17 AM | Permalink | Comments (0)