Israeli Software

Operational risk management has been the buzz word du-jour in recent years, due to the Basel II initiative in the banking industry and Solvency II in the insurance industry.

The Basel II definition of operational risk is “the risk of loss resulting from inadequate or failed internal processes, people and systems, or from external events.”

It seems that in the middle of the great financial crisis, TARP, unmet calls for transparency and trillions being sunk into the US financial services industry (instead of encouraging innovation, manufacturing and creation of free cash flow…), Basel II deserves to be judged and found wanting.

Perhaps we need to update the Basel II definition of operational risk and bring it into line with a modern set of threats. For example, we might say, let’s add to the Basel II definition, “… and risks due to networking with other businesses”. This is a reasonable addition, since in my experience in data security projects and according to the Verizon security breach reports,  over 70% of data loss incidents involve outsourcing and sub-contractors.

External business partnerships are indeed, a source of risk for financial institutions that do business process outsourcing (especially if one considers data loss) but it appears to me that the Basel II and Solvency II definitions  are  less appropriate for the technology and manufacturing industries, where  innovation and product development are performed by relatively small engineering teams and key assets are product quality and customer safety and not credit cards in database servers.

Let’s take the example of a company that makes a robot to assist in micro-surgery.

For the medical device company, the biggest operational risk  is a flawed product that might damage a patient. The FDA sees this as a regulatory issue and addresses it with the 510(K) but my gut feeling is that most small (4-6 people)  software development teams don’t really have a “process”.  After an audit by a regulatory affairs consultant, they can comply and still fall hard on a software defect or design flaw.

It’s amazing to me that the Basel II definition of does not consider customer safety as an  operational risk, and yet, the lack of customer safety and networked-business risks in the Basel II definition only serves to illustrate the futility of a check list approach to operational risk management.

Since regulatory compliance is not a substitute for analyzing particular threats to a particular business unit,  I would propose a different definition of op risk:

“Any combination of one or more threats that exploits vulnerabilities to damage company assets as measured in dollars (or euro or yen ….)”

This definition is universally applicable to financial services, IP developers, manufacturing, distribution, health care, bio med etc…The definition does not limit business management to risk analysis inside the company but enables a company to consider threats due to product quality, compliance, extended business relationships, PHI, PII and a whole slew of new risks that don’t even exist yet on their current threat surface.

It’s a definition that forces the company executives to ask themselves what are their key threats and assets and vulnerabilities and how much of the company value is at stake.

Threat models are not a silver bullet solution to prevent a crisis like AIG on one hand or Toyota on the other. A threat model is only a tool to implement a risk strategy by the business management. Threat modeling  needs to be used in the proper way, measured in dollar values and must be reviewed regularly – at least once/year.

The beauty of the above definition is that it links operational risks to business operations.

Any business in any vertical, must define their own threat landscape, define their control/security countermeasure strategy, run their own risk assessment regularly and  insure that their data security and regulatory compliance policies, procedures and systems are aligned with the latest version of their threat model.

Read more about threat modeling and operational risk management on this blog.

There is a school of thought that says that you can take any complex problem and break it down like swiss cheese. Risk assessment data collection and analysis with Excel is one of those problems that can’t be swiss-cheesed.  A collection of brittle, unwieldy, two dimensional worksheets is a really bad way of doing multi-dimensional modelling.

Consider that a typical risk assessment exercise will have a minimum of 4 dimensions (assets, threats, vulnerabilities and controls) and I think you will agree with me that Excel is a poor fit for risk assessment.

Here is where PTA (Practical Threat Analysis) comes to the rescue. You can download the free risk assessment software and try it yourself.

Any risk assessment process can be automated using Practical Threat Analysis and the PTA threat modeling database.  PTA is a threat modelling methodology and software tool that has been downloaded over 15,000 times and has thousands of active security analyst users on a daily basis.

PTA (Practical Threat Analysis) was first introduced in a paper by Ygor Goldberg titled “Practical Threat Analysis for the Software Industry” published online at Security Docs in October 2005. PTA provides a number of meaningful benefits for security and compliance risk assessments:

