First, I want to establish a solid understanding of what it means to be "compliant". The term PCI Compliance is used loosely around the industry to describe an organization's status regarding their requirement to address the control objectives in the PCI Data Security Standard (DSS) or other PCI standard. However, when an organization is trying to communicate this status to its executive management and business partners, it helps to understand the nuances between compliance and validation requirements.

Compliance is not a point in time achievement. Each organization that falls under the PCI DSS requirements should work to achieve and sustain compliance with the standard by addressing all of the control objectives in the DSS either explicitly or through compensating controls. The PCI DSS includes a comprehensive list of control objectives that an organization must meet on an ongoing basis to be considered compliant with the standard. The controls apply to the entire "card data environment". PCI Security Standards Council (SSC) defines the card holder environment as the,

"Area of computer system network that possesses cardholder data or sensitive authentication data and those systems and segments that directly attach or support cardholder processing, storage, or transmission."

Separate and distinct from the mandate to comply with the PCI Data Security Standard, is the validation of compliance whereby entities verify and demonstrate their compliance status. Each card brand has prioritized and defined levels of compliance validation based on the volume of transactions, the potential risk, and exposure introduced into the payment system by merchants and service providers. The validation exercises are generally a combination of "audit" activities and technical validation actives. The audit activity can consist of an annual onsite assessment conducted by a Qualified Security Assessor (QSA) or a self assessment questionnaire. The technical validation activities include vulnerability scanning, penetration testing, and application security assessments. Additionally, each card brand has reporting requirements that direct the QSA, merchant or service provider to submit the appropriate documentation for review.

I know this may seem a bit technical, but the more familiar you are with key compliance issues, the easier it will be when you have to make decisions on behalf of your organization. I will be continuing my exploration of PCI Compliance in my next post, but encourage anyone with immediate issues, to post questions on my blog.

This may seem rather obvious but perhaps that's because I've had information security on my brain for the last 15 years or so. Most of my career I've worked with commercial clients, but I, like most information security professionals, did work in the federal space for a few years and an article published recently in the Washington Times caught me by surprise.

I found it a bit odd that the federal government was focusing on training people to test their environments "like a hacker." The article seemed a bit obvious - and certainly overdue. Politics aside, proactively testing for vulnerabilities in an IT or information security deployment is the cornerstone of ANY industry best practices (NIST or ISO anyone?). And an organization responsible for protecting our nation from threats both domestic and foreign is certainly no exception.

Then I sat back thinking about a recent call with a client. We were reviewing findings and the assumption was that the "technology implementation" had protected their organization. Our finding was that the technology was protecting the data assets but the information assets were still at risk because the people had not been trained properly. Most decision makers still view information security projects as capital expenditures (aka technology implementations). Training personnel to implement technology securely is often an afterthought or the first thing cut when budget time arrives. Perhaps the Washington Times was focusing on the right thing after all.

While NIST requires strict certification and accreditation testing procedures, it doesn't mandate any organization train its own people to question or test their own environment, find their mistakes, identify them publicly and then help fix them. If this were the case, would we need an audit department? Some argue that the requirement for separation of duties prevents accurate or effective controls testing internally. Can internal personnel be trained to think like a hacker? If so, do we think people will accurately identify and exploit vulnerabilities, finding their own mistakes? Isn't it a bit like the fox minding the chicken coop?

Security professionals are no different than most people - we don't like to expose weakness, never mind celebrate if someone else finds the mistakes first and then shows you the damage those mistakes could cause. That said, what if we started training and rotating folks so that finding vulnerabilities is applauded and required because the larger picture is more important than the goal of one person, one job, or one department. Would things change?

As information security managers, we should encourage people to test what they think they know and recognize that vulnerabilities and the ability to exploit them is an important function that we should proactively support and learn from. And perhaps we should even reward the employees if they can think past the issue and be part of the solution. So instead of a rant, perhaps, today Washington is getting it right. Let's train and invest in our people, teach them that finding

Let's train and invest in our people, teach them that finding vulnerabilities is as important as implementing technology and getting it to work, and celebrate when the good guys get there first!

First, end-point monitoring: always make sure end-users are updating their browser and plugins to the latest version (especially Flash!).

Second, I suppose companies could force a secure browser config out to end-users and train those users on their secure use. This may be more secure, but it is not cheap, and not likely to get much traction. I can't imagine trying to get Keith in Finance to understand how scripts work in his favorite websites. But if you have a smaller user base and great systems support, this could very well work in small or mid-sized organizations; and some larger organizations will really be able to enforce that level of control. This is especially relevant where companies have segmented user groups based on criticality, like PCI. Implementing something like this in all machines in the PCI zone could actually work pretty well.

