In order to determine how encryption fits into server data protection, consider 4 encryption components on the server side: passwords, tables, partitions and  inter-tier socket communications.

In these 4 components of a application / database server encryption policy, note that some countermeasures are required (for example one-way hashes of passwords, while other such as encrypting specify table columns may or may not be relevant to a particular application).

1. Encrypted password storage

You must encrypt passwords. It’s surprising to me how many Web sites don’t bother encrypting user passwords – See cases Universal Music Portugal where e-mail addresses and clear-text passwords are dumped on Internet.

What is more surprising is the confusion between encryption and hashing.

Don’t use AES for encrypting passwords in your MySQL or Oracle or MS SQL database.  You’ll end up storing the AES key somewhere in the code and an attacker or malicious insider can read the key by opening up one of your application DLLs in Notepad++ and read that key in a jiffy and breach your entire MySQL database with a single SELECT statement.

Database user passwords should be stored as MD5 hashes, so that a user  (such as a DBA) who has been granted SELECT access to the table (typically called ‘users’)  cannot determine the actual password. Make sure that different instances have different salts and include some additional information in the hash.

If you use MD5 encryption for client authentication, make sure that  the client hashes the password with MD5 before sending the data on the network.

2. Encrypt specific database table columns

The PostgreSQL 9.1 pgcrypto module allows certain fields to be stored encrypted. This is especially useful if some of the data is sensitive for example in the case of ePHI where the Web application needs to comply with the CFR 45 Appendix A Security rule. The client software provides the decryption key and the data is decrypted on the server and then sent to the client.  In most cases the client (a database driver in an MVC application such as Ruby on Rails or CakePHP or ASP.NET MVC is also a server side resource and often lives on the same physical server as the database server. This is not a bad thing.

3. Encrypt entire data partitions

Encrypting entire data partitions has its place.

On Linux, encryption can be layered on top of a file system using a ”loopback device”. This allows an entire file system partition to be encrypted on disk, and decrypted by the operating system. Many operating systems support this functionality, including Windows.

Encrypting entire partitions is a security countermeasure for physical attacks, where the entire computer is stolen. Research we did in 2007 indicated that almost 50% of large volume data breaches employed a physical attack vector (stealing a notebook at a hotel checkin desk, hijacking a truck transporting backup tapes to Iron Mountain and smash and grab jobs where thieves know the rent-a-cop walkaround schedule and break in and steal desktop computers.

On the other hand, once the volume is mounted,  the data is visible.

4. Encrypt socket communications between server tiers

SSL has it’s place, although SSL is not a silver bullet countermeasure for Microsoft Windows vulnerabilities and mobile medical devices vulnerabilities as I wrote here, here and here.

SSL connections encrypt all data sent across the network: the password, the queries, and the data returned. In database client-server connections,  relational database systems such as PostgreSQL allow administrators to specify which hosts can use non-encrypted connections (host) and which require SSL-encrypted connections (hostssl). Also, clients can specify that they connect to servers only via SSL. Stunnel or SSH can also be used to encrypt transmissions.

1. A robust, cost-effective security portfolio based on attack analysis  results in robust compliance over time.
2. Executives related well to the concepts of threat modeling / attack analysis. Competing, understanding the value of their assets, taking risks and protecting themselves from attackers is really, at the end of the day why executives get the big bucks.

As I wrote in a previous essay “The valley of death between IT and security“, there is a fundamental disconnect between IT operations (built on maintaining predictable business processes) and security operations (built on mitigating vulnerabilities).

Business executives delegate information systems to IT and information security to security people on the tacit assumption that they are the experts in information systems and security.  This is a necessary but not sufficient condition.

In the current environment of rapidly evolving types of attacks (hacktivisim, nation-state attacks, credit card attacks mounted by organized crime, script kiddies, competitors and malicious insiders and more…), it is essential that IT and security communicate effectively regarding the types of attacks that their organization may face and what is the potential business impact.

If you have any doubt about the importance of IT and security talking to each other, consider that leading up to 9/11, the CIA  had intelligence on Al Qaeda terrorists and the FBI investigated people taking flying lessons, but no one asked the question why Arabs were learning to fly planes but not land them.

With this fundamental disconnect between 2 key maintainers of information protection, it is no wonder that organizations are having difficulty effectively protecting their assets – whether Web site availability for an online business, PHI for a healthcare organization or intellectual property for an advanced technology firm.

IT and security  need a common language to execute their mission, and I submit that building the security portfolio around most likely threat scenarios from an attacker perspective is the best way to cross that valley of death.

There seems to be a tacit assumption with many executives that regulatory compliance is already a common language of security for an organization.  Compliance is a good thing as it drives organizations to take action on vulnerabilities but compliance checklists like PCI DSS 2.0, the HIPAA security rule, NIST 800 etc, are a dangerous replacement for thinking through the most likely threats to your business.  I have written about insecurity by compliance here and here.

Let me illustrate why compliance control policies are not the common language we need.

PCI DSS 2.0 has an obsessive preoccupation with anti-virus.  It does not matter if you have a 16 quad-core Linux database server that is not attached the Internet with no removable device nor Windows connectivity. PCI DSS 2.0 wants you to install ClamAV and open the server up to the Internet for the daily anti-virus signature updates. This is an example of a compliance control policy that is not rooted in a probable threat scenario that creates additional vulnerabilities for the business.

Now, consider some deeper ramifications of compliance control policy-based security.

When a  QSA or HIPAA auditor records an encounter with a customer, he records the planning, penetration testing, controls, and follow-up, not under a threat scenario, but under a control item (like access control). The next auditor that reviews the  compliance posture of the business  needs to read about the planning, testing, controls, and follow-up and then reverse-engineer the process to arrive at which threats are exploiting which vulnerabilities.

Other actors such as government agencies (DHS for example) and security researchers go through the same process. They all have their own methods of churning through the planning, test results, controls, and follow-up, to reverse-engineer the data in order to arrive at which threats are exploiting which vulnerabilities.

This ongoing process of “reverse-engineering” is the root cause for a series of additional problems:

• Lack of overview of the the security threats and vulnerabilities that really count
• No sufficient connection to best practice security controls, no indication on which controls to follow or which have been followed
• No connection between controls and security events, except circumstantial
• No ability to detect and warn for negative interactions between countermeasures (for example – configuring a firewall that blocks Internet access but also blocks operating system updates and enables malicious insiders or outsiders to back-door into the systems from inside the network and compromise  firewalled services).
• No archiving or demoting of less important and solved threat scenarios (since the data models are control based)
• Lack of overview of security status of a particular business, only a series of historical observations disclosed or not disclosed.  Is Bank of America getting better at data security or worse?
• An excess of event data that cannot possibly be read by the security and risk analyst at every encounter
• Confidentiality and privacy borders are hard to define since the border definitions are networks, systems and applications not confidentiality and privacy.

Threat scenarios as an alternative to compliance control policies

When we perform a software security assessment of a medical device or healthcare system, we think in terms of “threat scenarios” or “attack scenarios”, and the result of that thinking manifests itself in planning, penetration testing, security countermeasures, and follow-up for compliance. The threat scenarios are not “one size fits all”.  The threat scenarios for an AIDS testing lab using medical devices that automatically scan and analyze blood samples, or an Army hospital using a networked brain scanning device to diagnose soldiers with head injuries, or an implanted cardiac device with mobile connectivity are all totally different.

We evaluate the medical device or healthcare product from an attacker point of view, then from the management team point of view, and then recommend specific cost-effective, security countermeasures to mitigate the damage from the most likely attacks.

Threat scenarios consider asset values, vulnerabilities, threats and possible security countermeasures. Threat analysis as a methodology does not look for ROI or ROSI (there is no ROI for security anyhow) but considers the best and cheapest way to reduce asset value at risk.

In our experience, building the security portfolio on threat scenarios has 2 clear benefits;

1. A robust, cost-effective security portfolio based on attack analysis  results in robust compliance over time.
2. Executives relate well to the concepts of threat modeling / attack analysis. Competing, understanding the value of their assets, taking risks and protecting themselves from attackers is really, at the end of the day why executives get the big bucks.

Christopher Frenz, CTO at See-Thru and a faculty member at Mercy College, both in New York, says the problem is, “not because of passwords being obsolete, but because of the prevalence of bad passwords and bad password practices.”

He points to the 2009 SQL injection attack on the social media site RockYou that compromised 32 million user account passwords. “The only password security requirement was a password of at least five characters,” he says, “(which) resulted in people choosing passwords such as 12345, Password, rockyou, and abc123,” plus common dictionary words.

Besides that, the passwords were stored in plain text format, along with users’ email addresses.

Frenz says some websites (Hotmail recently among them) now require more complex passwords with multiple character types.

I’m speechless.

SQL injection attacks on Web sites are made possible because of poor coding practices that take input strings from forms or query strings and concatenate with SQL snippets like this:

2′;Update tbl_accountParent set Email=Email+’;obama@whitehouse.giv’;select * from  tbl_accountParent where ’1′=’1

From now on, whenever any user asks for password reminder, Mr. Obama will get a nice email with his user name and password.

And frankly, I don’t understand programmers or Web site operators who tolerate storing passwords in plain text or encrypting them instead of using one-way hashes

Maybe a bunch of people should read the online introduction to cryptography by Dan Bernstein.

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

An objection I’ve heard frequently to Google Apps is that they don’t give customer service – although I would argue that great products delivered that work on a global scale for free definitely qualify as great customer service.

How do startups make customer service scale into awesomeness? touches on many good points including a I Love/I Hate Ratio (Virgin Atlantic scores at the bottom – Microsoft is about even and Amazon, Google score at around 8 – meaning that 8x as many people love Google as hate them. Which is pretty impressive I thought.

Still – one thing we miss is the synergy between love/hate and suppliers and customers. If you give great service, customers will love you and if you’re a great customer and pay on time – suppliers will love you.

The only counter-example I know is Israeli corporate customers that will pay the best supplier in the world Net 180 days and take a 20% discount just because they felt like it.

Bottom line – Israel may be a country with a poor service ethic but it’s also a country with a poor payment on time ethic and poor data security, customer privacy ethic

In my book – not an accident.  If you treat your customers and suppliers well, you will tend to treat the issues of data security and customer privacy accordingly.

Security is about reducing the impact of unpredictable attacks to a your organization.

IT and security adopt a common goal and a common language – a language  of customer-centric threat modelling

Typically, when a company ( business unit, department or manager) needs a line of business software application, IT staffers will do a system analysis starting with business requirements and then proceed to buy or build an application and deploy it.

Similarly, when the information security group needs an anti-virus or firewall, security staffers will make some requirements, test products, and proceed to buy and deploy or subscribe and deploy the new anti-virus or firewall solution.

Things have changed – both in the IT world and in the security world.

Web 2.0 SaaS (software as a service) offerings (or  Web applications in PHP that the CEO’s niece can whip together in a week…) often replace those old structured systems development methodologies. There are of course,  good things about not having to develop a design (like not coming down with an advanced case of analysis paralysis) and iterating quickly to a better product, but the downside of not developing software according to a structured systems design methodology is buggy software.

Buggy software is insecure software. The response to buggy, insecure software is generally doing nothing or installing a product that is a security countermeasure for the vulnerability  (for example, buying a database security solution) instead of fixing the SQL injection vulnerability in the code itself.   Then there is lip-service to so called security development methodologies which despite their intrinsic value, are often too detailed for practioners to follow), that are not a replacement for a serious look at business requirements followed by a structured process of implementation.

There is a fundamental divide, a metaphorical valley of death of  mentality and skill sets between IT and security professionals.

• IT is about executing predictable business processes.
• Security is about reducing the impact of unpredictable attacks.

IT’s “best practice” security in 2011 is  firewall/IPS/AV.  Faced with unconventional threats  (for example a combination of trusted contractors exploiting defective software applications, hacktivists or competitors mounting APT attacks behind the lines), IT management  tend to seek a vendor-proposed, one-size-fits-all “solution” instead of performing a first principles threat analysis and discovering  that the problem has nothing to do with malware on the network and everything to do with software defects that may kill customers.

Threat modeling and analysis is the antithesis of installing a firewall, anti-virus or IPS.

Analyzing the impact of attacks requires hard work, hard data collection and hard analysis.  It’s not a sexy, fun to use, feel-good application like Windows Media Player.   Risk analysis  may yield results that are not career enhancing, and as  the threats  get deeper and wider  with  bigger and more complex systems – so the IT security valley of death deepens and gets more untraversable.

There is a joke about systems programmers – they have heard that there are real users out there, actually running applications on their systems – but they know it’s only an urban legend. Like any joke, it has a grain of truth. IT and security are primarily systems and procedures-oriented instead of  customer-safety oriented.

Truly – the essence of security is protecting the people who use a company’s products and services. What utility is there in running 24×7 systems that leak 4 million credit cards or developing embedded medical devices that may kill patients?

Clearly – the challenge of running a profitable company that values customer protection must be shouldered by IT and security teams alike.

Around this common challenge, I  propose that IT and security adopt a common goal and a common language – a language  of customer-centric threat modelling - threats, vulnerabilities, attackers, entry points, assets and security countermeasures.  This may be the best or even only way for IT and security  to traverse the valley of death successfully.

After reading the excellent article  by Sarah Leibowitz-Dar in the Maariv weekend edition, I realized that there is 1 constraint in Israel for improving data security:

בועז גוטמן, מקים המפלג לפדעי מחשב במשטרת ישראל.”

יש היום במשטרה חוקרי מחשב טובים שיודעים לקרוא ולכתוב אנגלית

Boaz Gutman, former Israeli police officer who started the computer crimes unit says that Israeli Police have good police officers who know how to read and write English.  If we had 30 instead of 20 we would be able to handle the case load

That one (1) constraint for improving data security in Israel and preventing credit card breaches is quite simply that most Israelis, including members of Knesset, the Police and Army simply do not understand English.

English after all, is not Israelis’ native tongue.   Israelis all use the Hebrew interfaces on their cell phones, use the Hebrew interface in Microsoft Office and send messages to each other on Facebook in Hebrew.

If Israelis spoke English fluently or at least understood English fluently they would be aware that there is a whole wide world out there where credit cards are stolen and Web sites need to be protected.

But no, we are like a small group of Jews living in a Russian shtetl and we do not know that there is an America out there.

Here we have Ms. Leibowitz and a bunch of  other Israeli journalists getting worked up over a fairly elementary hacking event resulting in the leakage of 14,000 credit cards from Israeli  Web sites.

If they would read English, they would know that in the past 6 years over 300 million credit cards have leaked in America.

In other words, your credit card is already out there. And life just goes on.

I  could write a book on mismanagement of data governance and compliance, data security, web server security, web application software security.

In 2003, I got turned on to the notion of using extrusion prevention to prevent data loss. I had the privilege to work with some of the pioneers in data loss prevention and over a period of over 5 years, I evangelized, sold, marketed, implemented and supported data loss prevention solutions in Israel and Europe. In the course of that time, I made thousands of phone calls, met hundreds of prospects and sold a dozen systems.  I  developed a unique perspective to the data security space working with both vendors and C-level decision makers in a wide variety of verticals from financial services to diamonds and telecommunications.

There is no need to state the obvious common denominators between Israeli companies and their US counterparts who have suffered the ignominy of a large scale credit card data breach: Closing the barn doors after the horses have fled, thinking it won’t happen to them, relying on their Checkpoint firewall to prevent data breaches, erroneously calling an anti-virus threat management, believing their IT outsourcing provider and equating the counting of compliance check list items with effective data security.

In this essay, I will try and enumerate what I believe are the key contributing factors behind the insecurity of most Israeli businesses.  Most are inherently cultural to Israel although the last factor (PCI DSS 2.0) is everyone’s problem.

Letting your piss go to your head

The first factor is cultural. It’s called in Hebrew  עלה לו השתן לראש.  It’s hard to translate this exactly – but a literal translation is “letting your piss go to your head”.   Arguably, this may be true for many senior executives, especially those on Wall Street who run billion dollar financial service businesses.

The difference is that in Israel, a colonel who served in the Israeli Air Force and then retired at age 45 on a full military pension to work as a VP in a publicly-held Israeli company that does $50M worth of business has more piss up his head then the CEO of IBM.  You are more likely to ascend bodily into heaven than to convince this person to be a security leader, implement robust data governance in his organization and implement strong data security countermeasures. There are many jokes about this in Israel. The one I like the most goes like this: “Why not have sex under an open window in Israel? Because, someone will leap through the window and tell you – move aside, I’ll show you how it’s done“.  As far as I can tell, this is also the root cause for Israeli politicians like Ehud Barak, Bibi and Tzipi Livni who believe that they know what is best for the Palestinians.  (Letting your success get the best of you is gender-neutral).

The Checkpoint syndrome

The second factor is also cultural. I would label it the Checkpoint syndrome. I believe that the Americans call it “NIH – Not invented here”.   It is literally almost impossible to sell an Israeli CIO on the notion of innovative data loss prevention technologies when Checkpoint hasn’t really done much in that space (granted they introduced a DLP software blade for their firewall product in 2010, 7 years after Fidelis, Vontu and Verdasys already had working technology). Port Authority, later acquired by Websense, did indeed have some success in Israel – burning $60M in VC funding and selling about 30 systems in Israel due to a related syndrome that I shall call the 8200 syndrome – which is sort of an Israeli coolness factor – like Roy Hargrove and RH Factor playing funk. A related illness, which is at epidemic levels in Israel, is the Microsoft Monoculture.  While Microsoft has correctly pigeonholed data security into data governance  the main focus of Microsoft operating systems is access control and when key system management focus is on access control then it becomes difficult for system managers to properly assess the risk from trusted insider threats – insiders who violate security policy simply because they can. עלק אבטחה.

Retaliation instead of mediation

The third factor is political.

Saber rattling is a political gesture and retaliation is not a substitute for proactive threat analysis and premeditated risk mediation.

My friend Maryellen Evans sent me this clip from the Financial Times: Israel seeks revenge for hacking

Several years ago, I had an interesting sales call with the CSO of Clalit, the big Israeli HMO.   I made my pitch for data loss prevention and tied it into the ability of DLP to deliver real-time monitoring and visibility and assure PHI privacy compliance. He laughed at me and said: “Listen, Danny – Israeli has a dozen privacy regulations on the books, all are relevant to PHI, but no one is serious about compliance, so we do what we think we need to do in the limitations of our budget and it is what it is.“

The problem of legislation without enforcement is endemic in Israel from traffic safety to women’s rights to environmental protection: Israel is a country with more legislation and commissions of inquiry than  enforcement.   Perhaps,  a weak system of enforcement and abiding the law may be  a vestige of defense mechanisms developed while living in the Diaspora.   Certainly – the Eastern European Jews who founded Israel did not come from a background of law, order and compliance.  They came from a background of revolution and change.

Compliance  without security

Finally, we come to PCI DSS 2.0.  I have written extensively on the drawbacks of PCI DSS and here and here (The Tao of GRC) and suggest specific ways of getting credit card security right.

Perhaps the time has come to perform a vulnerability assessment of the standard itself.

In very simple terms, the biggest vulnerability of PCI DSS is that it’s about 10 years behind the curve.  When people in the PCI DSS Security Council in Europe confess to never having heard of DLP (Data loss prevention) and when the standard places an obsessive emphasis on anti-virus, you know you’re still in Kansas.

Speaking with a senior representative of PCI DSS Security Council in Europe last year, I posed some of these questions and he replied that the situation with merchants is so bad that PCI DSS is “better than nothing”.

That is pathetic isn’t it?

Perhaps we would all be better off taking the day off and hoovering our flats instead of trying to reeducate management, fix political systems, improve our data security and prevent credit card breaches.

It would certainly be cheaper.

Information security and  risk analysis is complex stuff, with multiple dimensions  of people, software, performance, management, technology, assets, threats, vulnerabilities and control relationships.  This is why it’s hard to sell security to organizations. But, information security is also a lot like fashion with cyclical hype and theater: today – , HIPAA, iOS and Android security,  yesterday – Sarbanes-Oxley, federated identity management, data loss protection and application security firewalls.

Back in 2007,  I thought we might a return to the Age of Reason, where rational risk management replaces blind compliance check lists – I thought that this could happen  for 2 reasons:

1. Compliance projects  can have good business value, if you focus on improving the product and it’s delivery.
2.  Security is like fashion – both are cyclical industries, the wheel can also turn around in the right direction.

HIPAA compliance is a minimum but not sufficient requirement for product and process improvement.

Healthcare companies and medical device vendors that do HIPAA compliance projects, may be paying a steep price for HIPAA compliance without necessarily getting a return on their investment by improving the core features and functionality of their products and service offerings.

Compliance driving improvements in products and services is good for business, not just a mantra from Mcafee.

It could happen, but then again, maybe not. Look at the trends. Taking a sample of articles published in 2011 on the  eSecurityPlanet Web site we see that  mobile devices and cloud services lead the list, followed by IT security with healthcare closing the top 15. I guess cost-effective compliance is a lot less interesting than Android security.

1. iOS vs. Android Security: And the Winner Is?
2. 5  iOS 5 Enterprise Security Considerations – You can’t keep Apple out of the enterprise anymore so it’s best to figure out the most secure way to embrace it, writes Dan Croft of Mission Critical Wireless.
3. PlayBook Tops in Tablet Security – Recent price reductions may mean more Blackberry Playbook tablets entering your organization, but that may not be such a bad thing for IT security teams.
4. Android Security Becoming an Issue – As the Android mobile platform gains market share, it also garners a lot of interest from cyber crooks as well as IT security vendors.
5. Which Browser is the Most Secure? – The ‘most hostile’ one, say researchers at Accuvant Labs.
6. How to Prevent Employees from Stealing Your Intellectual Property -It’s the employee with the sticky hands that is the easiest and cheapest to thwart.
7. Security Spend Outpacing the Rest of IT – High profile breaches and mobile devices are driving IT security spending.
8. Public Cloud Keys Too Easy to Find -If you put the keys to your cloud infrastructure in plain sight, don’t be surprised if you get hacked.
9. Zeus (Still) Wants Your Wallet – The antivirus community has failed to figure out this able and persistent piece of malware. It’s as simple as that.
10. Spear Phishing Quickly Coming of Age – Even the security giants are not immune from this sophisticated and growing form of attack, writes Jovi Bepinosa Umawing of GFI Software.
11. Penetration Testing Shows Unlikely Vulnerabilities – Enterprises need to dig deeper than just automated scanning to find the really interesting and dangerous cyber security flaws.
12. Bank Fraud Still Costing Plenty – Bank fraud is and will continue to be an expensive problem.
13. Do IT Security Tools Really Make You Safer? – Yet another suite of tools for IT security folks to administer and manage can actually have the opposite effect.
14. Siege Warfare in the Cyber Age – In one the unlikeliest turn of events brought about by technology, it looks like Middle Ages’ siege warfare may be making a comeback, writes Gunter Ollmann of Damballa.
15. Healthcare Breaches Getting Costlier – And it’s not just dollars and cents that are on the line – reputations are on the line, writes Geoff Webb of Credant Technologies.

There is absolutely no question that the build process is a pivot in the software quality process. Build every day, don’t break the build and do a smoke test before releasing the latest version.