Preface

This paper is not meant to be a disclosure or accusation. Although it is based on a true story and describes a rather concerning security-related issue, its focus is the analysis of security issues in projects heavily dependant on IT. Its primary goal is to serve as a guideline for people intending to do better than today.

Story

For a couple of months now DB Carsharing is largely advertized as a convenient car rental service (you can get cars on an hourly basis) offered by a company named DB Rent – a subsidiary of Deutsche Bahn – throughout all German railway stations. However, this public service becomes a potential danger to its customers – due to inherent flaws in handling of sensitive data, insufficient user restrictions and significant flaws in vulnerability management.

Social Engineering by chance

As I decided to sign in with the DB CarSharing service in a major German city, I was told by the station staff to create an account and get a special transponder card used as a key to open booked cars. Interestingly enough, I had to visit the luggage centre of the station to do so – no dedicated office or staff was available for dealing with new accounts. Of course, the luggage centre was crowded with people waiting for luggage. And the only available employee was having apparent difficulties to serve them in time.

I asked for a Carsharing account and she went to the back office returning with a large German Leitz filer labelled “DB Carsharing”. She opened it in front of me and tried to find the appropriate forms and instructions for the sign in procedure. To my great surprise, the filer did have a sheet of A4 paper sticking to the inner side of the cover. In large letters (at least 18 pt) I could read a URL, a username and a trivial password(!).

It was not much of a challenge to memorize that, so after arriving at the office (without signing in with DB Carsharing this day) I looked up the given URL and was presented a login form on my screen.

Does authorization matter?

I got curious and used the credentials I managed to catch a glimpse of within the filer - just to see if it will work. I could not believe that it did. As the username did just consist of the two letters sp and the name of the city I was in, I decided to try a couple of other cities and see if I can derive the trivial passwords. Of course, I could - getting access to at least 10 different user names with their password and able to act on their behalf. Unfortunately, the logins I have found did have extensive authorization far beyond of creating new accounts. I was able to:

• look up personal data of other DB CarSharing customers, DB Rent staff and even annual subscriber customers of Deutsche Bahn (the railway company) itself
• look up the customer's booking data – where they booked cars, when they did it and sometimes even why (the booking system did allow for a customer-provided comment within the booking)
• look up the complete list of cars (models, number plates, admission information), their locations, car history and damage reports

• assign a car to be moved from one location to another by DB Rent staff
• submit fictional damage reports for any car
• submit new bookings for arbitrary customers
• read internal company information provided for partners like organisation charts, contact data of “important people” and so on
• find additional logins with trivial passwords documented right away

Vulnerability handling

I decided to call up for the IT representative of DB Rent and notify him of the weaknesses. With the organisational chart at my hands, I had no trouble finding the right person. He did listen carefully to me and promised to investigate the issue. Something actually happened and a few hours later I was called up by a woman (responsible for the web portal administration) telling me that the issue is being worked on and passwords were changed as an initial measure.

Here this story might have ended quietly and I would have thought of just unfortunate conditions. I supposed that I encountered a newly implemented service where the project had tight timelines and the security engineers just did not have the time to get security “right” from the beginning. However, it did not have a happy ending like this.

Reoccurrence

One month later I checked again. I assumed the issue might have had organizational and technical consequences and most of the implementation of the security concept should have happened. I was not prepared for this – nothing has changed! The same luggage centre, the same security-unawareness throughout the (now different) staff, the same Leitz filer, the same username, but wait – a different password. The trivial password I got at my first visit was just the name of the corresponding city. Dutiful as people sometimes are, they changed it to contain numbers and letters. Namely, the telephone area code of the city prepending the name of the city. Of course they did the same stupid change to all accounts. As of current, they did change their password changing policy (the password changes every three months), but virtually nothing else did change with the process itself.

Analysis

The failure of security

Prevention

Prevention is all about preventing security incidents in the first place – checking if services do comply with the “least privilege rule”, training staff to be aware of security incidents and social engineering, making sure authentication works right, having an eye on the software in use and its vulnerabilities, taking care for firewall configurations and so on.

DB Rent made significant mistakes here:

