Israeli Software

To be able to do something before it exists,
sense before it becomes active,
and see before it sprouts.

The Book of Balance and Harmony

(Chung-ho chi).
A medieval Taoist book

Will security vendors, large to small  (Symantec, Mcafee, nexTier, ANBsys and others..) succeed in restoring balance and harmony to their customers by relabeling their product suites as unified content security (Websense) or enterprise information protection (Verdasys)?

I don’t think so.

Unfortunately – data security is not an enterprise suite kind of problem like ERP. You don’t have harmony, synergy and control over business process; you have orthogonal attack vectors:

• Human error – cc’ing a supplier by mistake on a classified RFP document
• System vulnerabilities – Production servers with anonymous file transfer protocol (FTP) turned on
• Criminal activity – Break-ins, bribes and double agents (workers who spy for other groups or companies)
• Industrial competition/breach of non-disclosure agreements – the actuary who went to work for the competition

After 5 years of hype, most  customers have a high awareness of DLP products but fewer (especially outside the US) are buying DLP technologies  and even fewer are succeeding with their DLP implementations. This stems from the customer and vendors’ inability to answer two simple questions:

1. Who is the buyer?
2. What is her motivation to protect information?

A common question I hear from my clients, is, “Who should ‘own’ data security technology?” Is it the vice president, internal auditor, chief financial officer, CIO or CSO, our security consultants or our IT outsourcing vendor; IBM Global Services?

If there is no clear business need for information protection (the kind that a CEO can enunciate in a  sentence) – the company is not going to buy DLP technology.

The business need for data security derives directly from  the CEO and his management team. In firms with outsourced IT infrastructure, the need for data security becomes more acute as more people are involved with less allegiance to the firm.

To help qualify an organization’s business need for DLP technology, let’s examine the decision drivers, or what compels companies to buy data security products, and the decision-makers, or those who sign off on the products. Let’s look at seven industries: banking, credit card issuing, insurance, pharmaceuticals, telecommunications, health care and technology.

INDUSTRY	TYPICAL DATA SECURITY DRIVERS	DECISION – MAKERS
BANKING	A real event, such as theft of confidential customer account information by trusted insiders Privacy regulations such as the Gramm-Leach-Bliley Act, HIPAA The Sarbanes-Oxley Act, for transparency and timeliness in reporting of significant events	CSO or CIO
CREDIT CARD ISSUERS	Ongoing theft of customer transactional information by customer service reps Data breach threat to credit card numbers that haven’t yet been printed on plastic cards and issued to card holders Privacy regulations, Sarbanes-Oxley , nondisclosure agreements with business partners	The security officer or information security officer (many issuers have separate functions for physical and information security)
INSURANCE	A real event, such as theft of customer lists by competitors Fear of losing actuarial data Exposure to data leakage of credit card numbers in online systems	General counsel, VP of internal audit, CFO
PHARMACEUTICALS	Theft of chemistry, manufacturing and control information, product formulation and genome data by trusted insiders Difficulty in preserving secrecy of sensitive intellectual property prior to patent filings Sensitivity of company records during due diligence processes	General counsel, CFO, chief compliance officer
TELECOM/ONLINE BUSINESS (Telecom service providers and large online operations such as Yahoo collect and aggregate huge quantities of data, and the higher up the value chain you go with data aggregation, the more valuable and vulnerable the asset.)	Prepaid code files Pricing data Strategic marketing plans Call detail records (analogous to credit card transaction records, these are extrusions by customer service representatives to private investigators and difficult to detect) Customer credit card records	VP of internal audit, VP of technologies
HEALTH CARE	Privacy regulations/HIPAA Need to protect pricing data of drugs and supplies purchased by the health care organization	CSO, VP of internal audit
TECHNOLOGY COMPANIES	Theft of: Source code Designs, pictures and plans of proprietary equipment Strategic marketing plans	CEO, CTO

Compliance is about enforcing business process – for example, PCI DSS is about getting the transaction authorized without getting the data stolen. SOX is about sufficiency of internal controls for financial reporting and HIPAA is about being able to disclose PHI to patients without leaks to unauthorized parties.

So where and how does DLP fit into the compliance equation?

Let’s start with COSO recommendations for internal controls:

“If the internal control system is implemented only to prevent fraud and comply with laws and regulations, then an important opportunity is missed…The same internal controls can also be used to systematically improve businesses, particularly in regard to effectiveness and efficiency.”

At a meeting with one of our clients last week – the question of business case for data loss prevention came up quite strongly.   It started with the client saying that they were hearing that while vendors like Symantec and Websense were getting a lot of customers to buy their DLP products – many of these customers were failing at their attempt to implement DLP.

The detailed reasons why people fail at DLP implementations merits a separate post –  but it’s a lot like why over 50% of the content management implementation from vendors like Vignette never made it to production in the 90s – the root cause was that there was no real business case for the technology.

