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.

It is convenient for a customer to buy a product and feel “secure” but, as businesses become more and more interconnected, as cloud services percolate deeper and deeper into organizations, and as  government compliance regulation becomes more complex and pervasive; the security “problem” becomes more difficult to solve and even harder to sell.

I believe that there are 3 reasons why it’s hard to sell security:

The first is that it’s complex stuff, hard to explain and even harder to build a cost-justified security countermeasure plan and measure security ROI.  The nonsense propagated by security vendors like Symantec and Websense do little to improve the situation and only exacerbate the low level of credibility for security product effectiveness with  pseudo science and ROI calculations written by wet-behind-the-ears English majors marcom people who freelance for security vendors – as I’ve noted in previous posts here, here, here and here.

The second is related to prospect theory. A CEO is risk hungry for a high impact, low probability event (like an attack on his message queuing transaction processing systems) or theft of IP by a competitior and risk averse to low impact, high probability events like malware and garden variety dictionary attacks on every ssh service on the Net.

The third is related to psychology.   Why is it a good idea to cold call a CIO and tell him that the multi-million dollar application his business developed is highly vulnerable?    Admitting that his software is vulnerable and going to the board to ask for big bucks to fix the problem is tantamount to admitting that he didn’t do his job and that someone else should pay the price.  Very bad idea.

This is why cloud services are a hit.

Security is baked into the service. You pay for the computing/storage/messaging resource like you buy electricity. The security is “someone else’s problem”  and let’s face it, the security professionals at Rackspace or Amazon or Google App Engine are better at security than we are. It’s part of their core business.

The next step after cloud services is the security industry evolving into a B2B industry like the automotive or energy industry.  You don’t buy brakes from a McAfee and a car from Checkpoint – you buy a car from GM and brakes are part of the system.

That’s where we need to go – building the security into the product instead of bolting it on as an after-sale extra

It is now time to slaughter one more sacred cow: SSL.

One of the most prevalent misconceptions with vendors in the medical device and healthcare space regards the role of SSL and TLS in protecting patient information.  When faced with a requirement by a government or hospital customer for compliance to one of the US privacy and security standards, a vendor usually reacts with the CEO asking his CTO to look into “solutions”. The CTO’s answer usually goes  like this:

I did some research. Apparently to be FIPS  (or HIPAA, or …) compliant we should use TLS and not SSL. I think that configuring the browser to be FIPS  (or HIPAA, or …) compliant may take a little work.

Action items are given out to the technical team, they usually look like this:

Joe – You establish a secure web site

Jack - Make sure all the addresses on the workstation point to https instead of http

Jack and Joanne - Compile a new version of the Servers and workstation to work properly on the new site.

Jack and Jill - Do what ever needs to be done so that the web services work on the new site.

That’s all – No other changes need to be done to the application.

Oooh.  I just love that last sentence – “No other changes need to be done to the application”.  What about patching Web servers and the Windows operating systems? What about application software vulnerabilities?  What about message queue vulnerabilities ? What about trusted insiders, contractors and business partners who have access to the application software?

There are multiple attack vectors from the perspective of FIPS and HIPAA compliance and PHI data security.  The following schematic gives you an idea of how an attacker can steal PHI, figure using any combination of no less than 15 attack vectors to abuse and steal PHI:

There are potential data security vulnerabilities in the client layer, transmission layer, platform layer (Operating system) and cloud services (Amazon AWS for example).

So where does SSL fit in? Well, we know that the vulnerabilities for a PHI data breach can not only happen inside any layer but in particular there are vulnerabilities in the system interfaces between layers. That means between server layers and client-server interfaces.  SSL  Quoting from the Apache Tomcat 6.0 SSL Configuration HOW-TO:

SSL, or Secure Socket Layer, is a technology which allows web browsers and web servers to communicate over a secured connection. This means that the data being sent is encrypted by one side, transmitted, then decrypted by the other side before processing. This is a two-way process, meaning that both the server AND the browser encrypt all traffic before sending out data.

Another important aspect of the SSL protocol is Authentication. This means that during your initial attempt to communicate with a web server over a secure connection, that server will present your web browser with a set of credentials, in the form of a “Certificate”, as proof the site is who and what it claims to be. In certain cases, the server may also request a Certificate from your web browser, asking for proof that you are who you claim to be. This is known as “Client Authentication,” although in practice this is used more for business-to-business (B2B) transactions than with individual users. Most SSL-enabled web servers do not request Client Authentication.