The easiest method would be to shut off the Internet except for approved sites via a proxy; and by approved, I mean "business sites." As we have seen, even legitimate sites have been and are affected by this. In this day and age that's not a common occurrence; tell users they can't use the Internet anymore. But with the surge of smart and now super phones (you go, Google!); people can still get their Internet content easily so it's not the deal breaker it once was.

Realistically, the best solution is probably a 3rd party service similar to an SSL cert that attests to the validity and safety of the ads that appear on that site. Thus, before your browser loads an ad it checks with the 3rd party to confirm that ad is approved. This has been discussed before and is a long way off from becoming a reality. (Having said that Google, being Google, will probably launch this service next week).

There are several new in-the-cloud offerings that aim to proxy all Internet traffic from companies and scrub them for malicious actions such as this but they're in beta and relatively juvenile. But certainly as such an in-the-cloud offering becomes more prevalent, like Google, you can bet that the marketplace will recognize the need, and more of this type of service will spring up.

So what can be done now? Who knows? It really is up to each organization to weigh the possible solutions against their culture and risk. As much as I would like one, there is not an "easy button" for CSO's to look at to solve this issue. No silver bullet or product to buy (outside of rolling out hundreds or thousands of copies of dedicated malware protection to each PC) and each "solution" has its own unique challenges.

If there is any good news here, it is that at least to this author, this attack vector has not been used to spread many viruses and worms. Since it has been contained to individual infections, for now it has largely been a problem companies may actually be able to ignore. But will this trend stay that way for long?

While the book has NOTHING to say about information security directly, it's focused on how we as humans perceive probability and risk, the tools we have created to measure and manage probability and risk, and why we do not anticipate the most significant events that will occur.

A Black Swan is an event that is:

• Highly Improbable - difficult to predict based on historical information
• High Consequence - yields a game changing and hugely significant impact
• Retrospectively Distorted - after the fact, it seems stakeholders should have seen it coming.

An example from Taleb's book is Ceasar's Palace in Las Vegas - where the four most significant risk events had nothing to do with the conventional risk that we associate with gambling.

Those events are:

• $100M loss from a star performer being mauled by his tiger
• Disgruntled employee threatening to blow up facility with dynamite
• Un-balanced, un-monitored employee mishandling tax forms
• Kidnapping of owner's daughter

 While the casino had sophisticated methods and models to deal with "conventional" risks like controlling payout percentages and monitoring "whales" (high-stakes gamblers), in the end none of those methods or models helped predict the truly impactful events - the Black Swans.

An event from the information security world that comes to mind is the Domain Name System (DNS) vulnerability discovered in 2008. This vulnerability was so severe that the need for a concerted, expedited mass patching effort was required, and in retrospect it seems fairly obvious that the vulnerability would have existed.

I encourage you to take a look at this thought provoking book and keep an eye out for Black Swans that could appear in your organization.

People share everything. Late for dinner, shopping, bombed the test... even "going to the bathroom" are just a few examples of total TMI. But how do you really know what is too much information?

Consider how many people have been fired for bad (hrm... stupid?) Facebook postings or status updates. And even more companies use social media sites for screening job applicants.

Now put the same social media into the business world, and think about how much control you lose over available information. Sophos released the results of a study on the impact of social media. In a nutshell, companies that use social media sites tend to have more information available more easily, enabling "evil doers" to craft more effective and persistent technical and social engineering attacks. This is an information security nightmare waiting to happen.

A perfect example of the way a motivated person can use the sheer volume and type of information available on social media sites is by checking out pleaserobme.com. If you have not been there, and you care at all about personal privacy, the site is a "must visit." They grab information from social media sites, and match up information available from other social media sites. The site demonstrates how easy it is to do something like see a twitter post that "Janet" is excited that they have left for the airport to go on vacation, then taking that information, and digging up more detail about "Janet," including potentially a variety of personal information, including phone numbers, and Janet's home address. Then what?

Well, if a criminal, or angry/jealous ex-boyfriend/girlfriend/spouse, or unhappy ex-employee KNOWS where you live, and that you are out of town for a week, that's not necessarily a good thing, is it? So, how much do you really want to share?