I want to talk about why  building a business case for Data security is critical to the success of your data security/data loss prevention/fraud prevention project.

If you run a business or business unit – you must ask yourself two questions

Is data security a major operational risk for your business?

Could be.

Unlike a computer virus – internally launched attacks on data  that result in data leaks, breach of  integrity, loss of data availability and non-compliance are your problem, not someone elses.

Unlike business processes – data risk cannot be outsourced.

Unlike balance sheet assets – companies don’t know their current financial exposure to data security threats.

The next question is should you invest in DLP technologies? Any one with only a nickel in their pocket (and in this market – that’s a lot of companies…) will say “Why should we when we don’t know the return on investment?  In order to answer your questions, you must measure your value at risk using a data security based risk assessment This is a simple, almost obvious notion – you measure risk of asbestos poisoning by checking your building insulation and you measure risk of fire damage by checking the building itself and various policies, procedures and equipment related to fire prevention.

Think about smoke detectors. You can’t put up an office building without smoke detectors (in Israel – the regulator has set a minimum density per square meter and the prices are low enough that the contractors will basically put in as many as you want). Why would you think of managing your data without the comparable data breach security monitoring equipment?

Data security based risk assessment uses DLP technology (the test equipment) and a best practices analytical risk model to measure the value of your data and your value at risk. Within a couple weeks, you should be able to get a picture of your current data security events, know your data value at risk in Euro and build a prioritized program for cost-effective data security controls in the people, process and technology planes. What you do then – is up to you.

Most companies I know in Europe and Israel are not at a sufficient level of security maturity to do this kind of thing themselves – and will need an independent consultant – one with specific domain expertise in their industry vertical,  specific data security expertise and ability to do analytical threat modeling – installing Checkpoint firewalls doesn’t count and you really want someone who is vendor neutral.

David Benyon from Op Risk and Compliance magazine reports

A new bribery and corruption legislation will be put before the UK parliament. Doing business using bribery would mean jail for a decade under the bill.

“The new Bribery Bill will make it far easier for companies and senior management to be prosecuted where bribes have been offered, paid or received. The new legislation will be even wider than the US Foreign Corrupt Practices Act, because it covers business-to-business transactions as well as business transactions with government or state-owned bodies,” says Neill Blundell, partner and head of the fraud group at law firm Eversheds”

After a discussion with a client today about privacy and data security in social networking, I started looking at physician portals and came across a fascinating post from Dr. Scott Shreve – Knowledge Prostitution enabling Aggregated Voyeurism: Is this a Business Model?

Voyeurism (voi-yûr’ ĭz‘əm) n.

1. The practice in which an individual derives pleasure from surreptitiously observing people.

2. Derives from the French verb voir (to see); literal translation is “seer” but with pejorative connotations.

The client told me that they were considering using a closed physicians’ portal to help market their products.  The business model used by closed, advertising-free, doctors portals (Sermo.com in the US or Konsylium24.pl in Poland) involves paying for market intelligence data collected from the “user generated content” in the community.   The tacit assumption is that physicians will talk freely inside a gated, advertising-free community.

Sermo.com kicks some of the revenue back to the users but the precision and recall of this market intelligence is not clear to me, considering the amount of noise in vertical social communities like Sermo and Konsylium24.pl and open social media like Facebook, Twitter and LinkedIn.

What is clear to me – is that there are data security and privacy implications when the community operator data-mines user-generated content for profit.  As a concrete example – a recent thread on Konsylium24.pl went something like this:

Doctor Number 1:

You know – Professor X is the KOL (key opinion leader) for company Y’s drug Z.  He says that drug Z is extremely effective for treating the indications of infectious disease Alpha.

Doctor Number 2:

Of course – Professor X is an acknowledged expert on infectious diseases, but he is also an expert on cash and knows how to do the math and add up the numbers…

I asked my client – “and for this kind of data, your parents sent you to medical school?

This took me back to the days of Firefly, Alexa, Hotbar and use of personal information as currency – collected with “collaborative filtering” and “automated inference” from people browsing the web.

Web 2.0 and social media seems to be going through a similar evolution as Web 1.0 – trying to monetize content by  data aggregation and analysis using “collaborative filtering” techniques.  This may have been a sexy looking business model for Venture Capitalists during the dot.com era, but in 2009 (5 years after Sermo.com launched) and a few months after their well-publicized breakup with the AMA; automated inference, knowledge prostitution and aggregated voyeurism may be  yielding to direct communications between people in B2B communities, social and professional networks.

Why peep through a window when you can just knock on the front door and ask?

In music, dissonance is  sound quality which seems “unstable”, and has an aural “need” to “resolve” to a “stable” consonance.