• a publicly available web portal – not constrained to some kind of corporate intranet, not protected by the requirement of valid client-side SSL certificates, just available to anybody just secured by having a “secret” URL and a username/password prompt.
• staff completely unaware of security implications, without any clue about how to handle passwords or other sensitive information
• usernames and passwords which are trivial to guess
• completely unnecessary privileges to read and even change sensitive, personal or workflow-related information given to people who probably do not even know what all this stuff is for (if they ever happen to notice anything of it at all)

As I have not tested the portal for possible SQL injection or other vulnerabilities , I cannot tell anything about the software security, but it's a definite failure for “prevention” even without doing so.

Detection

Detection is hard to get right for most environments, that's why it uses quite a lot of manpower and technology where it's in place – configuring IDS, reading security logs and notifications, checking for “strange behaviour”, running malware scans.

Apparently, the DB Rent folks simply do not care about detection – they were not able to see that something weird is happening. Multiple rare users who normally log in from geographically widespread locations suddenly and subsequently logging in from a single “unusual” network having some login failures and requesting unusual data normally should trigger some alarm bells – it did not, indicating that detection schemes are insufficient to catch up with even most trivial security breaches.

Reaction

The reaction process to a security incident usually consists of

1. making sure that it does not happen again by modifying the preventive measures (here the circle closes up with prevention)
2. undoing the damage if possible
3. getting the culprit (which is the attacker for most security officers) by cooperating with the police and starting a lawsuit as a part of a marketing campaign accompanied by press headlines like “Vicious virus writer and hacker gets 18 years in jail”

The last step is mostly interesting for computer security related companies. The others might prefer not to go public so their possible IT security deficiencies can remain uncovered.

I felt lucky not to be sued by DB Rent – there was little I have done to harm their business. Unfortunately, they did not modify any of their preventive measures to turn for the better either.

Who is to blame

Luggage centre staff

Easy victims – ironically enough, the common view of IT managers would be that they “deliberately” gave me access to sensitive systems – so let's get them fired immediately. Of course, they probably are not to blame. They are just people having trouble getting their work done, unsuitable for the task of handling sensitive information in the first place.

IT manager

The primary concern of an IT manager is to make things “work”. Unfortunately, making things “work” in a tight schedule and with a tight budget inevitably means making security “break”. It happens on a regular basis so we all should know better meanwhile.

Moreover, IT managers themselves are often surprisingly unaware of security implications due to insufficient qualification in this area.

Project manager

The project manager's primary goal is to control that the whole project “works”, he does not take any interest in details, details of IT in particular. When everything works, is completed in time and does not put a strain on the budget (which in turn will be defined by his manager), he is not expected to care at all.

Security "Process Owner"

My first encounter with the “Process Owner” terminology was when reading a now rather old paper on IT Service Management by HP. It did define a process owner as someone who is

• accountable for a certain process to work
• able to understand the process end-to-end
• able to understand potential effects the environment can have on the process
• empowered to direct all of the involved personnel in order to actually make the process work

The process owner does not actually have to do all the work. As the mentioned paper states “many people may actually be responsible for carrying out different aspects of a specific process. But it is always the Process Owner who is accountable for the success or failure of the entire process.”

“IT security” does fit the process definition and does have the typical process phases (planning, implementation, change). So a Security Process Owner is compulsory for a project with high dependency on IT and therefore IT security as well.

The Security Process Owner might consult or even employ and coordinate security officers. A multi-billion company like Deutsche Bahn does actually have lots and lots of sensible IT systems to make sure that their neat white-red painted trains do not crash at 300 km/h. It is obvious that they indeed do have IT security personnel which would be sufficiently qualified.

As the Security Process Owner is by definition accountable for organizational failures concerning IT security, this might be the answer for the headline question of responsibility. Unfortunately, I was not able to find a position for a “Chief IT Security Officer” at DB Rent. So I do have a sneaking suspicion that they just “forgot” to employ one.

Conclusions

Security

One of the most significant things that can be said about security is that its results are invisible. Since it is all about risk and risk-mitigating factors, it does not make your life better when increased, it might not make your life worse immediately when reduced. It does not change productivity or quality of the goods of a company if it employs security guards or effects a fire insurance.

So security just costs money without any visible result – especially if you do not have a security incident history to look back at, raising funds for security will not have any visible effects.

