What is a CISO? [2/2]

Security is not about putting an appliance somewhere into the network, it's about mastering what you do. It means strictness, control, review, enhancement. That's not what the typical IT guy wants to do everyday. He wants to serve users with the lowest amount of personal work, which at first glance means without security. That's why security may primarily look like a constraint.

But it's not. Security is not only a constraint, it's an enabling mechanism. When you have good security you can do more things. A simple illustration is that you can drive very fast on a motorway because you have good brakes. If you didn't have them, you'd never allow yourself to drive faster than 60mph.

So, when I talk about giving staff a sense that security is not only a constraint, I mean underlining to them how much you can achieve with security that you couldn't without. Let me draw a few examples from live situations I've seen in companies or heard about on the Internet:

• When you have precise inventory management over computers and printers, you may be able to recharge other services more equitably.
• When you have a precise 1 identity for 1 account policy, strictly implemented, you may go one step further by implementing an SSO.
  
• When you are able to tweak and audit the work of your contractors for remote maintenance, you may be more willing to ask for remote maintenance.
• When you have backup systems, up to the task, for all of your main services, you can grant your admins an additional week off.
• On the same level, when you don't spend hours running after viruses, you can spend those hours on implementing new things.
• When you have a solid web proxy and a sound policy for it, you can grant Internet access to more employees.
• When you have an automated RBAC system, you can ensure users are served in a shorter time at their arrival in the company.

The thing is, security guys know this way of thinking about security but they most often communicate around obligations, constraints and legal requirements. That's why it looks as if security is a constraint. (Think about Dilbert's preventer, Mordac!)

(
That way of thinking is something I didn't see in Bruce Schneier's book Beyond Fear, however interesting that book is. (See Scott Granneman's notes about the book.) Bruce suggests a five step method to assess the value of a security measure:

1. What assets are you trying to protect?
2. What are the risks to those assets?
3. How well does the security solution mitigate those risks?
4. What other risks does the security solution cause?
5. What costs and trade-offs does the security solution impose?

But Bruce forgets about number 6: What do you get with that security measure besides protecting the assets?
That's why I think his view about a national ID card is flawed. When you live in a country with a national ID card as I do, you see that it allows businesses starting from the smallest shop to have a good idea about the identity of buyers, in case they would not pay. Sure the ID card is not impossible to fake, it's simply too hard for the passer-by to fake.
)

What is a CISO? [1/2]

What is a CISO? Saperlotte ! [in French in the original text, ed.]
People have tough questions sometimes. Or rather tough Google searches, as it seems that people often stumble across this blog when asking Google for an answer to this question.

CISO, Chief Information Security Officer, is a management and leadership position that often reports to the CIO or to the CEO. There are also CISO positions that report to the CSO, to the CCO or to the CQO. Even sometimes to the CFO. That's merely a hierarchical view of the question because, most of the time, the CISO has to work with all of these people and reports to several of them depending on the occasion. As a summary, the CISO is a C-level who reports to C-levels...

He's a manager because he handles projects, teams, planning and budgets. He's a leader because he needs to get things done that are of primary importance only to him. Said otherwise, most people in an organization can get very successful at their work without ever reading a security policy, let alone understand it, let alone help enforce it. So the CISO has to play his cards with some subtlety and some charisma to achieve results.

He's in charge of multiple things, but I summarize it this way:

• Integrity of data in the information system,
• Availability of services provided by the information system,
• Availability of IT services provided by external partners,
• Confidentiality of exchanges,
• Elimination of recurrent problems to decrease operational costs,
• Durability of services provided by the information system, in provision for changes in technologies or business needs,
• Conformity of IT practices with legal constraints.

The CISO has to write corporate policies and directions that support the previous goals, that need be approved by the board of directors. One hard part (for any C-level, I should say) is to propose long-term, innovative yet efficient, realistic, goals. And to communicate around it, because such documents are definitely not written to remain on a shelf.

The CISO has to deal with a number of "typical" phenomena about security questions, that happen in all organizations. Different CISOs react differently. Examples of such facts are:

• Irrational fears and sudden irrational fears,
• FUD used by vendors of security products,
• What I call the "TV effect", with the words of the presenter having more influence on the final user than those of the CISO,
  
• Over-enthusiastic users or managers,
• "Security theatre", the use of illusions that give users a false feeling of security, very common in security products,
  
• What I call the "side effect of security theatre", when users and, worse, managers ask for more security theatre because it feels great,
• The 3rd of Clarke's laws, "any sufficiently advanced technology is indistinguishable from magic", which clearly applies to ITsec, which means that most people simply believe you're doing magic,
• Managers rarely believing in magic as a profitable corporate asset,
• Legal department of most organizations having no skill regarding IT laws[...]
  

Next article on insight, philosophy and giving staff a sense that security is not only a constraint.

Note: If you're any surprised that I wrote "he" and never "she", that's because I never met a woman in this position. But I'd be pleased to.

The US destroying the Internet?

Every now and then I read or watch a scenario about the US destroying or dramatically altering the Internet, for security purposes or for commercial purposes. For me, even if that were feasible, that would be silly and I think that's never going to happen.
If the US were to destroy or reduce the availability of the Internet, others would rebuild it, anew, differently.

1. The US would get a considerable loss of earnings from a worldwide project probably not developed in English (Chinese?), not developed by American companies.
2. They would lose their technical skills. New skills would be required for the new technologies of the new network.
3. They would lose the target of their current spying methods, quickly moving to the new network.
   
4. They would not be able to create such spying methods for the new network, because they would not be the primary actor, centralizing infrastructure, skills and budget.

RSS feeds for IT and ITsec

In bold characters those that I actually enjoy reading each and every time.

Security:

• Google's research on the terms sécurité "système d information" hospitalier [FR]
  
• Schneier on Security [EN]
  
• Chaos Computer Club [DE]
• Decurity blog [EN]
• Devoteam blog [FR]
• En vrac, mais pas trop non plus... [FR]
• Anton Chuvakin's Security Warrior [EN]
• Orange Business Sécurité [FR]
• SearchSecurity: Security Wire Daily News [EN]
• SearchSecurity: Network Security Tactics [EN]
  
• Light Blue Touchpaper [EN]
• Knowckers [FR]
• LinuxSecurity.com [EN]
• Ma petite parcelle d'Internet... [FR]
• Security and Risk Management Strategies Blog [EN]
• Security Mike's Blog [EN]
• The Guerilla CISO [EN + Lolcats]
• Yui Kee Computing Articles [EN]
• Securitatea informaţiilor [RO]
• Logged [EN]
• SecurityRecruiter.com's Security Recruiter Blog [EN]
• The Microsoft Security Response Center [EN]
  

"General" IT:

• ITBoard [RO]
• IT&C - Cotidianul.ro [RO]
• Royal Pingdom [EN]
• Michael Krigsman's IT Project Failures [EN]
• The IT Skeptic [EN]
• Software, Interrupted [EN]
• Mini-Microsoft [EN]
• William H. Dutton [EN]
• BlogFish [EN]
• Linuxfr.org's main article feed [FR]
• Linuxfr.org users' blogs feed [FR]
• 451 CAOS Theory [EN]
  
• Bob Sutor [EN]
• Colin Charles Agenda [EN]
• Lodahl's blog [EN]
• Mark Shuttleworth [EN]
• Rob Weir: An Antic Disposition [EN]
• Groklaw [EN]
• Jim Grisanzio [EN]
• Internet Evolution: Nicole Ferraro [EN]
• linux360 Feed Aggregator [RO + EN]
• Pauza de Cafea Blog [RO]
• Quelques digressions sous GPL... [FR]
• Grupul pentru software liber [RO]
• Student la CS [RO]
• Valerie Aurora [EN]
• Încearcă software liber! [RO]
• Parinux [FR]

Friends:

• Blog de Jean-Christophe Lavocat [EN + FR]: Web technologies and search engine optimizations.
• 3R Technologic [EN]: Very active in web technologies and 3D technologies, though he doesn't post a lot. (If you hear me, yeah, that's a call.)
• Gregory Colpart's blog [FR]: Mostly about free software and GNU/Linux systems.
• /home/florian [FR]: Mostly about free software and GNU/Linux systems.

I also have my own feed Assaults on the Internet neutrality [*] gathering articles from all that I read on the web about governments and ISPs messing with the neutrality of the Internet.

Security predictions for 2010 and a few wishes

As usual, nothing posted on this blog is related to my job at my employer. These are merely thoughts gathered from readings on the web and personal considerations.

(If you're wondering why I didn't post this in January, think that holidays spent in Sicily, Romania, Hungary and Serbia are worth being late. I really love the Carpathians.)

1. Linux systems will become an interesting target for hackers because of Google's OS.
   The free software community will react fast to vulnerabilities. If Google is up to the task, they will integrate the changes very fast and it will result in Linux systems being the most secure. Competitors will finally be forced to take vulnerabilities more seriously. That's the optimist hypothesis. The pessimist one is Google not being interested in building better security and not reacting faster than the others.
   
2. Microsoft will (finally!) propose a centralized software installation and update manager, quickly adopted by the big software companies, reducing the number of heterogeneous installation modes, late updates and so on. Something apt-like, in a Microsoft-way, of course.
   It's either this or Microsoft platforms will be progressively abandoned for integrated products such as iPhone or platforms with that functionality such as Linux (servers) or Mac OSX (clients).
   
3. Viruses will spread to Mac and iPhones up to the same level as that under Windows.
4. Generalization of new authentication modes including smart cards with microchips, user/machine certificates, fingerprints on laptops, will happen.
   There will be a fashion for it and a lot of blunders will be made in the beginning.