Leading up to the Al Quaeda attack on the US in 9/11, the FBI investigated, the CIA analyzed but no one bothered to discuss the impact of Saudis learning to fly but not land airplanes.

Dissonance in organizations is often resolved  by building separate silos of roles and responsibilities.

However, it is impossible to take wise decisions on risk management in the business when the risk intelligence is in separate silos.

We help protect customer data and intellectual property from fraud and breaches of confidentiality.  We’re always looking for interesting projects – call or text me at  +972 54 447 1114 at  any time.

Dissonance between IT and security management.

Mark Brewer wrote a thoughtful post on Risk in IT – I liked his use of the  term “resilient organizations”, although I have been using the term “robust organizations”.   The semantic difference between robustness and resilience may be related to the difference between IT and security management world-views.

“Risk in IT”  derives from a fundamental dissonance between information technology and security -

IT management is about planning and executing predictable business processes. Security is about planning for the the unpredictable.

This fundamental dissonance often causes a cultural schism between IT/CIO and Security/CSO. In many organizations the dissonance is amplified by two additional factors – a) splitting of physical and information security into two separate operations silos and b) external regulatory compliance.

Compliance as it pertains to security, finance and IT is often conveniently boxed into politically safe silos. OP (organizational politics) is not a bad thing, but multiple risk silos results in multiple and usually redundant costs. In addition, compliance results in the management board adopting policies that are not organically their own – which is dangerous in its own right.

The short answer to these issues is that security needs to build into (not bolt onto) the business strategy and business process itself.

Back in February 09 I noted that CVS Caremark Corp. had agreed to pay $2.25 million to settle a federal investigation into allegations that it violated HIPAA privacy regulations when pharmacy employees threw items such as pill bottles with patient information into the trash.

This morning, 9 months later – I checked the stock performance of CVS Caremark. I was curious to see if the stock had taken a hit from the HIPAA violation federal fine.  The answer is that there was no influence on stock performance and as a matter of fact CVS stock tracks the S&P 500 closely the entire period,  currently at a year high of 38.

This was not a data loss event. It was a non-compliance situation that probably didn’t constitute a very big threat to patient information/customer data.

Data security vendors like Mcafee, IBM, Fidelis Security, Symantec, Verdasys, Reconnex, Vericept, Raytheon, Websense and Checkpoint have written thousands of white papers on how their data security products can help an organization be HIPAA compliant. For example (from the Checkpoint web site:)

Health Insurance Portability and Accountability Act of 1996 (HIPAA)—HIPAA includes security standards for certain health information. NIST SP 800-66, An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule, lists HIPAA-related log management needs. For example, Section 4.1 of NIST SP 800-66 describes the need to perform regular reviews of audit logs and access reports. Also, Section 4.22 specifies that documentation of actions and activities need to be retained for at least six years.

True – but log-management  cannot mitigate dumpster-diving, nor can it prevent bulk database dumps and file transfer. Checkpoint is well-known for taking a wait-and-see strategy with data security – and similarly to other information security vendors, this seems like a case of when you have a hammer, every problem looks like a nail.

It may be easier to collect PII in small quantities from a dumpster than from an information system, but when you want large quantities of data, it’s much more effective get command line SQL access and go for the gold.

See the below example for Oracle.  Select all and save the credit card numbers in an external data file, zip the data and use secure copy to send it to a one-time instance of a Linux server in the cloud – for example on Mosso, where I can setup a server in 5′, transfer the data and then discontinue the service when I’m finished. All done in less than 15′.

SPOOL data.csv;
SELECT credit_card_number from customer_table;
END SPOOL;

Click here for the full article on CVS 2.5 million dollar fine for HIPAA violation

I recently saw a post from a blog on a corporate web site from a company called Cloud compliance, entitled “Compliance is the New Security Standard“.

Cloud Compliance provides a SaaS-based identity and Access Assessment (IdAA) solution that helps identify and remediate access control and entitlement policy violations. We combine the economies of cloud computing with fundamental performance management principles to provide easy, low cost analysis of access rights to prevent audit findings (sic) and ensure compliance with regulations such as SOX, GLBA, PCI DSS, HIPAA and NERC.

The basic thesis of the blog post was that since companies have to spend money on compliance anyhow, they might as well spend the money once and rename the effort “security”.   This is an interesting notion – although perhaps “placebo security” might be a cheaper approach.

Compliance is not equivalent to security  for several fundamental reasons.  Let’s examine this curious notion, using  PCI DSS 1.2 as a generic example of a regulatory compliance standard that is used to protect payment card numbers:

A. Filling out a form or having an auditor check off a list is not logically equivalent to installing and validating security countermeasures. A threat modeling exercise is stronger than filling out a form or auditing controls – it’s significant that threat modeling is not even mentioned by PCI DSS, despite the ROI in think time.

