Are you sure you do not store any payment card data or PII (personally identifiable information) in some MySQL database?

The first step in protecting credit card and customer data is to know what sensitive data you really store, classify what you have  and set up the appropriate security controls.

Here is a policy for any merchant or payment processor who want to achieve and sustain PCI DSS 2.0 compliance and protect customer data.

I. Introduction

You need to identify and apply controls to the data types identified in this policy. The data types identified below are considered digital assets and are to be controlled and managed as specified in this policy while retained or processed by the organization. You should identify and inventory all systems that store or process this information and will audit these systems on a semi-annual bases for effectiveness of controls to manage the data types.

II. Background

The Payment Card Industry (PCI) Security Standard is a requirement for all financial institutions and merchants that use or process credit card information. This security standard is designed to help protect the integrity of the credit card systems and to help mitigate the risk of fraud and identity theft to the individuals who use credit cards to make purchases for goods and services.

The PCI Security Standard was originally introduced by by VISA as the Cardholder Information Security Program (CISP) and specified the security controls for each level or merchant and credit card processor. In 2004 the major brands in the card payment industry agreed to adopt the CISP standard and requirements and a single industry standard in order to reduce the costs of implementation and assessment and increase the rate of adoption. Most organizations were required to meet all requirements of the PCI security standard by June 30^th 2005 and it is now an ongoing compliance process with merchants, payment processors and issuers.

III. General Policy Statement

All Credit Card Information and associated data is company confidential and will not be transmitted over public networks in the clear. Credit Card information can only be transmitted encrypted and only for authorized business purposes to authorized parties that have been approved to receive credit card information.

IV. Data Classifications of Credit Card Information

Personally Identifiable Information

Data Description and Policy

Any information that is collected about the owner of the credit card such as their name, signature, address, phone number or driver’s license number or social security number will be classified and controlled as PERSONALLY IDENTIFIABLE INFORMATION or PII. As a general rule to help the user identify PII data consider if a reasonable person with a reasonable level of effort could use the information to identify an individual. PII data is confidential to the organization and can only by used for specific purposes which are listed below. Only pre-authorized parties are allowed to receive PII data and only through authorized communication channels.

Examples

The following examples are for illustration only and do not necessarily comprise a complete set of all types of Personally Identifiable Information:

• Name
• Address
• Phone Number(s)
• Drivers License
• Social Security Number

Authorized Uses

• To provide customer service
• To ship products or deliver services to a customer
• To collect or process payment for products or services
• To facilitate planning or to support marketing plans

Authorized Channels for Communication

• Official Electronic Mail System of the Organization
• File Transfer Protocol
• Web Services

Controls

• Encrypt data when stored on magnetic media
• Encrypt data when transmitted over public networks
• Label as confidential when printed
• De-identify data when used for other than authorized purposes
• Retain data for no more than three years
• Destroy data upon three year anniversary

Sample DataSafe Business Rule

PII Data AND Credit Card Data in any channel will be block if unencrypted

Credit Card Information

Data Description and Policy

Credit Card Information will include the credit card number, the type of credit card (such as Visa, MasterCard, Discover, etc.) the security code and the expiration data. In addition to the basic credit card information other information such as the issuing bank or financial institution is considered part of the credit card information. Credit Card Information is considered confidential to the organization and can only by used for specific purposes, which are listed below. Only pre-authorized parties are allowed to receive Credit Card data and only through authorized communication channels.

Examples

The following examples are for illustration and are considered the comprehensive set of Credit Card Information:

• Type of Credit Card
• Name on Credit Card
• Credit card Number
• Expiration Data
• Security Code

Authorized Uses

• To provide customer service
• To support accounting or reconciliation business processes
• To investigate fraud or criminal activities
• To collect or process payment for products or services

Authorized Channels for Communication

• Official Electronic Mail System of the Organization
• File Transfer Protocol
• Web Services

Controls

• Encrypt data when stored on magnetic media
• Encrypt data when transmitted over public networks
• De-identify data when used for other than authorized purposes
• Retain data for no more than three years
• Destroy data upon three year anniversary

Credit Card Magnetic Stripe Data

Data Description and Policy

Credit Card Magnetic Stripe data is information that is automatically read through an electronic credit card reader and includes Track I and Track II data. These two tracks contain the credit card information and the name of the individual authorized to use the card as well as some other service and issuer specific information. The Credit Card Magnetic Stripe Data is considered confidential to the owner and authorized user and can only be used to process a financial transaction. Only pre-authorized parties are allowed to receive Magnetic Stripe data and only through authorized communication channels.

