Israeli Software

I was working on a Video on demand content security project this summer, with an old friend Dr. Joel Issacson - Joel saw my 1.9kg Acer notebook and remarked that it must be my third or fourth generation laptop. This is true - I was a loyal IBM A series user but the weight was just pulling my shoulder out of its socket. Joel has an IBM X70 which is also about 1.9kg.

A few weeks ago - I reported on What Japanese Customers want courtesy of my buddy Todd Walzer from iLand6 in Tokyo.

Here is Todd's sequel to the article.

People ask me what Japanese customers want. Last time I mentioned the importance of redundant systems that continue operation despite points of failure.

#2 – is compactness. In Japan they like things small.

This may not surprise you. But, does miniaturization top your development priorities list? If you're going to sell in Japan, maybe it should.

Some of the miniaturization is born of necessity.

Take notebook PC's. While the Western notebook typically weighs 2-3kg, the Japanese are making them smaller and lighter. My new Panasonic Let's Note (called ToughBook in the U.S.) weighs 1.17 kg, my partner has the 0.91 kg model. (For comparison, the MacBook Air at 1.35 kg, equals the heaviest of the Let's Note series). In a country where people are commuting and going to meetings on trains, size and weight really matter. The battery runs 10 hours, so you save carrying a 400 gram power supply too. Toshiba, NEC, Fujitsu, Sony, Sharp have similar notebook products. Of course Japanese have smaller fingers, so they don't mind the slightly cramped keyboard.

Companies like ASKUL "miniaturized" the office supply business by delivering pens, paper, printer cartridges, in frequent small lots to small-medium offices in near-real-time "Toyota Just-In-Time" style.

Considering the dearth of Tokyo office space (and storage space) and the narrow roads unfriendly to delivery vehicles, the motorbike-based ASKUL system works well.

Putting aside practicality, compactness is so embedded in Japanese culture that a "small for small's sake" design ethic has evolved. Japanese manufacturers always push the envelope on smaller and smaller cellphones, digital cameras, suitcases, computer mice, and more.

iLand6 provides Sales Presence services in the Japan Communications

A colleague and close friend claims that he usually makes the right decision because he uses only one constraint - time. There is something in that. Andy Grove wrote that it's best to take a wrong decision quickly then taking no decision at all - if you take a decision, you can always fix it. Inactivity and indecision cannot be rectified by further inaction.

In Judaism there is the concept of "free will" - Jews are commanded to make a choice. Good choices have good results and usually give us profit in this world or the next. While poor choices can also have good results, poor choices often carry a heavy toll.

In essence, we understand that every business, personal or national policy decision is an exercise in risk management and threat analysis. In my friend's methodology, the faster you complete the threat analysis, the better off you are.

In Israel, one sometimes hears religious Jews positing that a particularly crappy situation is happening as part of the Jewish role in the global scheme of things.

This class of reasoning is used to justify the expulsion from Gush Katif and the continued reign of Olmert and his band of corrupt politicians as being things that just "had to happen" because they are in the long term interest of the Jewish people.

I disagree and claim that this is "nechamat tipshim" (consolation by fools).

If you read the sugya of Kamtza and Bar-Kamtza in the Gemara, you clearly see that the Rabanim did not subscribe to this philosophy At many steps along the way - the Jews had a chance to change the vector of history and avert the destruction of the Temple - and the Roman destruction of the entire land of Israel in a scorched earth policy and killing of close to a million Jews almost 120 years after the destruction of the Second Temple.

Read Tractate Gittin - 55-56 for the original story or the edited version in the Wikipedia.

When you sell hammers, everything looks like a nail.

For companies like McAfee and Symantec, threat management is first and foremost anti-virus software.

Just look at their Web sites; Symantec Corp: "AntiVirus, Anti-Spyware, Endpoint Security, Backup, Storage Solutions" or in the case of McAfee, you'll see keywords like: antivirus, antivirus software, anti-virus, managed services, virusscan, security center, intrusion prevention, system protection, internet security, firewall, personal computer, spamkiller, privacy, macfee, pc protection.

Last week, I made a presentation on the methodology of practical threat analysis and it's application in risk management to a group of security and compliance consultants at KPMG in Tel Aviv.

We were discussing how many organizations build their security strategy around vendor technology - at that point, one of the consultants made the hammer analogy and asked me if I was naive. He told me - "look Danny - we all know that threats to customer data and company IP are typically due to people - employees, sub-contractors; people who are already inside the network. "

A common conceptual error is to rely on technology instead of tackling the more difficult challenge of managing people.

Noontime at the conference there was a panel discussion with Itay Yanovski (the CISO from ZIM Shipping), Micha Weiss (CISO from Bank Hamizrachi) and Avi Weissman (representing the newly formed National Information Security Council - an Israeli non-profit group headed by Yaacov Amidror).

The moderator (Ofir Zilbiger from SecOz, who is a fixture at these events) asked questions and the participants answered:

How do you align the security operation with business objectives?
1. It's real simple - we all work to maximize profit (Micha)
2. We're an operational organization at ZIM - we see a convergence of operational risk with information security risk. (Itay)

How do you use risk management in your security practice?
1. We calculate the monetary value of loss events but I feel that our main challenge is quantifying risk impact - it's difficult for me to explain to a programmer that a bug in a critical system can have a large financial impact on the bank. I feel that we still don't know the correct risk indicators for our IT operation. (Micha)

2. We have a number of key process indicators we collect in the shipping operation but I really don't know what indicators we should be using in our risk management practice. We see information security as a subset of COBIT and we practice monitoring via our SOC (security operations center) and periodic risk assessment. (Itay)

I took a couple hours out from work today to pop over to Infosec 2008 in Airport CIty.

I don't normally go to these events unless I'm invited to speak - but it is a good networking opportunity and chance to reconnect with old friends and colleagues.

Whenever I go somewhere - I'm always looking at things with a security perspective - open doors, windows - things that could be easily lifted. Who might be a threat.

Walking the exhibit hall, I realized that Risk Assessment is a threat to security product vendors.

Not every security countermeasure is effective or even relevant for your company. This is definitely a threat to a vendor salesperson who must make quota.

If you do a risk assessment with Practical Threat Analysis (shameless plug for PTA - download here you systematically collect assets, threats, vulnerabilities ...and THEN produce a cost-effective risk mitigation plan. Your vendor wants to sell you a $100,000 database firewall, but it may turn out that your top vulnerability is from 10 Field service engineers with company source code on their notebook computers. You can mitigate the risk of a stolen notebook by installing a simple security countermeasure - Free open-source disk encryption software for Windows Vista/XP, Mac OS X, and Linux.

Vendors often attempt to mitigate the risk assessment threat by using compliance as a universal countermeasure.

This is can approach absurd levels as we shall see in the following example.

NetClarity (which is a NAC appliance) claims that it provides "IT Compliance Automation" and that it "Generates regulatory compliance gap analysis and differential compliance reports" and "self-assessment, auditing and policy builder tools for Visa/Mastercard PCI, GLBA (sic), HIPAA, CFR21-FDA-11,SOX-404, EO13231 government and international (ISO270001/17799) compliance."

A network access control appliance is hardly an appropriate tool for compliance gap analysis but asserting that a NAC appliance or Web application firewall automates SOX 404 compliance is absurd.

Sarbanes-Oxley Section 404, requires management and the external auditor to report on the adequacy of the company's internal control over financial reporting. This means that a company has to audit, document and test important financial reporting manual and automated controls. I remember the CEO of a client a few years ago insisting that he would not accept any financial reports from his accounting department unless they were automatic output from the General Ledger system - he would not accept Excel spreadsheets from his controller, since he knew that the data could be massaged and fudged. If there was a bug in the GL or missing / incorrect postings he wanted to fix the problem not cut and paste it.

Appropriate, timely and accurate financial reporting has absolutely nothing to do with network access control.

Operational risk management strategies use a 4 step process similar to the Observe,Orient,Decide and Act loop, invented by the late John Boyd.

Information Security uses data collection, threat analysis, security countermeasure planning and implementation and security monitoring. In the areas of fraud and anti-money laundering the steps are Detection, Tracing, Quantification and Fraud prevention. Military Strategy uses an OODA Loop Observation, Orientation, Decision, Action

"The OODA construct was originally a theory of achieving success in air-to-air combat, developed out of Boyd's Energy-Maneuverability theory and his observations on air combat between MiGs and F-86s in Korea. Harry Hillaker (chief designer of the F-16) said of the OODA theory, "Time is the dominant parameter. The pilot who goes through the OODA cycle in the shortest time prevails because his opponent responds to actions that have already changed." John Boyd - Military Strategist

Time is the dominant parameter

The ability to quickly generate many different security countermeasure options as well as the ability to rapidly implement and shift, enables an organization to create a mismatch between attacker tactics and the organizations vulnerabilities. Instead of an organization fighting yesterday's battles with a firewall, the attacker will find himself fighting yesterday's battles with spyware.

When organizations use a checklist/compliance strategy, attackers can read the compliance standard (for example - PCI DSS 1.1 for payment card security) and attack the controls in the standard that are known to be be weak or simply to attack between the cracks where the standard has waffled (for example software application security and data leakage prevention).

However, my impression from many clients and security and compliance analysts that work with our risk assessment tool - PTA (Practical Threat Analysis); is that they perform the first two steps in a risk assessment and then stop. They collect data about vulnerable systems and analyze the risk profile ("orientation") in a risk assessment and stop short of the implementation of effective security controls.

The Decision and Action steps are often postponed due to management unwillingness to take a security leadership position (out of concern that security technology or new procedures will interfere with the operation) and due to vendor conflicts of interest with the risk assessment findings.

It is clear that the root cause of the increasing spiral of security breaches is that the attacker community moves much faster than business today.

Whether the attackers are under 30 employees who are far more hip to the latest mobile and Internet technologies than the IT department or whether hackers exploit Windows Vista vulnerabilities; I just don't see how a business can use traditional enterprise software 12-24 month implementation cycles to manage their enterprise risk.

They are not that easy to use and they make you work hard.

Let's say you are doing a risk assessment in order to comply with customer data protection or customer privacy regulations; PCI DSS 1.1 or GLBH

You have to get a bunch of people in your organization to schedule time, to fill out forms, be interviewed and tell you how much risk is in their part of the business process. Then the system will roll up the risk and show it to you in terms of the business process. Great. There is no reason for a person in purchasing, sales, IT operations or engineering to really care. The risk assessment process is not going to help them do their job better or make more money. If anything - it might actually be a reason for them to deflect blame for vulnerabilities to someone else in the organization.

This is one of the strengths of the Practical Threat Analysis methodology (download PTA Professional free evaluation copy.

When you do a risk assessment with PTA - you collect data on assets, threats, vulnerabilities. This is a natural language that everyone "gets" and you're not asking them to admit or assess risk - the system (PTA) calculates the risk based on the data you collect.

I spent a few hours at the Israel Infosec 2008 show last week and it underscored the axiom that if you have a hammer, every problem looks like a nail.

The Director of R&D Israel for Protegrity, Michael Groskop was showing me some of their wares (automated encryption of selected columns in relational databases, Web Application security). He was pretty emphatic about the need for Web application security and encrypting credit cards but when I challenged him on the top threats to payment card data in the retail industry he was forced to back space a bit.

Vendor statement "Vulnerable Web applications are the key issue"
Response: "In retail industry, not"

As VIsa has finally conceded in their October 23, 2007 bulletin, Payment application security mandates, "vulnerable payment applications have proved to be the leading case of compromise incidents, particularly among small merchants".

Vendor statement "You must encrypt credit card numbers"
Response: "In retail industry, you should not store the data"

Visa USA Inc. Oerating Regulations prohibit the storage of magnetic-stripe, CVV2 and PIN data.

So far so good. If you continue reading the Payment Application security bulleting through to the 4th page - you will notice one very important caveat -

"PABP applies only to third-party payment software that stores, processes or transmits cardholder data. PABP does not apply to hardware terminals or software developed by merchants and agents for in-house use only."

In other words - even though the small to mid-size merchants buy third party software - the big retailers (who often develop their own) are being let off the hook from a serious software security assessment. Not bugs, not default passwords, not default vulnerable Windows system configurations.

Visa contends that this is an issue of supply chain security, and that the majority of vulnerabilities are with smaller merchants. This is a correct statement in its own. However - it is being taken out of context of asset value - a small merchant has 10,000 credit cards but a Level 1/2 merchant like Hannaford has millions of payment cards and is a much juicier target than the small guy selling falafel.

In dollar terms, there is far more risk with the Level 1 and Level 2 merchants - yet they are not being encouraged to fix their most critical vulnerabilities - in-house payment card application software.

Yesterday, I was at the first ISACA Israel conference on IT Governance.

My first challenge was understanding what IT governance means (and I've been an IT professional for a long time...)

IT Governance (according to Wikipedia)

is a subset discipline of Corporate Governance focused on information technology (IT) systems and their performance and risk management. The rising interest in IT governance is partly due to compliance initiatives (e.g. Sarbanes-Oxley (USA) and Basel II (Europe)), as well as the acknowledgment that IT projects can easily get out of control and profoundly affect the performance of an organization.

Well - I can identify with that.

The translations of governance and maturity to Hebrew caused a certain amount of discussion - ממשל ובשלות - and smiles - considering that Ehud Olmert - the current Prime Minister of Israel is facing corruption charges. Sam (Shoni) Albeck - who is General Counsel for the TASE - the Tel Aviv Stock Exchange. Albeck discussed the Societe Generale case and made some insightful comparisons with regulatory, compliance and governance in Israeli publicly traded companies.

Dr. Irit Haviv-Segal, from the Tel Aviv University Law School presented a good overview of corporate financial reporting regulatory requirements for Sarbanes-Oxley and their evolution from pre-Enron days to the current state.

Without question - Microsoft, Oracle and Liquid Machines are all serious vendors in enterprise content management and DRM. How effective is DRM (Digital Rights Management ) for protecting customer data?

My first test of effectiveness of any data security technology is what reference accounts have to say. Unlike IT applications like CRM and ERP, security of customer data and IP is a sensitive area for most executives and they'd prefer not to discuss publicly what they're doing (or not doing).

Looking at the Liquid Machines Web site - not a single case study mentions the name of the client. They are hard selling their products using compliance, which makes me wonder how many of their clients used a ROSI (return on security investment) calculation and built a business justification for the Liquid Machines DRM software. They have this gem on the Web site:

"In order to comply with section 404 of Sarbanes-Oxley, companies must implement internal controls that:

You know what PT Barnum said about a fool being born every minute but sarbox 404 says nothing of the sort. A CEO of one of my clients put it best when he said, " I don't want to get any financial reports in Excel, I want everything straight from the financial systems - if you cannot get if from the GL or AP or AR - then fix the reports."

Manipulation of data in Microsoft Excel is the original sin of fudging, manipulating and stealing.

Reading the above marketing copy, underscores that too many technology vendors are spending venture capital trying to build franchises around Sarbox and GLBA instead of fixing the reports and eliminating root causes of fraudulent reporting.

While use of DRM inside a corporate setting with well controlled and configured policy, procedures and systems can be effective (although expensive to maintain), I just don't see DRM as an effective security countermeasure for customer data and IP outside the perimeter.

However, one needs to match the right security countermeasure to the right asset vulnerability. If the vulnerability is an insider that may be able to access sensitive information outside his department, then I can see how DRM would mitigate the risk of unauthorized access.

However, there is a common misunderstanding of the meaning of a trusted insider. By definition - if a trusted insider has all the rights she needs in the DRM system to access critical IP and customer data - she can upload it to that data to her Gmail account.

In other words, DRM is not an effective security countermeasure for data leakage prevention or protecting the digital asset from unauthorized network transfer.

I think that managers are simply not managing content/network/system security like they run their business. With all the compliance - related malarkey from vendors - I just find it hard to accept the true business value of DRM products for protecting customer data.

I want one phone number and a name and 20' of their time - I am always willing to learn new things and hear about great technologies.

But - in the meantime - out of all the prospects who told me in 2006 that were going to prevent data theft with Microsoft DRM; a) None implemented and b) All bit it big time - since it is a matter of public record - none of the Israeli companies who were attacked by competitors with the so-called "Israeli Trojan" (companies like HOT and Pelephone) lost their data from screenshots and keylogs transmitted over open FTP ports.

It is important to note that expensive DRM systems would not have mitigated that threat at all. What is the most effective security control - that will have to wait for another blog entry, another day.

Not everything is a Web application

The tag line on my email is "Buggy software is risky software." Software defects are at the root cause of most Web application vulnerabilities, but looking at traditional enterprise IT applications such as retail head office and back office processing - it is a safe bet that weak passwords, default system configurations and leaving a bunch of temporary files on a system volume with world read access are at the top of the vulnerability list.

Complying with government (HIPAA) or industry (PCI DSS 1.1) security standards is not enough to protect customer data and IP. The folks who wrote PCI DSS were thinking of VISA and the big processors and for sure the congressmen in DC sure as heck don't know about your business vulnerabilities.

Compliance has created a budget line-item mentality - if there is a Sarbanes-Oxley line item - it will get filled by the accounting firm. This creates a effect of starving out threat analysis projects that are tasked with hunting down and mitigating the root cause of fraud and data leakage.

In order to protect the confidentiality, integrity and availability of customer data and company IP - it is important to continuously look at current threats and vulnerabilities - the current threat surface for your business can change in hours. When we say threats - we are not talking about virus - we're talking trusted insiders, collaborators that exploit bugs in your systems software and configurations.

Since assets and their value are fairly slow moving and security countermeasures are generally the easiest (and most fun) of any project - your priority needs to be on monitoring threats and system vulnerabilities.

In an article published May 16, Financial News Online writer Mark Cobley says, “Investment advisers speaking at a corporate governance in Paris yesterday gave a positive verdict to the U.S. Sarbanes-Oxley legislation…Half of the advisers Cobley quotes in the piece work for U.S.-based companies, and they were lauding Sarbanes-Oxley. Glass Lewis and MCI Communications representatives indicated that Sarbox “gives shareholders powerful tools to combat fraud.”

Yeah right. Powerful tools to combat fraud.

Sarbox is a fig leaf for big companies with a lot of money to spend.

The average accountant has never been involved in a live fraud event and the just out of school, still wet behind the ears new grads that do Sarbox audits - barely knows what a real business looks like let alone a full blown forensic fraud investigation.

The original Sarbox legislation didn't deal with SPC (special purpose companies) that were one of the root causes of Enron and considered today to be one of the root causes of the current sub prime crisis.

How can the US deal effectively with root causes of fraud by closing one eye and delegating the job of fraud investigation and mitigation to people who are not qualified for the task?

Sarbox costs US companies over $100BN / year in services (the impact on IT spend is $18BN alone).

Imagine if the US were to invest $120BN /year in green energy development instead of in big 5 billable hours?