B. Although PCI DSS 1.2 is better than previous versions – it still lags the curve of typical data security threats – which means that even if a business implements all the controls – they are probably still vulnerable.

C. PCI DSS was designed by the card associations – there is no way that any blanket standard will fit the needs of a particular business – anymore than a size 38 regular suit will fit a 5′ 7″ man who weighs 120 kg and wrestles professionally.

D. PCI DSS talks about controls with absolutely no  context of value at risk. A retailer selling diamond rings on-line, may self-comply as a Level 4 merchant but in fact have more value at risk than then the payment processor service provider he uses. (See my previous post on Small merchants at risk from fraudulent transactions )

E. PCI DSS strives to ensure continued compliance to their (albeit flawed) standard with quarterly (for Level 1) and yearly (for everyone else) audits.   The only problem with this is that a lot of things can happen in 3 months (and certainly in a year).   The automated scanning that many Level 2-4 merchants do is essentially worthless but more importantly – the threat scenarios shift quickly these days – especially when you take into account employees and contractors who as people are by definition, unpredictable.

F. Finally – PCI DSS is a standard for whom? It’s a standard to help the card associations protect their supply chain.   It is not a policy used by the management of a company in order to improve customer service and grow sales volume.

F. PCI DSS 1.2 mandates security controls for untrusted networks and external attacks.   The phrases “trusted insider” or “business partner” are not mentioned once in the standard. This is absurd, since a significant percentage of the customer data breaches in the past few years involved trusted insiders and business partners. A card processor can be 100 percent compliant but because they have a Mafia sleeper working in IT – they could be regularly leaking credit card numbers. This is not a theoretical threat.

To summarize:

• PCI DSS is a standard for the card associations not for your business nor for your customers.
• As a security standard it is better than none at all but leaves much to be desired because it is not oriented towards the business and consumer protection

Ted Ritter has suggested that we rename DLP a Disturbing Lack of Process

Indeed DLP is not a well-defined term – since so many vendors (Kaspersky anti-virus, McAfee anti-virus, Symantec anti-virus, Trend Micro Provilla, CA Backup…you name it) have labeled their products “Data loss prevention” products in an attempt to turn the tide of data breaches into a  franchise that will help them grow sales volume.

I disagree however – that DLP might be renamed as a “Disturbing lack of process” . Not even as a joke.

I do not think that lack of business process is the issue. Any company still afloat today has  business processes designed to help them take orders, add value and make money. They understand by themselves that they must protect  their intellectual property from theft and abuse.

The question is not lack of process but whether or not security is being used to help enforce business process in the relevant areas of product safety, customer service, employee workplace security and information protection in business-to-business relationships.

In a profitable company, the business processes are aligned with company strategy to one degree or another. Good companies like Intel are strong on business strategy, process and execution while government organizations tend to be strong on strategy (President Obama) and regulation (FISMA) and short on execution (Obama Nobel Peace Prize).  This is true in most countries, maybe Germany, Singapore and Japan do a better job than most.

I think we are doing most businesses an injustice by asserting that they have a “disturbing lack of process”- instead we should focus on the question of where and how security fits into the business strategy and how it can help enforce relevant processes in the areas of customer protection and privacy, customer service, employee security and privacy and information protection with business partners.

An approach that uses data security for process enforcement automatically aligns data security with company strategy (assuming that the business processes support the company strategy, we may assume an associative relationship).

Using data security for process enforcement also simplifies DLP implementations since the number of business processes and their data models is far smaller than the number of data types and data records in the organization. Easier to enumerate is easier to protect.

It is indeed immensely easier to describe a 7 step customer service process and use DLP to enforce it than try and perform e-Discovery on 10 Terabyte of customer data contained in databases and workstations.

The 3 basic tenets of information security are data confidentiality, integrity and availability. DLP addresses the confidentiality requirement, leaving integrity and availability to other technologies and procedures that are deployed in the enterprise.

The key  to effective enterprise information protection is making information security part of enterprise business processes – for example:

• Confidentiality: not losing secret chemical formulas to the competition. (Note that credit card numbers on their own, are not confidential information according to any of the US state privacy laws. A single credit card number without additional PII is neither secret nor of much use).
• Integrity: not enabling traders to manipulate forex pricing for personal advantage.
• Availability: protecting servers from DDOS attacks.

DLP is having an uphill battle because (in the US at least), DLP technologies are point solutions deployed for privacy compliance rather than for business process enforcement and enterprise information protection.

DLP technology is best used as a process enforcement tool not as a compliance trade off;  unlike PCI DSS 1.2 section 6.6 that mandates a Web application firewall or a software security assessment of your web applications. It is easier (but perhaps more expensive) to buy a piece of technology and check off Section 6.6) than fix the bugs in your software – or … enforce your business processes.