5. There will be reports about IT services clouding the wrong parts of themselves: critical infrastructure, already very profitable services, legally protected information...
6. There will be an overflow of non-browser software using SSL.
   Each of them has its own libraries and each blunder or vulnerability in the use of SSL will have to be addressed in each of these libraries. This is not addressable in a correct time. For this reason, there will be new products or services around gathering all this SSL traffic and forwarding it in an actually secure way.
7. Social harvesting will rise to unprecedented peaks. Because of poor legal harmonization (or even concern, for that matter!) in various countries, automated social harvesting services will be made available.
8. Governments from developed countries will try to censor, filter and/or index the web. They will fail for two major reasons:
   
   • The web is too huge for any current government to master it, or even understand it.
   • The free software community will sidestep any technical measure towards censorship.
     
9. There will be stories, news, rumours, about Google having connections with the US intelligence agencies. Google's business is a source of information just too much important nowadays for intelligence agencies to neglect it. I won't tempt any prediction about Google's reactions.
10. PCI DSS-like standards (simple checklist, minimalist, technical, yet very efficient) will be published about various matters of ITsec. Or maybe I just read too many people interested in that.

And now a few wishes:

• That people stop thinking I work on viruses when I say I work on ITsec.
• That IT managers (non-security) stop thinking there is a fixed list of requirements for security and each of them requires purchasing a "security product" and each of these products works standalone.
• That service managers start budgeting time for service reviews and corrections, not only service implementations.
• That Adobe distinguishes between PDF designed for review and printing and PDF designed for automated administrative tasks in complex forms. This may prevent a lot of problems to come.
• That my government stops being such a liberty killer about IT.
• [...]
  
• That my readers consider the strange situation of using an Excel-controlled Visual Basic script to interact with an AS/400 terminal emulator, written in Java, inside a Citrix session running on a Windows Server "cluster" inside a VMware architecture. (You can have screenshots and photos of the AS/400 on IBM's website, for instance, there.) That was my only nightmare these last years. Does virtualization never end?
  

Have you heard about CSRF?

Cross-Site Request Forgeries are probably the simplest kind of attacks against unprotected websites. It simply works with a site A that the attacker owns (hacked or hers) visited by the victim, making a request to a site B where the victim is authenticated. As the victim (or rather her browser) is already authenticated on B, the request succeeds and the site A gets the content, and is free to make whatever it wants of it.

For example, in one tab or window, you'll be having a look at your bank account (B). On another tab or window, you'll be visiting a random page, say a blogging page (A). The page A contains code that makes a request to the bank site. The bank knows you're currently connected and thinks it's a regular request. And responds to it. So A receives informations about your banking accounts and does whatever it's meant to do with it.

When I discovered about this kind of attacks, I couldn't suppress a roar of laughter. That's so easy that I wondered how dumb I was not to have thought about it myself.

I can remember two years ago foretelling my friend and former co-worker Gabi Popa that it would become a major problem in web apps. Now, both the OWASP (since 2007) and the MITRE put it in the top five of the worst problems of web apps.

I think it's a problem that's going to last for a long time because the source of the problem can be identified both in the web apps and in the web browsers, resulting in a "no-one moves first" situation (delaying the moment when the developers of one side will roll their sleeves up and act.)

Reduce the number of technologies, not providers of!

In some of the companies I've visited over the years, there was an internal policy that seemed strange to me: when contracting with service providers or goods providers, employees of the company should try to keep the number of providers as small as possible.
It's not the policy in itself that seems strange to me, it's the fact that it is also applied to IT goods and services.

Basically, the policy relies on the two ideas below:

1. With fewer providers, you can purchase more of the same and negotiate a better price next time.
2. With fewer providers, you can establish true relations of trust and avoid gaps between what's asked and what's provided.

That would mean that the cost per unit decrease if you remain with the same provider:
However it relies on the three following assumptions:

1. Purchasing at a specific provider will impact the price of other providers only downwards, and that will be only a small impact. This is wrong in IT, because the cost of moving to another provider is very high, because of software and hardware incompatibilities.
   
2. You can negotiate with providers. This is wrong in IT, because you're always speaking with big international companies. If they allow you to negotiate, that's within an already well-thought area.
   
3. A true relation of trust brings a really better service from the providers. This is wrong in IT, because the hardest part is always the exploitation of a product or service, not its purchase. Good relation with the provider only marginally increases quality.
   

In fact, because of incompatibilities, once you've made a move toward a provider, the cost (not price) of moving to something else shoots up. It will require time, money and will probably require you to throw away what you made in the first place.
Knowing that you can't move anymore, the provider you chose has the hands free to increase prices.
That's what happens in reality:
So, to my mind, the policy of reducing the number of providers is detrimental to IT services.

However, the real difficulty coming from the integration of very complex technologies, very differently thought, born in in very different companies or universities, and best manipulated by people outside your company (either service providers or editors), I think it is a good policy to maintain a list of technologies that you use, the (in)compatibility links between them and to think carefully before adding one to the list.