Since probability calculus is a fairly developed discipline of mathematics, there are means to calculate the chances for having the amounts of incidents decreased albeit of reduced security measures. And of course to calculate chances for having incident counts increased despite of tremendous security improvements as well. Unfortunately, a lot of people (a lot of people having to decide on some security-related topic in particular) do not care about advanced mathematics.

Most people are able to estimate probabilities and risk (more or less) correctly in the real world, locking up front doors, using safety belts, having insurances, and not trying to cross highways afoot. But in the digital world which is new to all of us there appears to be no natural rating clue for risk.

Significance

The mentioned story is just a single example, but there are plenty of others. As I do work for an IT consultant I see a couple of similar cases per year, especially across small businesses. But processes and management can fail everywhere. In most cases it does happen due to individuals making decisions which they are incapable of making correctly, at the same time unwillingly to admit it out of fear, ignorance or misinterpretation. In other cases it happens because processes do not work as intended.

I used to be adherent to the popular belief that the significance of (and therefore the amount of attention and resources devoted to) IT security should correlate to the significance and relevance of IT itself within the business process. If there is something that drives your business or at least increases your productivity significantly, you better take some actions to make sure that you do not get screwed by some minor incident, right? I was surprised to learn that in the real world the answer to this rhetoric question is “no” whenever it applies to IT and “yes” whenever it applies to anything else.

Reasoning about this ambivalence I could think of different causes for this phenomenon – all of them dealing with people acting as individuals and the human mindset in general.

People who do not care

When we use information technology, we often do so as a virtual substitute for something that we truly and physically used a couple of years ago. We use word processors instead of typewriters or pen & paper, spreadsheet applications as a substitute for calculators or report sheets, database applications in place of old-fashioned files (not those on your computer, the ones in clumsy closets with card indexes). If everything was working fine and going well in the pre-computer era, how can all this expensive technical stuff be really so important that we can't live without it?

Of course this mindset does imply a certain degree of negligence towards economics and optimization impacts. But hey, be honest, did not you ever think of the “good old tech-free times” where everything worked “flawlessly” and was “much easier” and of course “better” that it is today? The human mind is doing fairly well when it comes to reinterpretation and transfiguration.

People who do not understand

Technology and the involved processes, dependencies, and effects are not easy to understand for non-tech folks. When a problem or a challenge occurs, you are used to just get a “solution” which makes a problem disappear. When thinking of information technology, having a “solution”nearly inevitably means having a black, noisy box placed in some dusty dark office corner. Undoubtedly, this is why all kind of “firewall” and “security” appliances or yellow-boxed “security” software do enjoy such enormous popularity.

However, security engineers know that security is an ongoing process – the environment, demands and applications are changing steadily. There is never going to be a day where you just can stop and shout “safe” – not even for a short period of time.

And technical engineers know that new technology rarely can be used just as a better substitute for old technology. Instead, new technology provides us with new possibilities and changes the way we work. Sometimes it even changes even the way we think, usually raising new questions and requiring people using it to pass through some kind of adoption process to be able to take full advantage of it.

This in mind, it is easy to see that there is no simple way to “buy” non-goods like security or technological advance – it is always a development involving a lot of people not directly related to security or technology itself. Imparting this knowledge has been the work of security consultants throughout the years. However, there still is a vast amount of folks unaware of this.

People who do neither understand nor care

As a combination of the two preceding types, everything said for each of the above is valid for those ones. It makes things worse, if someone who does neither understand nor care is forced to make some kind of strategic decisions because he was made a “Process Owner” by his boss for a process best described as “Make It Happen”. Lacking the information and the degree of attention needed to balance reasons for a security-related question, the kind of “solution” which is easiest to come up with is just forgetting that there ever was a problem and hoping that nobody would ever notice.

Epilogue

As there seems to be no possible way to just magically create sensitivity for IT security issues among executives (or, more generally, people in charge), the security folks must not stop to do their best to evangelise good security, responsibility and risk analysis. A critical mass of security-negligent management within business or public services can hurt them badly and unexpectedly, harming not only to the companies involved, but their customers and users on a large scale. Staying alert and arguing for awareness is important, as it is the only available way to increase overall security.

About the author

Denis Jedig is the co-founder of syneticon networks – an IT consultant based in Germany. Working as a consultant since 2000, he has been awarded as Microsoft Most Valuable Professional in the years 2002 through 2005.