Examples

The following examples are for illustration and are considered the comprehensive set of Magnetic Stripe Data:

• Track I Data – 56 Bytes

• Track II Data – 35 Bytes

• Personal Identification Number

Authorized Uses

The only authorized use for Magnetic Strip Data is to complete an automated, electronic financial transaction.

Authorized Channels for Communication

• File Transfer Protocol
• Private Line or VPN
• Web Services

Controls

• Electronic storage on magnetic media is not allowed – zero retention
• Encrypt data when transmitted over public networks

Credit Card Transaction Data

Data Description and Policy

Transaction data is collected at a point of sale and will often include items purchased, credit card information, date and time, authorization code and transaction amount. These transaction details are confidential to the organization and can only by used for specific purposes, which are listed below. Only pre-authorized parties are allowed to receive Credit Card Transaction data and only through authorized communication channels.

Examples

The following examples are for illustration only and do not necessarily comprise a complete set of all types of Credit Card Transaction Data:

• Authorization Code
• Transaction Number
• Name
• Amount

Authorized Uses

• To process or collect payment for products or services
• To reconcile all financial accounting
• To provide customer service

Authorized Channels for Communication

• Official Electronic Mail System of the Organization
• File Transfer Protocol
• Web Services

Controls

• Encrypt data when stored on magnetic media
• Encrypt data when transmitted over public networks
• De-identify data when used for other than authorized purposes
• Retain data for no more than three years
• Destroy data upon three year anniversary

Last year I gave a talk on quantitative methods for estimating operational risk of information systems in the annual European GRC meeting in Lisbon – you can see the presentation below.

As a I noted in my talk, one of the crucial phases in estimating operational risk is data collection: understanding what threats, vulnerabilities you have and understanding not only what assets you have (digital, human, physical, reputational) but also how much they’re worth in dollars.

Many technology people interpret data collection as some automatic process that reads/scans/sniffs/profiles/processes/analyzes/compresses log files, learning and analyzing the data using automated  algorithms like ANN (adaptive neural networks).

The automated log profiling tool will then automagically tell you where you have vulnerabilities and using “an industry best practice database of security countermeasures”,  build you a risk mediation plan. Just throw in a dash of pie charts and you’re good to go with the CFO.

This was in fashion about 10 years ago (Google automated audit log analysis and you’ll see what I mean) for example this reference on automated audit trail analysis,  Automated tools are good for getting a quick indication of trends, and  tend to suffer from poor precision and recall that  improve rapidly when combined with human eyeballs.

The PCI DSS council in Europe (private communication) says that over 80% of the merchants/payment processors with data breaches  discovered their data breach  3 months or more after the event. Yikes.

So why does maintaining 3 years of log files make sense – quoted from PCI DSS 2.0

10.7 Retain audit trail history for at least
one year, with a minimum of three
months immediately available for
analysis (for example, online, archived,
or restorable from back-up).
10.7.a Obtain and examine security policies and procedures and
verify that they include audit log retention policies and require
audit log retention for at least one year.
10.7.b Verify that audit logs are available for at least one year and
processes are in place to immediately restore at least the last
three months’ logs for analysis

Wouldn’t it be a lot smarter to say -

10.1 Maintain a 4 week revolving log with real-time exception reports as measured by no more than 5 exceptional events/day.

10.2 Estimate the financial damage of the 5 exceptional events in a weekly 1/2 meeting between the IT manager, finance manager and security officer.

10.3 Mitigate the most severe threat as measured by implementing 1 new security countermeasure/month (including the DLP and SIEM systems you bought last year but haven’t implemented yet)

I’m a great fan of technology, but the human eye and brain does it best.

The essay below by professor Avinash Persaud considers the creation of a terrorism futures market. The ideas are particularly timely in the context of the unrest in Libya and the uptick in oil prices.

Right now, the closest thing we have to “terrorist futures” are crude oil futures. One way of looking at them is as a loose proxy for the sell-by date on the Saudi monarchy. For example, oil prices above $99 would be a function of geopolitical instability, and not just the supply-demand dynamic.

