Top-Down or Bottom-Up CISOing?

What I thought, in my earlier years, to be a strategical choice now appears to me as a question of personal character of the decision maker: whether to take a top-down or bottom-up approach to the solving of a complex problem. When you're managing wide projects, you get to deal with many managers' characters and that may lead you to work with Single-Minded Top-Down Thinkers (SMTD) or Single-Minded Bottom-Up Thinkers (SMBU).

As a CISO, you have to solve complex problems: "get us compliance to that norm", "make sure that application is available 24/7", or even wicked problems such as "make us secure". And you have to deal with many decision makers among IT and more. So you cannot do without a prepared tactics to set a SMTD or a SMBU back on tracks.

SMBUs
If you let a SMBU deal with a problem alone, you'll watch him find a quick solution to the problem and apply it. But he'll forget to communicate about it, to document it for later re-use and, most of all, to compare it to the goals of the organization and ensure it's no hindrance to some other process of the company.

To deal with SMBUs, I take two actions:

1. I explain him what I intend to do with his solution to my problem. Not just the problem itself, I take the time to explain what's the goal and what my next steps are with it. So, he includes in his understanding of the problem all of my later constraints and does solve the problem and the later-on constraints.
   
2. I also take the time to recapitulate baseline procedures to communicate and document the problem/solution and I make sure he understands he'll be the one to clean up the mess if something was done unproperly.

Once you're accustomed, that doesn't take more than ten minutes.

SMTDs
SMTDs are usually more experienced people who have lost somewhere in the middle of their professional lives the idea that they must give results, not just thoughts. If you let a SMTD work a solution to a problem by himself, he'll give you diagrams of his view of the problem which he thinks is complete -or at least contains everything necessary- and he'll link your problem to a family of other problems that he has to solve and you'll get out of his office with ten times as much work as when you got in.
For instance, if you come in with a question about whether to purchase a new, different hardware, you'll get out with questions -and a few useless answers- about asset management, internal billing and wifi networks. And you'll realize that you don't have any clue to the answer about whether the company will buy it or not.

Over the years, I've developed a quick and dirty solution to deal with SMTDs:

1. Don't go into the long-term explanations of why you want to solve the problem, just stick to the short-term. That would last hours and would only worsen the depth of the SMTD's scope.
2. At the beginning of the discussion, do set, in accordance with the SMTD, a choice of as few as five objectives to be reached by the solution to your problem. This way, you'll be able to reduce the scope of his thoughts to what you agreed on. That is, you just need to split your problem and the surrouding areas in a five-item list.
If you take the example of the new, different hardware purchase, you just have got to reduce the problem, right from the start of the conversation, to the comparison of:
• prices,
• main features,
• delivery,
• compatibility,
• immediate satisfied customers.
There are many other points to be discussed, but you don't want to address them all. Not now, not with the SMTD and not in an all-in-one speech by him.

When you're accustomed to it, you can prepare these five pieces before talking to the SMTD and that doesn't cost time, that saves you time.

Adverse Effects of a Security Measure: the Example of French Speedometers

As far as analogies might go, I find the example of French speedometers a revealing example of security failure.

Automated speedometers have been installed in many places along motorways and also in town centers or in rural areas. Those devices take a picture of every car going 5% or 10% above the speed limit. The driver is fined a high penalty and even gets points removed from his driving license. The license is invalidated once 12 points have been removed.

That sounds good, but there are all kinds of problems. To name just a few design problems:

• People brake a lot when they see one ahead of them. They risk provoking an accident on a motorway just because of that.
• Whether they were "shot" or not, they' re angry about it and they then speed up a lot, knowing there won't be another speedometer in the next few miles.

People started knowing the exact locations of the speedometers or even invested detectors, bundled in iPhones, Androids or other specific devices. So the government sent the policemen roam the country with "mobile" speedometers.
And then came the social problems:

• Tax money is used to put fines on the taxpayers. If that's only in case of danger, that's good. But if it goes into fussiness, that's parasitic!
• After a short drop in the death rates of road accidents, the system reached its limit and the death rates started stagnating again. So the government intensified the pressure on policemen. They are now accountable for the number of fines given in their area. That measures the efficiency of the system on an irrelevant variable.
  
• Additionally, citizens are exasperated by this overpressure, clearly conscious that it's not an efficient security measure anymore.
• In a significant number of cases, policemen start to put fines in places where they can do it easily, whether there is a real danger or not.
• All that of course leads to a vicious circle where citizens are angry about policemen and about the government and where the "measure" of efficiency becomes more and more irrelevant.
  
• Eventually, the policemen are so pressured to put speedometer fines that they forget to put fines for other -actually efficient- reasons. For example, you'll find more cars in poor conditions (no light, flat tyres...) than a few years ago.

There's also the border effect:

• Foreigners are "shot" by the speedometers, but the French state doesn't know to whom the fine must be sent. In the end, they dont' have to pay and they don't risk to have their license removed. And they often profit from our beautiful roads at speeds higher than 180kmph. So citizens feel as if foreigners are better treated than themselves.
  

There's the implementation problem:

• In their rush to put fines, policemen just park anywhere, including dangerous locations! They are a factor of accident sometimes.

And finally, there are the typical VIP exceptions that plague any security measure:

• Police cars themselves are not subject to these fines, so currently the worst drivers you can find anywhere whether in town or on motorways are: policemen!

All in all, I'm impressed if the government behind that ever gets re-elected.

Been doing some reverse engineering