• Quantitative: enables business decision makers to state asset values, risk profile and controls in familiar monetary values. This takes security decisions out of the realm of qualitative risk discussion and into the realm of business justification.
• Robust: enables analysts to preserve data integrity of complex multi-dimensional risk models versus Excel spreadsheets that tend to be unwieldy, unstable and difficult to maintain.
• Versatile: enables organizations to reuse existing threat libraries in new business situations and perform continuous risk assessment and what-if analysis on control scenarios without jeopardizing the integrity of the data.
• Effective: recommends the most effective security countermeasures and their order of implementation. In our experience, PTA can help a firm mitigate 80% of the risk at 20% of the total control cost.

The PTA calculative model is implemented in a user-friendly Windows desktop application available as a freeware at the PTA Technologies web site. A PTA ISO 27001 library is available as a free download and is licensed under the Creative Commons Attribution License.

The need for cost effective risk reduction

Despite the importance of privacy and governance regulation, compliance is actually a minimum but not sufficient requirement for risk management.

The question is: What security controls should a firm implement after a risk assessment?

Taking ISO 27001 as a baseline security standard with a comprehensive set of controls, the ISO 27001 certification process can be as simple or as involved as an organization wants but there are always far more available controls than threats. As a result, organizations, large and small, find themselves coping with a long and confusing shopping list of controls. You can implement the entire checklist of controls (if you have deep pockets), you can do nothing or you can try and achieve the most effective purchase and risk control policy (i.e. get the most for your security investment dollar) with a set of controls optimized for your business situation.

However, implementing additional controls does not necessarily reduce risk.

For example, beefing up network security (like firewalls and proxies) and installing advanced application security products is never a free lunch and tends to increase the total system risk and cost of ownership as a result of the interaction between the elements and an inflation in the number of firewall and content filtering rules.

Firms often view data asset protection as an exercise in Access Control (Section 11 of ISO 27001) that requires better permissions and identity management (IDM). However, further examination of IDM systems reveals that (a) IDM does not mitigate the threat of a trusted insider with appropriate privileges and (b) the majority of IDM systems are notorious for requiring large amounts of customization (as much as 90% in a large enterprise network) and may actually contribute additional vulnerabilities instead of lowering overall system risk.

The result of providing inappropriate countermeasures to threats is that the cost of attacks and security ownership goes up, instead of risk exposure going down.

How to choose cost-effective controls

A PTA threat model enables a risk analyst to discuss risk in business terms with her client and construct an economically justified set of security controls that reduces risk in a specific customer business environment. A company can execute an implementation plan for security controls consistent with its budget instead of using an  all-or-nothing checklist designed by a committee of experts who all work for companies 100x the size of your operation.

How does your company mitigate the risk of data security threats?

Is your company management adopting a policy of “It’s other peoples money”?

In a recent thread on LinkedIn - Jody Keyser shared some quotes from David Vose’s book on risk, reliability and computerized risk modeling:  Risk Analysis a quantitative guide.

The responses to correctly identified and evaluated risks are many but generally fall into one of the following categories:

- Cancel Project
- Eliminate ( do it another way)
- Transfer (insure back to back contract)
- Share (with partner or contractor )
- Reduce (take a less risky approach)
- Add a contingency (increase budget, deadline etc.,to allow for possibility of risk)
- Collect more data to better understand risk
- Do nothing (cost is just too dang high)
- Increase ( maybe the plan is too cautious )

In my experience – when it comes to data security, data loss prevention, DLP projects – the top 2 responses to data security threats are “accept the risk” followed by “cancel the project” in a close second place.

The other alternatives are almost all non-starters. The question is – why?

Eliminating risk by changing the business process is often not an option or too much trouble for employees. For example – consider the process of transferring documents to external contractors – even though it’s trivial to encrypt documents inside a Zip file and share the password – most companies don’t make it part of their security procedure and those that do require encryption of documents sent to external business partners, don’t deploy DLP monitoring to ensure compliance with the encryption policy.