Futures prices convey information in its raw form. They tell you what individual participants are betting on and how they’re evaluating risk.  They tell us something about Quaddaffi. Even if Libya is not a major oil producer, Muamer Quaddaffi is a major source of instability.

Can a Country Take out Financial Insurance Against Macro-Risks Like Currency Instability or Global Terrorism?
by Professor Avinash Persaud

Good evening, ladies and gentlemen. I would like to begin today by discussing the link between the personal insurance you and I take out every day and financial futures markets. I will then turn to a proposal to establish a terrorism futures market and how that would work. I will address the moral objections to such a market and its possible benefits to our democracy. It should be a thought-provoking tour.

There is a gap between what the public expects from an auditor and how auditors understand their role.

Auditors look at transactions and controls. They’re not the business owner and the more billable hours, the better.

The “reasonable person” assumes that the role of the security auditor is to uncover vulnerabilities, point out ways to improve security and produce a report that will enable the client to comply with relevant compliance regulation. The “reasonable person” might add an additional requirement of a “get out of jail free card”, namely that the auditor should produce a report that will stand up to legal scrutiny in times of a data security breach.

Auditors don’t give out “get out of jail” cards and audit is not generally part of the business risk management.

The “reasonable person” is a legal fiction of the common law representing an objective standard against which any individual’s conduct can be measured. As noted in the wikipedia article on the reasonable person:

This standard performs a crucial role in determining negligence in both criminal law—that is, criminal negligence—and tort law. The standard also has a presence in contract law, though its use there is substantially different.

Enron, and the resulting Sarbanes-Oxley legislation resulted in significant changes in accounting firms’ behavior,but judging from the 2009 financial crisis from Morgan Stanley to AIG, the regulation has done little to improve our confidence in our auditors. The numbers of data security breaches are an indication that the situation is similar in corporate information security.  We can all have “get out of jail” cards but data security audits do not seem to be mitigating new risk from tablet devices and mobile apps. Neither am I aware of a PCI DSS certified auditor being detained or sued for negligence in data breaches at PCI DSS compliant organizations such as Health Net where 9 data servers that contained sensitive health information went missing from Health Net’s data center in Rancho Cordova, California. The servers contained the personal information of 1.9 million current and former policyholders, compromising their names, addresses, health information, Social Security numbers and financial information.

The security auditor expectation gap has sometimes been depicted by auditor organizations as an issue to be addressed  by educating users to the audit process. This is a response not unlike the notion that security awareness programs are effective data security countermeasures for employees that willfully steal data or bring their personal device to work.

Convenience and greed tend to trump awareness and education in corporate workplaces.

Here are 10 guidelines that I would suggest for client and auditor alike when planning and executing a data security audit engagement:

1. Use an engagement letter every time. Although the SAS 83 regulation makes it clear that an engagement letter must be used, the practical reason is that an engagement letter sets the mutual expectations, reduces risk of litigation and by putting mutual requirements on the table – improves client-auditor relationship.

2.Plan. Plan carefully who needs to be involved, what data needs to be collected and require input from C-level executives to  group leaders and the people who provide customer service and manufacture the product.

3. Make sure the auditor understands the client and the business.  Aside from wasted time, most of the famous frauds happened where the auditors didn’t really understand the business.   Understanding the business will lead to better quality audit engagements and enable the auditor and audit manager to be peers in the boardroom not peons in the hallway.

4. Speak to your predecessor.   Make sure the auditor talks to the people who came before him.  Speak with the people in your organization who did the last data security audit.   Even if they’ve left the company – it is important to understand what they did and what they thought could have been improved.

5. Don’t tread water. It’s not uncommon to spend a lot of time collecting data, auditing procedures and logs and then run out of time and billable hours, missing the big picture which is” how badly the client organization could be damaged if they had a major data security breach”. Looking at the big picture often leads to audit directions that can prevent disasters and  subsequent litigation.

6. Don’t repeat what you did last year.  Renewing a 2,000 hour audit engagement that regurgitates last years security check list will not reduce your threat surface.  The objective is not to work hard, the object is to reduce your value at risk, comply and …. get your “get out of jail card”.

7. Train the client to fish for himself.   This is win-win for the auditor and client. Beyond reducing the amount of work onsite, training client staff to be more self sufficient in the data collection and risk analysis process enables the auditor to better assess client security and risk staff (one of the requirements of a security audit) and improves the quality of data collected since client employees are the closer to actual vulnerabilities and non-compliance areas than any auditor.

As I learned with security audits at telecom service providers and credit card issuers, the customer service teams know where the bodies are buried, not a wet-behind-the-ears auditor from KPMG.

8. Follow up on incomplete or unsatisfactory information.  After a data security breach, there will be litigation.  During litigation, you can always find expert testimony that agrees with your interpretation of information but -

The problem is not interpreting the data but acting on unusual or  missing data.  If your ears start twitching, don’t ignore your instincts. Start unraveling the evidence.

9. Document the work you do.  Plan the audit and document the process.  If there is a peer review, you will have the documentation showing the procedures that were done.  Documentation will help you improve the next audit.

10. Spend some time evaluating your client/auditor.   At the end of the engagement, take a few minutes and interview your auditor/client and ask performance review kinds of questions like: What do think your strengths are, what are your weaknesses?  what was succesful in this audit?  what do you consider a failure?   How would you grade yourself on a scale of 10?

Perhaps the biggest mistake we all make is not carefully evaluating the potential we have to meet our goals as audit, risk and security professionals.

A post-audit performance review will help us do it better next time.

The question is, what will be the data security  impact of LTE deployments? As LTE is IP based and IPv6 becomes more common in the marketplace, will the security requirements of mobile devices become similar to traditional networked devices?  There is already a huge trend  for BYOD or Bring Your Own Device to work, which certainly causes a lot of headaches for information security staffs. Will more bandwidth and flat IP networks of LTE increase the threat surface for corporate IT?

Other than higher performance, LTE features a flat IP network, but I don’t see how that increases the threat surface in any particular way.  The security requirements for mobile networked devices are similar to traditional wired devices but the vulnerabilities are different, namely the potential of unmanaged BYOD tablet/smartphone to be an attack vector back into the enterprise network and to be a channel for data leakage.  The introduction of Facebook smart phones is far more interesting as a new vulnerability to corporate networks than smart phones with a 100MB download and 20MB upload afforded by LTE.

I am not optimistic about the capability of a company to manage employee owned mobile devices centrally and trying to rein in smartphones and tablets with awareness programs.  Instead of trying to do the impossible or the dubious, I submit that enterprise that are serious about mobile data security must take 3 basic steps after accepting that BYOD is a fact of life and security awareness has limited utility as a security countermeasure.

1. Reorganize physical, phones and information security into a single group with one manager.  This group must handle all data, software IT, physical (facilities) and communications issues with a single threat model driven by the business and updated quarterly. There is no point in pretending that the only phones used by employees are phones installed and operated by the companies telecom and facilities group. That functionality went out the door 10 years ago.
2. Develop a threat model for the business – this is  key to being able to keep up with rapidly growing threats posed by BYOD.  Update that model quarterly, not yearly.
3. CEO must take an uncompromising stance on data leaks and ethical employee behavior. It should be part of the company’s objectives, measurable in monetary terms just like increasing sales by 10% etc.