In plain English, SSL is good for protecting credentials transmitted between the browser and web server during the login process from eavesdropping attacks.  SSL may still be vulnerable to man in the middle attacks by malware that piggybacks on the plain text browser requests and responses before they are encrypted. Similarly, SSL may be vulnerable to cross-site scripting attacks like the Paypal XSS vulnerability discovered in 2008 that would allow hackers to carry out attacks, add their own content to the site and steal credentials from users.

SSL is a key component in a secure login process, but as a security countermeasure for application software vulnerabilities, endpoint vulnerabilities, removable devices, mobile devices and data security attacks by employees,  servers and endpoints, it is worse than worthless because it sucks the medical device/healthcare vendor into a false feeling of security.

SSL does NOT make a medical device/healthcare Website secure. The SSL lock symbol in the  browser navigation window just means that data in motion between a browser client and Web server is encrypted.   If you can attack the endpoint or the server – the data is not protected. Quoting Gene Spafford ( I think this quote has been used for years but it’s still a good one)

“Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit card information from someone living in a cardboard box to someone living on a park bench.”
– Gene Spafford Ph.D. Purdue, Professor of Computer Sciences and Director of CERIAS

This is all fine and dandy, but  recall our conversation from the CTO giving action items to his team to “establish a secure web site” as if it was point and click on a Microsoft Office file. The team may discover that even though SSL is not a very good data security countermeasure (albeit required by FIPS and HIPAA), it may not be that easy to implement, let alone implement well.

It’s no wonder that so many web servers are misconfigured by the clueless being led by other clueless people who never read the original documentation and were all feeding off google searches for tutorials. Yikes!

Most people don’t bother reading the software manuals and google for advice looking for things like “Tomcat SSL configuration tutorial“.  Jack, and Jill and Joanne in our example above, may discover themselves wandering in an  abundance of incorrect,incomplete and misleading information in cyberspace, which is mixture of experts who assume everyone  knows how to setup secure AJP forwarding and Tomcat security constraints and a preponderance of newbies who know nothing (or a little bit, which is worse than nothing).

Working with a client in the clinical trial space, I realized that the first and perhaps biggest problem is a lack of decent documentation, so I wrote SSL and Certificate HOW TO – Apache 2.2 and Tomcat 6, Ubuntu which I hope will be my modest contribution (along with this blog) to dispelling some of the confusion and misconceptions and helping medical device and healthcare vendors implement secure Web applications. No promises – but at least I try to do my bit for the community.

Whether you’re an account manager at Cisco, a programming geek in an Israeli startup, an expert on PCI DSS 2.0 or an industry authority on CRM; you must understand the culture in your workplace in addition to your professional skills in order to effectively manage risk and comply with regulation. If you alienate people – you won’t be able to improve security and compliance.

A few years ago, when I worked at Intel Fab8 in Jerusalem, we were chosen to train about 150 engineers for the Intel fab in Leixlip Ireland. I had two Irish people on my team. In particular, I remember Ronnie and Dympna (she told me – pronounce my name like “Debna”, you know like the DEC network adapter…) Dympna once worked for Digital Equipment Corporation and I spent years developing applications in VAX/VMS so we shared common language, the language of Digital networking equipment.

Before the Irish people came on board, the Israelis went through 3 days of cross-cultural training. We learned a lot, including how much Israelis and Irish are alike – strong family values, ties to country, religion (but not too much) and openness. Of course, the Irish can drink us under the table – which is probably why we had a great 6 months together.

There is a famous but true story about a Texas oil company that was intensely involved in negotiating a substantial business deal with a major company in Mexico. The American team spared no expense in flying their experts to Mexico and presenting the benefits and long term rewards of their state of the art equipment, hardware and excellent customer support. Throughout the negotiations and long hours of working together, both the Mexican and American teams developed a camaraderie and respect for each other.

The Mexicans were satisfied with the proposal and agreed to proceed with the deal. The Americans were delighted. They phoned their legal department in Houston and instructed them to fax the contract to their Mexican counterparts. Since they felt they had completed their job the American team jumped on the next flight back home.

The Mexicans were incensed! They wondered how the American team could be so rude and insensitive as to just fax a bunch of papers and expect to seal such an important deal after weeks of working closely together. The Mexican team refused to sign the contact tried to have as little contact as possible with the American team.

Eventually, when the Americans inquired about the delay and discovered what had happened, they immediately went into damage control. For the American negotiating team, the signing of the deal meant the final phase of a process. For the Mexicans, it symbolized the beginning of a relationship. They wanted to celebrate this milestone and make it personal. They wanted this important occasion to be marked by having all the major players and their spouses, from both sides of the border, to come together and enjoy a memorable dinner.