There are multiple reasons for data security risk being accepted by business managers.  Most are related to cost, complexity, changing business requirements and a tacit disbelief in effectiveness of technology in preventing data theft and fraud.

The reasons for accepting data security risk are related to  the difference between being secure and feeling secure.  Since most companies don’t monitor data flows, they don’t know how many sensitive digital assets are being leaked to the competition – ergo they don’t have the empirical data to analyze their data security threats and measure data security risks in terms of dollar threat to the business.  This would lead to enable a business to deploy data security countermeasures and be secure at an acceptable cost. It would also enable them to measure the cost effectiveness of their data security technology and challenge their innate beliefs and skepticism.

However – the company management already feel secure because they have delegated that part of  the business to the information security folks and reading the papers tells them that customers (not the business management) pay the cost of a data security breach.

As a kid growing up in South Jersey – when there was the occasional report of an urban boondoggle or million dollar NASA toilets – my Dad (who worked for RCA on defense projects and knew about these things) would always use the expression – “Other peoples money” or if it was closer to home – “Pa’s rich and Ma don’t care”…which is really close to home this year for Americans as President Obama takes the US to an unprecedented $1.35 trillion budget deficit in  2010.

One of the famous canons in the Jewish Passover “seder” ritual is 4 questions from 4 sons – the son who is wise, the son who is wicked, the son who is innocent and the son who doesn’t know enough to ask.

I sometimes have this feeling of Deja vu when considering data security technology solutions. Although the analogy is not at all parallel – I have written a list of 4 questions to be asked when considering a DLP solution – these questions require clear, authoritative answers just like in the Passover seder (להבדיל).

1. What is the key threat scenario?
2. How much Value at Risk is on the table?
3. Who owns the project?
4. Does the DLP technology fit the threat scenario?

1 – What is the key threat scenario?

Here are some typical threat scenarios – the key threat scenario should keep a C-level executive awake at night.

See http://www.software.co.il/wordpress/2010/02/is-there-a-business-need-for-dlp/

2 – What is your value at risk?

Once you have identified the key threat scenario, you must know how much value at risk is generated when a threat exploits vulnerabilities to cause damage to assets. The basis for measuring VaR (value at risk) is the asset value (generally determined by the CFO) -

VaR = asset value x threat probability x estimated damage to asset value in a percentage

The VaR is reduced by a set of security countermeasures that also have a cost. VaR is best calculated in a data security based risk assessment that uses DLP technology to measure frequencies of threat occurrence and a calculative threat model to derive VaR.

Most companies are not at a sufficient level of security maturity to do this exercise themselves – and will need an independent consultant with specific data security expertise and the ability to do analytical threat modeling.

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 DLP countermeasures.

See http://www.software.co.il/wordpress/2010/01/building-a-business-case-for-dlp/

3 – Who owns the project?

Beware of organizational politics and silos and conflicting agendas.  Need I say more?

4 – Does the DLP technology fit the threat scenario?

Just because the vendor sold you an anti-virus product doesn’t mean that his DLP technology is a good fit (even if it’s free)

Example A:  A network DLP solution may be required with 1GB throughput, if the technology saturates at 200MB/S then the solution is not a good fit.

Example B:  An agent DLP solution may be required that is capable of identifying IP in AutoCAD files; if the content analysis software is incapable of decoding AutoCAD, then the countermeasure does not mitigate the vulnerability.

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.

A client recently asked:

How do I assign a dollar value to an assets?…should I use the  purchase value of the asset, replacement value or expected damage to the company if the asset were stolen or exploited?

Estimating asset value is without doubt the most frequent question we get when it comes to calculating data security risk in monetary terms. There are several practical guidelines for measuring information assets value:

• Use the right metric – a common mistake made by marketeers who work for data security vendors is to estimate the cost of a data security breach as the number of records multiplied by some plug number.  The cost of a data security breach to a company is not the same as the cost of a customer data record breach to a customer.  A customer may not even know that her credit card number is breached (considering that 250 million credit card numbers have been stolen in the past few years – it is a reasonable assumption that your credit card number is known to someone who stole – but your cost is zero, isn’t it?
• Ask an expert – usually the CFO. The expert can and should provide confidence intervals for his estimate. The CFO is the best source and best equipped to decide if replacement value, purchase value/depreciated or opportunity cost is the relevant metric to measure the value of an asset. It’s ok, if your CFO says that company IP is worth $50 million with a confidence level of 85%.  If you do a practical  threat modeling exercise, you will be able to test sensitivity of your threat model to the confidence boundaries.
• Use test equipment. For example – If the cost of acquiring a customer is $50, you can write a sql query to find out how many customers you have and then multiply by $50. Looking at the Fixed assets and GL modules is an example of using test equipment.  If you have to measure the number of credit cards in clear text circulating on your network – I suggest  network surveillance.
• Use random sampling from a population of asset value estimators. The Rule of Five says that there is a 93% chance that the median of a population is between the smallest and largest values in any random sample of the population.   So – if you have to estimate value of a digital asset like intellectual property – you can ask five people for their estimate – for example, the CFO, the CTO, a customer, your VP marketing and a software developer who worked for one of your competitors.
• Measure in small increments and be prepared to iterate. In other words – when you do a threat model exercise, take small steps -  measure 5-10 asset values and move on from there. Most of the information value is gained at the beginning of a measurement exercise and most companies measure things that have zero information value to the business because they are easy to measure (for example – how ssh password attacks were made on company web servers) instead of the important things – like what is the value of a field service engineer diagnostic database that is distributed to notebook computers.

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.

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

A recent article on Internet Evolution , written by Gideon Lenkey quotes the SANS Institute: “application software is a major vulnerability for enterprises“. The root cause of application security vulnerabilities is bugs (usually design bugs but often implementation defects).

A research study performed in 2007, analyzed over 180 data theft events.  The empirical data shows that software bugs accounted for over 55% of the contributing vulnerability to the event (See the  Business Threat Modeling study) but 100% of the data theft events were done by people who were able to exploit the application software vulnerabilities – usually in a rather simple-minded way – for example, by typing in the account number of a banking customer in the query string of a home banking Web application,  it was possible to discover information about other bank customers. All of the software security vulnerabilities were in the SANS Top 10.

Less than 5% of the data theft events involved social engineering but almost all of the data theft events involved a trusted insider colluding with a malicious outsider.

The study  considered why organizations don’t do more to improve their production software quality.

• Users are conditioned to accept unreliable software on their desktop and development managers are inclined to accept faulty software as a tradeoff to meeting a development schedule.
• Executives, while committed to quality of their own products and services, do not find security breaches sufficient reason to become security leaders with their enterprise systems because:

1. They usually receive conflicting proposals for new information security initiatives with weak or missing financial justifications.
2. The recommended security initiatives often disrupt the business. ( “Top-down Security”, Alan Paller,SANS Institute)

The one vulnerability that is politically correct to mitigate is the trusted insider – employees and contractors.   An advantage with working at the human level is that responsibility and action can be shared by IT with HR and contracts management. Ethical behavior for employees can be reinforced using cheap and simple methods such as a 1-2 page AUP (acceptable usage policy).A hinge factor for AUP  is monitoring and enforcement – when monitored and enforced – an AUP is a hig cost-effective security countermeasure against the vulnerabilities contributing to a data breach. More on acceptable usage policies in this article - Writing an Internet Acceptable Usage Policy

Big projects are easier to manage than little ones.

In the 80s, I worked at EDP, a VAX/VMS software house. We were doing a project for Yellow Pages in Israel and I was introduced to Boaz Dotan – who had just started what was later to become Amdocs, the Israeli software and services giant. Boaz told me that he had 40 programmers working on a $5M project developing billing software for ATT. I said, that’s a lot of programmers and Boaz replied: “Yes,and it is a lot easier to manage a big software project than a small project”

Read more…