Some of these steps are about not drinking consultant coolade (like Step # 1- Do not be tempted into an expensive business process mapping project) and others are adopting best practices that work for big business (like Step #5 – Monitor your business partners)

Most of all, the 7 steps are about thinking through the threats and potential damage.

Step # 1- Do not be tempted into an expensive business process mapping exercise
Many consultants tell businesses that they must perform a detailed business process analysis and build data flow diagrams of data and business processes. This is an expensive task to execute and extremely difficult to maintain that can require large quantity of billable hours. That’s why they tell you to map data flows. The added value of knowing data flows between your business, your suppliers and customers is arguable. Just skip it.

Step #2 – Do not punch a compliance check list
There is no point in taking a non-value-added process and spending money on it just because the government tells you to. My maternal grandmother, who spoke fluent Yiddish would yell at us: ” grosse augen” (literally big eyes) when we would pile too much food on our plates. Yes, US publicly traded companies are subject to multiple regulations. Yes, retailers that  store and processes PII (personally identifiable data)  have to deal with PCI DSS 2.0, California State Privacy Law etc. But looking at all the corporate governance and compliance violations, it’s clear that government regulation has not made America more competitive nor better managed.  It’s more important for you to think about how much your business assets are worth and how you might get attacked than to punch a compliance check list.

Step #3 – Protecting your intellectual property doesn’t have to be expensive
If you have intellectual property, for example, proprietary mechanical designs in Autocad of machines that you build and maintain, schedule a 1 hour meeting with your accountant  and discuss how much the designs are worth to the business in dollars. In general, the value of any digital, reputational, physical or operational asset to your business can be established fairly quickly  in dollar terms by you and your accountant – in terms of replacement cost, impact on sales and operational costs.  If you store any of those designs on computers, you can get free open-source disk encryption software for Windows 7/Vista/XP, Mac OS X, and Linux. That way if there is a break-in and the computer is stolen, or if you lose your notebook on an airport conveyor belt, the data will be worthless to the thief.

Step #4 – Do not store Personally identifiable information or credit cards
I know it’s convenient to have the names, phone numbers and credit card numbers of customers but the absolutely worst thing you can do is to store that data. VISA has it right. Don’t store credit cards and magnetic strip data. It will not help you sell more anyway, you can use Paypal online or simply ask for the credit card at the cash register.  Get on Facebook and tell your customers how secure you are because you don’t store their personal data.

Step #5 – Don’t be afraid of your own employees, but do monitor your business partners
Despite the hype on trusted insiders, most data loss is from business partners. Write a non-disclosure agreement with your business partners and trust them, and audit their compliance at least once a year with a face-to-face interview.

Step #6 – Do annual security awareness training but keep it short and sweet
Awareness is great but like Andy Grove said – “A little fear in the workplace is not necassarily a bad thing”. Have your employees and contractors read, understand and sign a 1 page procedure for information security.

Step #7 – Don’t automatically buy whatever your IT consultant is selling
By now – you are getting into a security mindset.  Thinking about asset value, attacks and cost-effective security countermeasures like encryption. Download the free risk assessment software and get a feel for your value at risk.  After you’ve done some practical threat analysis of your business risk exposure you will be in an excellent position to talk with your IT consultant. While most companies don’t like to talk about data theft issues, we have found it invaluable to talk to colleagues in your market and get a sense of what they have done and how well the controls perform.

In this post I want to talk about 5 mistakes CIOs make:

1. Rely on fixed controls

Any information security professional will tell you that security countermeasures are comprised of people, processes and technology.  The only problem is that good security depends on stable people, processes and technology. A stable organization undergoing rapid and violent change is an oxymoron.  Visualize your company has ISO 27001 certification but the stock drops by 90% because of an options back-dating scandal at the top, the company fires 900 employees and all of a sudden, the fixed controls are not as effective as you thought they were.  Think about the Maginot Line in WWII.

2. Train for security awareness

Security awareness training is probably a hopeless waste of resources considering the increasing number of options that people have (Facebook, smartphones..) to do stuff that causes damage to the business.Security awareness will lose every time it comes up against an iPad or Facebook.

People countermeasures should be a mix of common-sense, background checks (at a depth proportional to job exposure to sensitive assets), and deterrence.  Andy Grove once said “Despite modern management theory regarding openness – a little fear in the workplace is not a bad thing”.  When a lot of employees are RIF‘d – there is a lot of anger and people who don’t identify with their employer; the security awareness training vaporizes and fear and revenge take over. Some of the security people will be the first to go, replaced by contractors who may not care one way or the other or worse – be tempted by opportunities offered by the chaos.

Why is  common sense a good alternative to awareness training? Common sense  is easy to understand and enforce if you keep it down to 4 or 5 rules:  maintain strong passwords, don’t visit porn sites, don’t blog about the business, don’t insert a disk on key from anyone and maintain your notebook computer like you guard your cash.

3. Manage GRC processes (while the hackers are attacking your software)

It’s a given that business processes need to be implemented in a way that ensures confidentiality, integrity and availability of customer data.  A simplistic example is a process that allows a customer service representative to  read off a full credit card number to a customer. That’s a vulnerability that can be exploited by an attacker.  But – that’s a trivial example – while you’re busy managing processes and using security theater code words – the attackers are attacking your software and stealing your data.

4. Rely on defense in depth (instead of questioning your defenses)

Technology countermeasures are not a panacea – and periodically you have to step back and take a look at your security portfolio both from a cost and effectiveness perspective.  You probably reply on a defense in depth strategy but end up with multiple, sometimes competing and often ineffective tools at different layers – workstation, servers and network perimeter.

Although defense-depth is a sound strategy – here are some of the fault lines that may develop over time:

5. Align with the business (instead of investing in competence)

Business alignment is one of those soft skill activities that keep people in meetings instead of mitigating systems vulnerabilities – which requires hard professional skills and high levels of professional security competence. It’s a fact of life that problem solvers hate meetings and rightly so – you should invest in competence and go light on the business alignment since it will never stop the next data breach.

Claudiu Popa, president and chief security officer of data security vendor Informatica Corp. told  Robert Westervelt in an interview  on searchsecurity.com that:

…once an organization reaches the right level of maturity, security measures will not only save time and money, but also contribute to improved credibility and efficiency.

This is nonsense – security is a cost  and it rarely contributes to efficiency of a business (unless the business can leverage information security as part of it’s marketing messages) and as  for an organization firing 30% of it’s workforce over night – words like maturity, credibility and efficiency go out the door with the employees.

At that point –  highly competent and experienced security professionals who are thinking clearly and calmly are your best security countermeasure.

The notion of a security consultant guild is a seductive idea.  Promoting  quality, defining service levels and enhancing professional standing are good  things, but there is a red ocean of professional forums so – I would not just jump in and start a guild.

Just take a look at forums like LinkedIn and Infosec Island – most (sometimes it feels like all…) of the folks in professional networks are independent  consultants – and that makes perfect sense – we all have to eat. Yet LinkedIn cannot replace industry forums like ISACA or ISC2 that work to promote industry standards, improve security awareness, drive private-public partnerships etc.

The problem with ISC2 and similar industry lobbies – is that they have vested interests, therefore they don’t or can’t represent independent security consultants.  When was the last time Raytheon called me up – asking to collaborate on a data security project for DoD – like never?

I would take some lessons from the IETF.

Any security consultant organization should have three principles: free, open, and based on vendor-neutral standards.

Note my emphasis on “Vendor-neutral standards”.  This is the secret of the success of the IETF and the Internet in general and it will be the core of the success for any group of security consultants that want to do more than kibitz in LinkedIn security forums.

Regarding standards. There is this eternal debate between the US and the EU – but I think that we can probably agree that ISO 2700x is the most comprehensive, vendor-neutral standards framework existing today – and that should be the one vendor-neutral standard adopted by the guild.

However a guild of consultants is not enough.

We already have similar entities in the shape of the Linked In security communities – which are in general a bunch of consultants talking to each other – with endless threads with shallow input generated by  open-ended questions like “What is the best anti-virus” or “What is the best firewall” or “How should I choose a UTM appliance” or “Is confidentiality, integrity and availability part of your security strategy?”.

In order to turn a consultants guild into something of value – (and I mean dollars and cents – not social networking gratification) the  guild most include and engage (using it’s own terms of engagement of free, open and vendor-neutral standards) with 3 other kinds of people:

1. End user line of business decision makers

2. Vendors

3. Hackers

I am aware that this is a tall bill of requirements – but is, I believe, the only way to create something unique with value to all.

Consider this:

Your security defenses don’t improve your understanding of the root causes of data breaches, and without understanding the root causes –  your best shot is not good enough.

Why is this so?

First of all – defenses are by definition, not a means of improving our understanding of strategic threats. Think about the Maginot Line in WWI or the Bar-Lev line in 1973. Network and application security products that are used to defend the organization are rather poor at helping us understand and reduce the operational risk of insecure software.

Second of all – it’s hard to keep up.  Security defense products have much longer product development life cycles then the people who develop day zero exploits. The battle is also extremely asymmetric – as it costs millions to develop a good application firewall that can mitigate an attack that was developed at the cost of three man months and a few Ubuntu workstations. Security signatures (even if updated frequently) used by products such as firewalls, IPS and black-box application security are no match for fast moving, application-specific source code vulnerabilities exploited by attackers and contractors.

Remember – that’s your source code, not Microsoft.

Third – threats are evolving rapidly. Current defense in depth strategy is to deploy multiple tools at the network perimeter such as firewalls, intrusion prevention and malicious content filtering. Although content inspection technologies such as DPI and DLP are now available, current focus is primarily on the network, despite the fact that the majority of attacks are on the data – customer data and intellectual property.

The location of the data has become less specific as the notion of trusted systems inside a hard perimeter has practically disappeared with the proliferation of cloud services, Web 2.0 services, SSL VPN and convergence of almost all application transport to HTTP.

Obviously we need a better way of understanding what threats really count for our business. More about that in some up coming posts.