Fortunately, this story has a happy ending because the American team was able to recover and the deal was finally signed. The lesson from this incident is quite significant because it teaches us the importance of being aware of the different cultural perspectives. While the American business stance is to be task and results oriented, the Hispanic mindset places much more emphasis on the human side of business.

When dealing with customers in Europe (especially Italy, Israel and Greece) this lesson is just as valuable. Hi-tech sales and technology management is also about understanding the cultural differences. Whether they’re your customers, colleagues or direct reports – people want to see the business as well as the human side of your leadership abilities. They want to know that despite the language differences, you genuinely care about them and the work they do. Of course this is true in every workplace but driving home this idea and putting into practice, is much more difficult and challenging when there are different language and cultural expectations.

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

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

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

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

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

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

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

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

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

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

1. Rely on fixed controls

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

2. Train for security awareness

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I would take some lessons from the IETF.

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

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

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

However a guild of consultants is not enough.

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

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

1. End user line of business decision makers

2. Vendors

3. Hackers

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

Question No. 1 – Does your organization have a formalized risk analysis process? … 90 percent of the respondents, said that their organizations have such a formalized risk analysis process.

Question No 2 – Does your organization have an executive with a mandate to manage enterprise risk ? … only about 40 percent of the respondents had an executive with such a mandate.

Enterprise Security Risk Management Benchmarking Survey - April 2010

“That’s hard to believe, given that extreme events and risk management are making headlines almost every other day.”

In order  to understand why large enterprises invest in risk analysis process but not in risk management we need to take a closer look at Western (US and EU for the sake of argument) corporate value systems.

For a manager of a company on the verge of bankruptcy, equity compensation is a one-sided bet with upside only. For example, say the CEO  bets on a bridge loan at usurious terms in order to buy time to close an acquisition deal. If the bet pays off, his equity compensation pays off, but if he loses the bet (and the company goes bankrupt or is sold for a pittance), his personal compensation exposure is zero, but the stockholders, bond holders, customers and business partners will be left holding the bag.  Since it’s a one-sided bet with no downside, executives may also be tempted to adopt borderline business practice in order to proactively optimize their compensation.

Risk analysis provides invaluable input to improve business practice and reduce security breach exposure but you have to execute on the implementation of the security countermeasures and be prepared to hold them up to scrutiny of your peers on a regular basis.  That requires a strong work ethic, transparency and accountability.

Since executives are generally not held personally accountable for security breaches  - it is not surprising at all that most enterprises have  formal risk analysis processes but few firms have managers with  the personal responsibility to execute on security risk management.

Let’s return to our original question – ‘Is IT equipped to deal with clear and present danger?’

We now see that IT and their information security colleagues may indeed have the formal risk analysis processes and even the latest in data security technology countermeasures to reduce the impact of security breaches but they don’t function inside a corporate value system that rewards them for cost-effective security.

And that my friends – is already an ethical question, not a process management nor a compensation question.

• Bloatware/system resource consumption – if you’re concerned with anti-virus system resource usage, imagine layering another 100MB of software, another 20MB of data security rules and loads of network traffic for management just for the luxury of getting a good deal from Symantec on a piece of integrated software that IT doesn’t know how to manage anyhow.
• Software vulnerabilities – if you have issues with the anti-virus – you don’t want them affecting your data flows via the DLP agent. Imagine a user uninstalling  the anti-virus and impacting the DLP agent.
• Diversity – the strong anti-virus products have weak DLP agents – which means that the advantage of a single management platform is spurious. Having strong anti-virus software on your Windows PCs from a vendor like McAfee complements having strong data loss prevention from a company like Verdasys.
• Not a good fit for the organization – IT manage the Anti-virus,   Security manage the data security and never the twain shall meet.

There are 3 general classes of internal attacks that are never going to be mitigated by access controls:

Trusted insider theft

A trivial example is a director of new technology development at a small high-tech startup who would have access to the entire company’s IP, the competitive analyses, patent applications and minutes of conversations with all the people who ever stopped in to talk about the startup’s technology. That same person has access by definition but when he takes his data and sucks it out the network using a back-door, a proxy, an HTTP GET or just a plain USB or Gmail account – there is no way an Active Directory access control will be able to detect that as “anomalous behavior”.

Social engineering

Collusion between insiders, gaming the system, taking advantage of friends and DHL messengers who go in and out of the office all the time with their bags.

Side channel attacks

Detecting data at a distance with acoustic or Tempest attacks – for example. or watching parking lot traffic patterns….