Take the case of PCI compliance - everybody was aware of credit card thefts and cybercrimes for a long time before Visa and other card brands created their own versions of card holder security program. Even after the program was in place for over three years, companies did not take it seriously until the card brands started levying fines and sanctions. Whether you hate it or love it, there is no doubt that PCI compliance has had a huge impact in raising the security baseline on all merchants accepting credit cards.

HIPAA, which technically has been in existence since 1996, did not really take hold until early 2000s. In fact, not many organizations cared to show compliance until April 2003, which was the deadline for getting fined. The problem with HIPAA though, was that it was too vague and open to interpretation of companies or 3rd party consultants offering HIPAA Audits. With the advent of HITECH in 2009, people finally feel that HIPAA got some teeth, as the updated guidelines are now more specific and the incentives and fines for meeting compliance are clearly laid out.

As for the specificity of HITECH, there still is a lot to be achieved, leading to the arrival of the HITRUST alliance in the picture. HITRUST's CSF is the only healthcare-centric security framework that can be used by organizations of all sizes. In addition to being an amazing aid for HITECH assessment, CSF can also be used for all leading industry standards like PCI, ISO, NIST, CMS, etc. They are constantly adding new state and federal regulations that can help healthcare organizations with their compliance requirements. In fact, just last week they announced the update for Massachusetts Data Protection Reg 201 CMR 17.00 for comments from the healthcare community.

One has to wonder if HITRUST can be that impetus, that final push. Will it be the PCI compliance of healthcare that will enable CISOs and security evangelists within U.S. healthcare facilities to obtain the support and commitment required from management to offer better protection to sensitive data in their control? Time will tell - and I, for one, am excited to find out.

What's the business value? - It's important to consider whether utilizing these tools will add any real value to your organization. At the same time, the phrase "if you can't beat ‘em, join ‘em" comes into play here. If there aren't any social media activities/technologies sponsored at the corporate level, your folks will likely put something out there anyway and without your control. When this happens, it quickly spins out of control.

A company contemplating starting a blog or utilizing social networking sites should:

• Produce policies, standards and procedures
• Training regarding business strategy for use of such sites
• Update and refresh material as necessary to be sure the messages are always accurate
• Measure success and quality distribution channels

Evaluate the security and risk - The most effective way I've found to illustrate security risk is to educate by example. For instance, say you have a sales person who uses LinkedIn to create a network of business connections. Sounds great, right? Not always - anyone can easily view this person's connections and see who many of their current and past clients and co-workers may be.

Here's another example. Technical people may use support blogs and forums to post questions about challenges and problems. Again, while this certainly has value to the individual, these posts often provide huge insight into an organization's IT infrastructure. I think we can all agree attackers would love to get their hands on this type of information.

Security-related items to consider include:

• Information use guidelines and policies:
• Dictate what content can/should be published
• Comply with company's confidential guidelines
• In-line with company's image and vision
• Respect all copyrights and trademarks
• Train employees on publishing materials and document the results of this training

Don't forget to assess and review - How do you know if these sites are effective? How do you know what information is being put out "there" if you don't check for it? This is a key part to understanding effectiveness and finding examples of policy breach to utilize for training purposes.

This final step should include:

• Identify authorized persons or agencies to access social media websites
• Monitor for information leakage
• Automated tools are your friend
• Gather proof for training

I know this might seem a little overwhelming, but taking note of even a few of these could make a difference (in a good way!) for your organization. I'll continue to use this blog as a way to offer tips - keeping the line of communication open on the "risks and rewards" of social media.

I've talked to a lot of business leaders who are trying to figure out if they need to integrate social media and blogging into their marketing plans. For better or worse, the concept of social media and networking is changing the face of how consumers use the Internet, and therefore, how businesses and organizations create an online presence. Social media is the "reality TV" of the Internet and is playing a huge role in shaping the future of the online world.

Most social media tools are free. Companies pay for marketing and web services, so why not use free tools available to them online? The problem is, many social media users don't really think about how information could be used against them, or even believe anyone would share or use sensitive information in a bad way.

Enter the need for a corporate "social media policy" - simply blocking Facebook and other sites is not a solution.

Employees must be aware of what they can and cannot post and/or discuss on public blogs, forums, collaboration, help and technical forms, etc...and such posts should be monitored. You'd be surprised to know how many assessments I've performed over the years where I was able to obtain sensitive information available to the public, such as dump files, log data, network diagrams, configuration files, and yes, even user names and passwords.

Social media is also vulnerable to many threats: Web application security; data aggregation; retargeting; reputation damage, etc. Companies must assess the amount of risk they are willing to given the potential impact of a threat - and the likelihood of the threat occurring is EXTREMELY HIGH.