I've been reversing a Win32 PE executable lately, something I haven't been doing since I was 15. I found it quite easy. Much easier, indeed, than a few years ago. What's changed since then?

• The tools have changed. At the time, I used to master WinDASM and SoftICE, which are no more fashionable. It even seems that WinDASM has disappeared from the market. This time, I used HeavenTools' PE Explorer, which is a clear improvement on the latter.
• The PE format has not changed. Or, at least, nothing that matters in debugging.
• Windows is more stable than at the time, saving you many reboots ^^
• The compilers have not changed much. It seems that I could learn to recognize compilation styles of various compilers in very little time.
• Most of all, I've not changed. I can now remember very precisely why I quit reverse engineering software back then: because I prefer working with the source code and I prefer working in design or implementation modes rather than in debugging mode. I can now remember that I quit reverse engineering software approximately the same time as I started using GNU/Linux on my desktop.
  

I can clearly validate this view years later: though I'm happy to be able to reverse a binary, I think programming is more rewarding.

Smartcard and PIN or the Increased Security of Just 4 Digits

The French government is currently enforcing the use of what they call strong authentication, for all access to people medical data: smartcards protected by a PIN code, containing an authority-approved certificate. The PIN code sums up to just 4 numbers and the question came to me:

Why should I trust 4 little digits with my users' security? (when my password has 12?)

There are many subtle technical points within that question, but the main answer holds to only one key view of the problem: the reduction of possibilities, helping for the enforcement of good processes.

Compared to a password-based authentication, smartcards and PIN codes enforce the following:

1. Just one mechanism to integrate passwords and content on the card: that of the card itself.
2. Just one mechanism to ask for authentication: challenge. That removes the danger of "password comparison" mechanisms where you just have to look into computer's memory to get the cleartext password.
3. Just one administrator code capable of resetting the PIN: the SOPIN. That removes the danger of old, "unused" administrator accounts you find in most company directories.
4. Just numbers in the PIN code, no letters. Though this may seem like a weakness in the case of brute-force, that's on the contrary a strength, because that prevents people from setting their given name as password, or that of their son.
5. Additionally, users tend to remember numbers better. As a typical human being, you could name tens of likely alphabetic strings for your own password. But you remember only a few sequences of 4 numbers. So when you know one, that's for good.
6. Just three attempts, you can't easily brute-force it by usual means.
7. Just one logical place to deliver a smartcard: inside the company. You may send a password or even a PIN by mail, but you need to deliver a token, you can only do it physically and the only logical location to do it when you have dozens or thousands of users is inside the company's walls. That reduces the number of intermediates between the administrator and the user, and most of the time replaces external intermediates with internal ones.
8. Just one smartcard. 1/ If it gets stolen, you'll notice it. 2/ You can't share it with friends and still benefit from it at the same time. So you'll (at least) make sure you get it back.
9. Just one attempt to build the cards. I mean that the cost of a recall would be huge to change just a few security settings. For instance, if you choose to allow unlimited attempts instead of just three, changing it back to three will cost you a return of all cards back to the HelpDesk. This means that most smartcard-based project try to do the things right from the beginning, whereas many password-based projects start with "lower-level" security and try to improve on it and eventually give up about it.

All in all, PIN codes and smartcards seem a good choice.

Monthly ITsec Leadership Quotes and Articles: February and March 2011

General IT and ITsec management
The true cost of non-compliance is ZERO* (*If nothing goes wrong), on the Uncommon Sense Security blog.
I Broke All Six Rules for Finding the Right IT Vendor, on the HBR blogs, with insights on "best" practices when choosing an IT vendor.
A Disruptive Solution for Health Care, from the HBR blogs. Though not IT-related, I think this articles applies well to IT in the healthcare domain.

Trends
Educating the CEO on Mobile Applications, on the Healthcare Info Security blog.
Signature-based antivirus not quite dead, but bigger problems loom, speaking of the inability to maintain signature based security systems, and citing whitelisting, a subject of much interest to me these times.
How Mobile Phones Can Transform Healthcare, also on the HBR blogs.

Personal Development, Career
Chief Security Officer, 21st century, on the Security Recruiter Blog.
4 Skills CISOs need now, on csoonline.com.
The Four Personas of the Next-Generation CIO, on the HBR's blogs.

An internal billing scheme for IT risks

After meeting with a crowd of fellow hospital CISOs a few weeks ago, I had a sudden epiphany that the problem of billing IT risks inside a company is not just a peripheral one, but a primary one. And closely related to our inability to put figures on IT risks.

What about the idea of a CISO acting as an internal insurer for the IT service?

> Company board: regulates practices, if ever needed.
+----> CEO: checks correct operation.
+----------> CIO: acts as the customer of the insurance.
+----------> CISO: acts as the insurer.

The CISO would propose an offer made of:

• Expensive insurance for inappropriately acquired or ill-maintained IT assets.
• Cheaper insurance for IT assets that are acquired and maintained according to a set a constraints.

Security ROFL 4

• [FR] This is not the SSH 0day you're looking for, about a fake SSH exploit.
• [EN] Flower sites hit hard by Valentine’s Day.
• [EN] UK Immigration Officer Puts Wife on the No-Fly List.
• [EN] An Update is Available for Your Computer, through [RO] That's how it goes with updates, the piece of comics below:
  
• [EN] Unsecured IP Security Cameras, which I guess you can verify by yourself.
• [FR] On mikropikol.net, the following comic strip: