Saturday, December 11, 2010

Back on my 2010 security predictions

For an ITsec worker, every year comes with some pieces of satisfaction and a lot of frustration. For instance, you'll hear about rocket-science ITsec techniques and observe that your neighbour's techniques are more snail-like, ostrich-like or dodo-like :-(

I did a few predictions at the beginning of the year of what would happen in the ITsec field, let's see if they actually happened.
What I wrote back then is given in yellow and today's comment is in white.
  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.
    Did not happen. There are traces of some attacks on Google's OS but nothing the depth of what happens on Windows. (so far)
  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).
    Did not happen. But I hear Symantec is on the subject and it's quite promising.
  3. Viruses will spread to Mac and iPhones up to the same level as that under Windows.
    Clearly did not happen, though there are a few examples of such viruses.
  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.
    Happened. I saw many examples of considering fingerprints as a good means of authentication, which it often is not, and worst of all: some companies start relying on "private questions" to enable users self-resetting their passwords.
  5. There will be reports about IT services clouding the wrong parts of themselves: critical infrastructure, already very profitable services, legally protected information...
    Certainly happened, though those companies will not make a failure report before they've withdrawn, which is no easy thing ^^ The funniest story I heard (nothing written, sorry) is that of a web development company whose managers decided to cloud infrastructure, thus turning Apache settings, PHP settings and so on into read-only, contractual, data.
  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.
    Happened, even Microsoft got into the market.
  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.
    Happened, see Day's comment on the original article: pleaserobme.com, a site that harvests Twitter to guess whose homes are empty and easy to rob. One could also quote personalized ads or so many articles on the web.
  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.
    I don't know yet whether governments will fail, but the current wikileaks wars certainly are an example.
  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.
    Did not happen, so far as I'm aware.
  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.
    Did not happen, 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.
    There's certainly some change, but I can't identify it so far. People seem to start being aware of the "information-side", as opposed to the "technology-side"...
  • 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.
    No change.
  • That service managers start budgeting time for service reviews and corrections, not only service implementations.
    No particular change.
  • 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.
    They didn't, though they reacted by adding sandboxes to the software. Makes me think of old families that had many children to "avoid" child mortality...
  • That my government stops being such a liberty killer about IT.
    Not happening before the next election...
  • [...]
  • 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?
    I don't know whether my readers did consider this situation. Did you?

Wednesday, December 8, 2010

Monthly ITsec Leadership Quotes and Articles: November 2010

The New CISO: How the role has changed in 5 years, on the Security Leadership section of csoonline.com, about the more business-oriented nature of security positions these days.

[FR] Certification: mandatory way for CISOs (La certification, passage obligé du RSSI ?), forum chat on the certification of CISOs.

A security evangelist shares his best practices, on NetworkWorld, with good insight about what really matters when you're responsible for the security of a big, heterogeneous, sometimes hostile network... very much of what I would say on the same matter.

Jason Fried: Why work doesn't happen at work, on TEDtalks, about a better time management suggestion: just cancel your next meeting!
(via Windancer - Stairway to ...Heaven?)

The Value of Cyber-Awareness Campaigns, on Healthcare Information Security Blogs, about a subjet on which I have very little experience and I'm happy to read insights

Schneier's approach to changing passwords, rational, as usual.

Why Your Next CISO May be an Attorney, on Healthcare Information Security Blogs. Though I may not agree with the content, I think it's a good reading.

Relationships in Corporate Security, Do They Matter?, on SecurityRecruiter.com's Security Recruiter Blog, about the importance of human skills in security positions.

[FR] The era of the non-technical CISO (L'ère du RSSI non technicien), on the French community site Security Vibes, about the evolution towards management people in security.

"There are three ways to deal with climate change: Adapt, manage, or suffer.", Admiral Thad Allen, HBR Nov 2010.

"Make the objectives clear, but avoid micromanaging those who will execute on them.", Michael Useeem, HBR Nov 2010.

"Management attention is your scarcest resource.", Robert Simons, HBR Nov 2010.

"People think that focus means saying yes to the thing you've got your focus on. But that's not what it means at all. It means saying no to the hundred other good ideas.", Steve Jobs according to Robert Simons, HBR Nov 2010.

Thursday, November 25, 2010

Internet Quarantine: Where IT Differs From Healthcare

As Bruce Schneier goes on the subject of quarantining potential threats away from regular users of the Internet, I think it's interesting to point a big difference between IT diseases and human diseases: we have the code. We have the specifications for the computer.
For closed source, the software maker has the code, which means that diseases or weaknesses can be fixed with more efficiency than any human condition.
For opensource, it's even better: everyone has the code, which means that everyone can look for a solution to a problem.

That's not to say that every Internet user is a qualified-IT-physician, it's just to underline that comparing IT and healthcare may not be so promising. Compared to medicine, IT professionals can fix a problem in no time and no money. Although there are problems of copyright in IT, it's nothing compared to those in pharmaceutical industry. The whole plan of the human body and interactions is still to draw. And we can spoil many computers, hours of computing, lines of code, reboots, for research without an ethical problem.

Wednesday, November 10, 2010

Please NO MORE Top 10 Security Measures!

I have a habit to collect web articles about security measures to apply for specific security situations. Those articles usually have a title like "Top 10 security measures for the administration of XYZ" or "Top 20 vulnerabilities in XYZ servers". And I now have a feeling that it's a bad thing to present a security approach that way.

Let's take a few examples:
What's good in these articles is that you can use them for what they are: a grid to think about your own security. But they don't provide exhaustiveness and, for that matter, they may not even be suitable for your own case.

That's a question of risk management (of course) but, putting away big words like these, you'd simply wonder why there are 5, 10 or 20 top measures and not 2, 6, or 11. The measures in these articles are gathered not to provide a level of security, or a level of security maturity, but to make for a long, publishable list. And that you should implement only the top 3 measures, or only measures number 2, 4 and 5 is left up to you. Not mentioning that you may not implement 2, 4 and 5 in this order but may very well begin with number 4 or 5.

What these articles lack is an identification of the precise risks addressed by these measures and the location of these measures on a security maturity scale.

Let's add an illustration to this (nasty) comment: Friends recently asked me to attempt penetration on a website that they wanted to secure. What I found was:
  • an easy access to htpasswd file,
  • obvious passwords that John the Ripper guessed in no time and
  • cleartext credentials to access the database.
If you look at the OWASP list, you'll find the corresponding measures at number 6 and 7. Yet, all Apache admins know that they are on maturity level zero. Furthermore, for that precise site, OWASP's number 1 (code injection) was almost irrelevant.

That's not to say that OWASP's work (or anyone's listed above) is not good. It is, and useful if used correctly. It's just to say that I'd prefer to see more "Beginner level 7 security measures for XYZ servers" or "What to do if XXX is critical for your company: From step 1 to step 4" articles.

Tuesday, November 2, 2010

Monthly ITsec Leadership Quotes and Articles: October 2010

A little late (in love, keeps one busy!)
  • Incident or Event Management: Keep it simple but real!, on the IT Security and Compliance Thought Leadership blog.
  • 25 Sure-fire Ways To Motivate Your Team Members, excellent reminder of the basics for team motivation and good atmosphere.
  • Security: Competence Never Compensates for Insecurity, aka Attributes of Leadership #17 on Joyce Schneider's blog.
  • [FR] A good security policy reflects the life of the company, by NetASQ's product director Jeremy d’Hoinne, addressing the future of firewalls, that is, something else, not firewalls. Traffic inspection, all-in-one appliances... Nothing new but I'm glad to hear that from NetASQ.
  • Transparency, accountability, and IT success (Michael Krigsman).
  • Help! No One Is Following Our Processes! on The Hitch Hiker's Guide to the ITIL Galaxy and Beyond.
  • How to Crush Dissent, on Rob Weir's blog.
  • Microsoft is a dying consumer brand, on CNNMoney.com, which is my feeling as, in very little time, Microsoft added up Vista, Zune, unwanted DRMs, Office 2007's frightening GUI, and missed the turn to smartphones and web applications...
  • "Companies up and down supply chains in numerous industries confront the same challenge: A well-intentioned individual action or demand aimed at making a business greener can create a long string of unanticipated consequences that collectively dwarf the benefits.", by Hau L. Lee in HBR, October. You could switch greener for any of: more secure, thinner, cheaper, more customer-friendly...
  • "Listen, don't broadcast", as a hint for a company's social media strategy, by Larry Kramer, same source
  • "One CEO I know fines people $1 for every e-mail he gets that he didn't need to see.", Rita Gunther McGrath, in HBR Onpoint, Fall 2010.
  • "If you think your people won't understand something, remember it's your job to explain it to them.", Stever Robbins, same source.
  • "[...] if things aren't going well, the teams are probably well aware of the problems. In fact, they've probably known about them longer than you have.", same author, same source.
  • "Most organizations penalize employees for the wrong outcome, even if they follow the right process. Perversely, others are rewarded for the right outcome, even when they flout the rules about process.", same author, same source.
  • "[...] the value of clear, honest, explicit communication rises exponentially with the size of the organization.", John Hamm, same source.
  • The whole article The Leadership Lessons of Mount Everest, same source, which I can't quote without reprinting it entirely. (Reprint R0109B)

Security ROFL 2

Firesheep and forcing SSL

All that Firesheep buzz lead me to discover that a Firefox extension wraps your web traffic into SSL if the remote site supports it. Very simple, neat, idea. (Thanks to NetworkWorld and thanks you Jicé for first noticing.)

Thursday, October 28, 2010

Leadership Learning 2: When a Security Measure Fails, Put it Away!

Just a lesson of common sense: when some security tool or practice is useless because it was ill-designed or because it's broken, or because the rationale behind it has disappeared, it's better to just get rid of it.

Just two examples:

Fun fact: Facebook Bug in Handling Who Accesses Photos

I just experienced a funny bug: Facebook lets me view photos of someone who is not a "Friend" anymore :-)
OK, it's not in every case, it's just when I had written comments on a photo and someone writes additional comments.

Say I have written a comment in March, on a photo by a friend named Alice (pseudo) :


And then Alice and I stop being "Friends" in Facebook. She doesn't allow anyone but her friends to access photos, so I shouldn't have access anymore. But today someone else writes a comment on that same photo and I receive a notification.

Let's click on the link to Alice's photo. Nice, I can view that old photo again! That I should be let in to see that photo and any additional comments is subject to discussion.

However, the big bug is that I can click on "Back to Album" and I get the complete album, which I certainly should not:


I don't know whether that's a common case or just a kind of local bug or exception...

Thursday, October 14, 2010

A little thought about computing clouds and physical security

Clouds are not so cloudy that they don't sit on God's green earth.
I was thinking that with so much data concentration, and data of so much value, what would prevent people to break physically into data centers to rob data?

After all, who says data banks says data hold-ups...

I can think of four reasons why they wouldn't make a hold-up to steal data from a data center:
  1. It's probably easier to steal it online.
  2. It's certainly safer to steal it online.
  3. If you're breaking into a place you've never been, finding what you're looking for may be messier for a data center than for a bank.
  4. The adoption rate of this kind of crime would probably be very slow: burglars are not accustomed to data centers and black hats are not accustomed to hold-up parties. They probably don't share a lot of "good practices".
Yet, these barriers do not seem to apply to States and polices. They can easily break into a data center, they do not fear any defence from the "victim", they have all the time they need, and they probably can gather people accustomed to both heated situations and computer hacking.

So I was thinking that data of interest to a State should probably not be stored within its reach.

However, I don't have a clue how the visibility of a criterion such as the geographical situation of data may evolve in the next years for the cloud customer :-|

Saturday, October 9, 2010

Back on the technology SPOF: practical case

A reader commented in private that the article about the technology SPOF was too abstract and lacked a few simple illustrations. The opposite would have been surprising ^^ The subject seems universal, which is no reason not to give a good example.

So, there I have it, example with an "all-in-one" security appliance, as is too often so often used in SMBs. It's mainly sold as a corporate firewall and serves many other uses.

The first SPOF is the hardware one. When the hardware fails, you've got a problem:

You can resolve that SPOF by adding another piece of hardware:



The second kind of SPOF is the network one. You have the backup hardware, but it's not available:

In this case, it's completely useless... You can solve this problem by making sure that the access to the redundant appliance is also redundant:


The third kind is the configuration SPOF. The backup is ready, working and available, but it's not used because clients are not configured to use it. For instance:

For this, you just have to configure the backup to be used in case of problem on the master or, if it's not possible, to setup an emergency procedure that switches from a configuration with the master to a configuration with the backup. That should look like:


Finally, and that the point in my previous post, you've got the technology SPOF, which means that both the master and the backup suffer from the same problem. This could be anything from "disk full" to "corrupted configuration file" ranging through "expired license". In this case, it's no help that you have a backup:

You just have to be sure about the list of the services you provide with that specific technology, and which of those are critical enough to require a reduced/degraded mode:

Tuesday, October 5, 2010

Monthly ITsec Leadership Quotes and Articles: September 2010

Back from vacations in Tunisia ^^
  • "Managers spread powerlessness by limiting information", Rosabeth Moss Kanter in July-August HBR.
  • "The powerless retaliate through subtle sabotage. They slow things down by failing to take action-a form of pocket veto, in which a bill is killed simply because time runs out", Rosabeth Moss Kanter, same source.
  • "Drawing a line between strategy and execution almost guarantees failure", Roger Martin, same source. The whole article is a jewel. A must-read for many managers.
  • "Antagonizing the performance engine [vs the innovation engine] is a really bad idea. The performance engine always wins in an all-out fight. It is, quite simply, bigger and stronger." by Vijay Govindarajan and Chris Trimble, same source. So true about security if you take performance=IT and innovation=ITsec...
  • "I don't see the legal advisor as a fusspot, always waving his law-code book. On the contrary, he/she must escort the company through its development and minesweep the legal area.", Sabine Lochmann, in the French review "Management", issue number 179 (my own translation). I feel exactly the same about the company's security officer.
  • A disturbing disconnect between CSOs and CIOs
  • Put down the pink stickies to improve your career
  • Too Perfect to Be an Effective Security Manager?, follow-up to the previous one.
  • Do All Hospitals need a CISO?
  • Zero Trust Security – The Technical Discussion, good note on the now-obsolete MZ/DMZ model and the fact that silos should never be considered "safe".

Thursday, September 16, 2010

An interesting use of Google Trends

Google Trends is a nice tool that gives you statistics about the terms used in Google web searches, in the form of curves. For instance, you can compare the curves of iPod, iPhone and iPad:


But there's also another interesting part, on the right: it gives you links to articles that were published at the moment when a peak occurred. The moments are correctly chosen for buzzwords like in this example, not always as well chosen for less marketing-oriented products. Anyway, that's often a way to apprehend the history of a technology, idea or movement.

Have a look at these curves:

Tuesday, September 14, 2010

Security ROFL

Let's have some fun about security.

Monday, September 13, 2010

Zero Risk vs. Decision Making

The ability to produce risk assessment, partly-innate, partly-acquired, is one of the most basic skills of successful managers.

While there is much value in the organized and systematic research for accurate information, the ability to assess risks in a situation where information is incomplete is a most valuable asset.

The first reason is that we often lose precious time in the gathering and precise analysis of data when approximate data would be good enough. To make it abruptly: you don't need to know where the arrow will hit to know that an arrow sent grossly in your direction is a bad thing. That's when you need someone with some instincts about risks.

The second reason is that some data can be impossible to gather, or hard enough to slow down the process of gathering it to the point of discouragement. For instance, if you want to pinpoint the ability to turn on a specific option of a specific security feature in a specific version of a specific software, which software you have not already bought and cannot test, you might get bored before you get the information. That's when you need someone with some culture and work connections, so as to get a better access to -or approximate substitute for- such information.

The third and most important reason is that management people delegate. In this case, the management would probably want to delegate data collection and make its own assessment from it and make a decision from it. That is, delegate the boring part and make the obvious decision (taking all the credit, Dilbert-like).

To be more precise, it is commonplace to see IT managers answer a question by another question, asking for more technical details when the staff come for more decision making. In this case, the staff ask the manager for his/her ability to fill in the gap between available information and complete information. (And the staff is probably aware of this gap.) So when the manager overlooks this request for decision and asks for never-ending technical or economical details, data or evidence, the staff feels like the manager is worthless. That is: once they have collected all the data, they can make the decision themselves, they're not stupid, thank you!

As a conclusion, I would say that Zero Risk is, of course, not reachable, but that managers should be aware that their staff regularly look for risk assessments from them, not for an indication that they should go and look deeper to reach Zero Risk. If they could, they would.

Saturday, September 4, 2010

IT and ITsec books I've read these last years

These last years, I've read a few interesting books about IT and IT security, so I list them down here, if you ever got a spare week-end ^^
The list starts with the language, name and author(s) of the book then, when possible, links to related blogs and newsfeeds. It's in no particular order.
  • [EN] The failure of Risk Management, Why It's Broken and How to Fix It, by D.W. Hubbard [BLOG] [RSS]
  • [EN] Applied Security Visualization, by Raffael Marty [BLOG] [RSS]
  • [EN] The Official (ISC)² Guide to the CISSP CBK, aka the CISSP CBK, by... the (ISC)²
  • [EN] Beautiful Security, by Andy Oram and John Viega
  • [FR] La fonction RSSI (The CISO position), by Bernard Foray [old BLOG] [old RSS]
  • [EN] The New School of Information Security, by Adam Shostack and Andrew Stewart [BLOG] [RSS]
  • [EN] Security Warrior, by Cyrus Peikari and Anton Chuvakin [BLOG] [RSS] [Cyrus Peikari's page, see "Articles"]
  • [EN] Security Metrics, Replacing Fear, Uncertainty and Doubt, by Andrew Jaquith [BLOG] [RSS]
  • [FR] Sécuriser ses échanges électroniques avec une PKI, Solutions techniques et aspects juridiques (Securing Electronic Flows with a PKI, Technical Solutions and Legal Matters), by Thierry Autret, Laurent Bellefin and Marie-Laure Oble-Laffaire
  • [EN] The whole ITIL v3 series
  • [EN] Geekonomics: The Real Cost of Insecure Software, by David Rice [BLOG] [RSS]
EDIT 09/06: Oh and I forgot the mythical The Mythical Man-Month, by Fred Brooks [Wikipedia]

Thursday, September 2, 2010

Companies beware of SSL decryption in your proxy!

The ubiquitous rise of SSL as a means of confidentiality pushes towards new security problems and new ways to manage it...
I guess we could have figured it out from the very definition of SSL, but to me it appeared only clearly at the beginning of this year. With this number of protocols using SSL, with this everyday HTTPS, with everyone buying things on the Internet, the SSL protocol spread to ubiquity and its use went from precise pieces of software and knowledgeable people to every kind of software and mainstream people. From this situation, I saw the explosion of:
  • bad implementations of SSL in all kinds of software,
  • attempts to attack the protocol, new (so to say) man-in-the-middle attacks,
  • bad uses of SSL (weak cypher, self-signed certificates for public use, etc)
  • impatience from top management about the inability of IT services to provide statistics about the SSL traffic of their employees.
For all these reasons, I made the bet 2010 would see the introduction of new tools to manage SSL, make statistics from it, filter it, assess its security and so on. I found that Forefront TMG (the name of MS ISA for 2010) does quite a part of the job by decrypting the SSL flows between the LAN and the Internet. Once decrypted, you can do all the usual with those flows: filtering, statistics, eavesdropping...

My point is: it's not a secure practice yet, and probably never will.

There are two parts in my argument, the first is the legal and compliance point of view. If SSL is encrypted, it's in order not to be read, as dumb as it may sound. The company might not be allowed, under the laws of the country, to listen to employees' encrypted traffic. For instance, in France, I wouldn't be allowed to listen to private connections to online banking sites. Plus it brings back the threat of the tactless/malevolent administrator.

The second part is the technological one. SSL is ubiquitous and, to some extent, that's a chance. It means that the client software may have a variety of vulnerabilities and weaknesses in the implementation of SSL. For instance, if the SSL traffic flows from three browsers, two media players, ten business applications, then a vulnerability would probably affect only one in fifteen pieces of software using SSL. The targetability of unproxyfied SSL can grossly be compared to the average of vulnerabilities of the various pieces of software that use it. The targetability of proxyfied SSL is that of the proxy.

Would you trust ISA better than Firefox? Suppose that you have an endpoint tool that examines SSL, if its security features are better than those of the proxy, you probably lose these capabilities during the decryption/encryption phase of the proxyfication.

Of course, SSL remains a cloudy mystery, threatening to some extent, but I think this is not the good way out of it. But let's have a look at these technos, because I'm sure we'll have to cope with them anyway.

Wednesday, September 1, 2010

The technology SPOF

When I'm thinking availability, a lot my time and thoughts go to the careful search for SPOFs.

  1. I do look for hardware SPOFs, like a unique machine doing an important job and requiring a backup in case of breakdown. [first step of a BCP]
  2. I also do look for network SPOFs, like making sure the backup has the same network accesses as the master machine, so that it doesn't remain alone, useless. The same is true for firewall accesses and all kinds of filtering that network flows do undergo. [careful execution of the BCP]
  3. I furthermore do look for configuration SPOFs. These consist of the rather funny case when the backup machine is up, reachable on the network, but the clients are not aware it's there and so don't undertake anything with it. This is usually the case when IP addresses are not switched automatically between the master and the backup or when a configuration screen allows only to type in one server, not two or many. Hopefully, this should not happen with MS Domain Controllers, the way they work (or we would hear this kind of SPOF more often). Anyway, it's still recurrent in many "small vendor" appliances and in the application world. [very careful execution of the BCP]
  4. Nonetheless, a terrific SPOF remains: the technology SPOF. You have the backup machine, it's reachable, and others are aware that they should communicate with it. But the backup suffers from the same technological incident as the master machine did.
    Say, for example, that the master breaks down because it fails to handle a large quantity of "client data" (or anything) that has to be treated. The backup will also break down under the same charge.
    Let's take another example, the server is an application connecting to a database. The database received a minor software update that changes something that makes the master server go crazy. The backup takes the job and goes crazy too.
    Third and last example, you have a nice application server with scheduled tasks that make needed job. One fails and the server goes down, unable to continue its work. At that moment, the backup goes up and launches the same scheduled task, failing also... [and that's outside the perimeter of most BCPs]
That's the time when you'd want to have another way to provide your service. That's the moment when you are forced to remember that the machine is not here just to be here and working, it's here to help provide a service. And that service may be provided otherwise. That's the time when you enjoy having a well-prepared DR plan, with forethought reduced/degraded modes...

Tuesday, August 31, 2010

Monthly ITsec Leadership Quotes and Articles: August 2010

Thursday, August 5, 2010

Fun Fact: Wrong Sense of Rotation for Deming's PDCA Wheel

Have you noticed how many times management consultants draw the PDCA wheel so that the way to climb up the hill is ACDP and not PDCA?

ACDP wheel
This picture from [GE] Paeger Consulting.

Saturday, July 31, 2010

Enterprise-Size Authentication Is Not Just About Avoiding False Positives

When you're setting up an authentication method for access to an enterprise information system or to the enterprise premises, you don't want to just worry about false positives. You need to worry about the false negatives also.

Think about the logon screen of an application or website, asking for your username and password. The biggest worry of IT people behind that screen is to make sure the wrong people do not access the system. I think they should also care about the number of times the right people can't access the system either.

That's no big math, but suppose you would change a logon screen with 0.1% of false positives and 1% of false negatives (each losing the company 0.5$ because of the time lost for work) for a new logon screen with 0.01% of false positives and 3% of false negatives. Additionally, suppose the logon screen is used by 10,000 employees five times a day, 300 days a year.

The change would represent a loss of:
2% of additional false negatives
x 0.5$ each time
x 10,000 employees
x 300 days a year
x 5 times a day
which equals 150,000 $ per year.

It makes sense to acquire the new logon screen (let alone its own cost) if dividing by ten the losses due to intrusions in this system saves you more than 150,000 $ each year, that is, if the losses due to intrusions are above 170 000 $ per year, roughly.

Friday, July 30, 2010

Monthly ITsec Leadership Quotes and Articles: July 2010 (and June too)

Positive Leadership: Invest in People Building a Culture of Innovation.

Leadership Essay by former student Vince Fitzpatrick on the SANS Technology Institute's "Leadership Laboratory". The author comes back on the leadership he used when he was first appointed as CISO. It really reminds me of my own beginning.

Executives are Not Stupid on RiskAnalys.is, helpful to debug IT workers and ITsec workers when they think that everything is the management's fault.

Five reasons projects fail on Michael Krigsman's IT Project Failures.

'Wicked problems': collaboration, risk, and failure also on Michael Krigsman's IT Project Failures.

CISO and CSO Reporting Structures on the Security Recruiter Blog, on the shift of ITsec from defence to legal compliance.

Why "Doing ITIL" Doesn't Work (And How to Fix It): a direct, simple, summary of why ITIL is no silver bullet. Keep in bookmarks in order to cool down a manager, some day.

Can You Compete With the Next Generation of Security Leadership? (Yes, we can.)

Wednesday, June 23, 2010

Leadership learning 1

Wisdom being to recognize wisdom when you hear or see it, let me put it down what I heard from a management old-timer :
  • When somebody asks you about the goals of a project, answer goals.
  • When somebody asks you about the ethics of a project, answer ethics.
  • When somebody asks you about the management of a project, answer management.
  • When somebody asks you about the deadlines of a project, answer deadlines.
  • When somebody asks you about the means or technology of a project, answer means or technology.

Thursday, May 27, 2010

Notes: Profile for a CISO?

I was at the 4th International Forum on Cybercriminality and there was a conference about CISOs' professional profile.

I just took a few notes and, seemingly, there are three major kinds of personalities for a CISO:
  • The pilot,
  • The architect, IT urbanist,
  • The administrator.
I have no particular comment on this, except that I think I am doing my best to be all three of these :-\

I was also interested in this definition they gave: "The CISO is the one who defends the ITsec budget."

Finally, they described an evolution in the profile of CISOs:
  1. In the 1990's, people became CISO by opportunism,
  2. In the 2000's, people became CISO through competition,
  3. In the 2010's, people are becoming CISO by choice or by vocation.
I'm happy to record that I'm in the 2010's :-)

Wednesday, May 26, 2010

Monthly ITsec Leadership Quotes and Articles


I'm getting more and more convinced that the leadership style of Bruce Schneier is what made him so popular. There is more of personality than leadership in his case. In fact, my way to answer about "the mixture of security and feelings" is very close to his. Two examples:

A few quotes heard at the 4th International Forum on Cybercriminality :
  • "Nowadays you learn more about someone from Facebook than from Edvige." (Edvige is a nominative information file used by the French police.)
  • "The problem is not adapting to the digital world, it's adapting to the border-less world."
  • "In healthcare, IT security is a deontological requirement."
  • "Estonia is ahead of us [ahead of France regarding ITsec]."

Oh, by the way, I finally got a hint on why do they all emphasize on "Information Security" rather than "IT Security": I think it's because they want people to understand that it's not an IT-only problematic.

Thursday, May 13, 2010

Transparency the Next Big Topic? I Don't Think So :-(

Here is a recent Bruce Schneier interview "If you don't understand the people you'll never understand security, says Schneier". I really appreciate Bruce Schneier for his stick_to_the_fact and be_smart_not_an_automate approaches.

However, when he says during that interview that the next big topic for security will be transparency, I think it's more of a wishful thinking. I can see three main reasons why the move to transparency will be very slow:
  1. Good transparency requires transparency from both the vendor and the buyer. I think the buyer will never see the point of publishing data about (in)security. Even if that's more or less a kind of corporate social responsibility...
  2. Some major players among vendors and some managers in whatever buyer's hierarchy do not want to play the game by the rules. They prefer it the way it is, especially if they have a good ROI/good wages and not too much stress. So, unless there is some interventionism, I think they will do their best to slow the move.
  3. If you're going to publish things transparently, you might think of it as a possible bad advertisement for your company. And the weak point is: most companies, buyers or vendors, do not know where they stand among peers on the criteria of IT security. So they will not want to make the first move and risk publishing what might be seen as bad results.
To my mind, the whole business of IT security transparency is, as most of corporate social responsibility issues, a wicked problem. For this reason, it will require some good leaders to design new models and, probably, some interventionism from States and big corporate players. That is: it will move slowly (decades, to my mind).

Wednesday, April 28, 2010

Fun fact: Google search ratios about problems, by OS

Search pattern

Number of results

Ratio of "problems"

"windows 98"21,900,000
"windows 98" problem6,770,00030.91%
"windows millenium"291,000
"windows millenium" problem77,50026.63%
"windows xp"124,000,000
"windows xp" problem61,400,00049.52%
"windows vista"80,900,000
"windows vista" problem88,200,000109.02%
"windows seven"2,900,000
"windows seven" problem551,00019.00%

Saturday, April 24, 2010

Monthly ITsec Leadership Quotes and Articles

  • Influential Information Security Leader on the Identity Theft Awareness site.
  • The oldie but still goodie An Absence of Leadership on the official site of Geekonomics.
  • My excellent colleague Guillaume Deraedt, at a regional chapter of hospital CISOs: "A CISO handles non-conformity", as opposed to the compliance view of handling conformity.

Saturday, April 17, 2010

Altering the philosophy of this blog

I have long felt that responsibility in information security was a hard management job.
I have always known, through personal temper, that leadership is an asset in every management position.

Yet it never appeared to me until a few semesters ago how much responsibility in information security was a job that required, most of all, leadership skills. For this reason, I have chosen to more regularly publish articles on this site about the leadership of information security, including good readings about it, even uncommented.

Among the reasons that conspired to enhance my point of view, here are a few:
  • Working as responsible in this field for more than two years now.
  • Realizing that the job is a drop about team management, a bucket about upwards management and an ocean about transversal and stakeholders' management.
  • Realizing that security is a lot about conceptions and misconceptions, and that vendors are better at it than internal managers of any company. And that reacting to this situation takes a lot of communication towards the teams.
  • Having Anton Chuvakin summarize one of my articles by naming my job "expert in security leadership", which made me think a lot.
  • Reading books like "Geekonomics", by David Rice or "The CISO function [FR]", by Bernard Foray.
  • Seeing that everyone is capable of designing a highly sophisticated security framework in his head, but less often implement it.
  • Reading a lot of blog articles from security experts, and writing a few, complaining about people's behaviour and misconceptions and calling for help, for people to change.
In the end, I have decided that the best is to help myself, rather than wait for others to change or wait for "top management" to give full powers. Heaven helps those who help themselves, as is said on both sides of the English Channel.
So now comes the time when I emphasize on leadership.

Comments, praises and amazements welcome.

Hacking a speed cam

France nowadays is full of speed cameras serving car owners huge fines and the ability to loose one's driving license faster than ever. The rebellious French all look for a way to sidestep those speed limitations. Here's a very clever one [FR], though it will never work. And it's a good laugh anyway.

Tuesday, April 13, 2010

Disk full : Moving a Postgresql database data folder

For testing purposes, I set up a Postgresql 8.3 database on a Windows machine. The hard drive space was too little for the use, so I had to move the data folder to another location. (I could not use the saving mechanisms because the remaining space was not big enough even for the temporary files required for the operation.)

This proved to be quite easy. However, you cannot keep the database running.
  1. You first stop the database service from the Windows from the Computer Management console,
  2. Then move the data folder to a new location with more space,
  3. Then modify the path in the config file postmaster.opts, in the data folder itself,
  4. Then modify the path that's given to the service when it's launched by Windows : in the registry, edit the ImagePath string at key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\pgsql-8.3
  5. Then restart the database service from the Computer Management console.

Saturday, March 27, 2010

iSEC recommendations following the Aurora attack on Google

I finally found some time to read the iSEC Partners recommendations about the attacks on Google and other companies, originated in China, in January this year.

This post is just to underline the very good reading it is for people in IT. I like it because:
  • It does not look for a silver bullet but lists several points that need be addressed.
  • It points out, as so many posts on this blog, that you first need to human understand and monitor what you do, before implementing costly solutions.
  • It also points out that you need to work on the security of the endpoints (users' machines), especially on updating regularly client software.
Well, just go and read it, it's six page long.

Wednesday, March 24, 2010

Official proofreader appointed ;-)

Certificate for Eric Biard as official proofreader

Tuesday, March 23, 2010

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.
)

Thursday, February 25, 2010

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.

Sunday, February 21, 2010

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.

Saturday, February 20, 2010

RSS feeds for IT and ITsec

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

Security:

"General" IT:

Friends:

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?

Thursday, February 18, 2010

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.)

Wednesday, January 20, 2010

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.