The bottom line is, whether your company is using social media tools/sites or not, you must have policies regarding the use of external social and collaborative sites. You should also have strategies and tools in place to measure effectiveness of their social media system, as well as information leakage. I'll be looking at this more closely in a post later this week - check back soon!

When you analyze the process undertaken to appoint the newly founded cyber security coordinator position you find it no exception. There has been, and will continue to be, debate over the ability of the latest appointee (Howard Schmidt) to move forward a national cyber security agenda without a significant budget authority. I know ...I know...it sounds like the White House is repeating one of the fundamental mistakes that the information security professionals in industry have seen time and again - no authority to enforce policy. Oh, and not to mention that within the first weeks of his appointment Schmidt was hit with the announcement of the Google vs. China situation. Between the lack of budget authority and the constant state of crisis, this program may find itself in a place where it is hard to imagine much progress.

However, with the passing of HR 4061, better known as the Cyber security Enhancement Act, the House of Representatives has taken the latest step in a march toward meaningful cyber security enhancements for the U.S. government and its people. Building on the appointments and policy statements of the Obama administration with legislation designed to build the information security professional communities through research and grants, as well as empowering the National Institute of Standards and Technology to build internationally recognized standards, has the potential to provide some much needed support to the program.

When I step back and look at the broad view, I can see that these are the kinds of steps that most information security professionals would recommend an organization take to build a strong security program. Appoint a leader > develop policy > empower business units to set standards > create a security awareness program, etc. Enforcement and funding are not small hurdles, but with each small step forward it does seem that the folks in Washington are making some progress and I like it!

Google recently announced it would pay up to $1,000 per ‘leet' or elite bug found, and a mere $500 for ‘regular' bugs in its open source code - Chromium. You may ask yourself why Google would do that. There is a good reference article on Security Focus, but I think the answer is simple - because Chromium is the platform which drives Google. Chromium is what makes Google, Google. The more Google encourages hackers - ethical or not - to find issues they can fix, the better Chromium is.

This got me thinking about our client's web-facing and internal business applications and how application developers are required to now drive their business. For a smaller client, it is an e-commerce cart used for on-line purchases; for our larger Fortune 100 clients, the application drives financial client services in the tens of millions, or more. The premise is the same - if there are bugs in the code - the business is at risk. So why not engage others to find the bugs before the bad guys do?

We still tend to think of business as brick and mortar buildings with HR, Executive Row, Marketing, Operations, Finance, etc - and, oh, by the way, Information Technology (IT), Information Security (IS) and Audit departments. In most companies, IT/IS is a cost center critical to daily operations but not often thought to drive business. Unfortunately, that type of thinking is so 1990's and may be costing the company money. As more companies use applications to drive revenue, and not just to support operations, they have to invest not only in information security but more specifically, application security. I know, I hear it - we don't have any web-facing applications that could put our organization at risk so this isn't applicable to us. Not so fast...any application that supports a critical business function - think about your financial or HR application - needs a robust Application Security program.

According to SC Magazine, over 80% of all Internet vulnerabilities are caused by poor application coding and security. If exploits for major programming codes can net bounty hunters over six figures, where and on what should your company focus?

Start by thinking of information security holistically and evaluate where and how mission critical people, processes and technology currently operate to support your business. Think about your Software Development Lifecycle (SDLC). Usually developers and programmers are incented to deliver code that works and is operationally bug-free; they are not necessarily incented to develop code that works, is bug-free, and is securely coded.

Evaluate whether you need to update your current IT/IS mission and the current SDLC. Of course this is the boring part - no new software or hardware platforms to buy and implement. As we say, no "new bright and shiny objects to play with," but secure coding, while not flashy, can help add more money to your company's bottom line. Reward the developers when code is delivered on-time, on-budget and coded securely. If you use external developers, write secure coding and testing clauses into the contract as a requirement, and include warranties when you can.

Then, make sure you have evidence that they followed your requirements. Hold developers - whether internal or external - accountable. During the next release cycle, perhaps incent the testing team (or your entire IT/IS team) by using the ‘Bugs for Sale' model. If you are a high-profile, high risk target organization, I suggest you look first to internally incent the team and then validate by a third party. Our experience shows us that clients who use secure coding practices, train their developers and programmers, and provide incentives to find bugs have less exploitable vulnerabilities when they go live. Coding never looked so alluring...

Anyone have bugs for sale?