My colleagues and I at the Beuth University of Applied Sciences in Berlin are researching the issue of security misconfigurations. We have some preliminary findings, but we need your help.
Have you ever…
… had a friend doing something rashly just to get it up and running?
… wondered how anyone is supposed to work with that ‘documentation’?
… wished there had been some kind of quality assurance when you looked at a config file?
… thought “I told you so” when an issue finally became an incident?
If these instances sound familiar, or if you are one of the lucky operators working in an environment where nothing like that happens, we’d like your help by participating in our survey.
Take our survey
Why is the right thing not being done?
Data being lost, leaked, distorted, kidnapped, or abused has become a regular event on the Internet. However, when we investigate these incidents we find that they are regularly caused by simple errors such as faulty or missing authentication, exposing services towards the Internet that should not be exposed, or simply disregarded updates.
These errors would have been prevented by “just doing the right thing” in the first place. But why is the right thing not done?
We want to get a better understanding of security misconfigurations, why they occur and how the operations community perceives them.
The operations community is full of lore detailing why misconfigurations happen. However, while these examples may seem obvious to operators, they are often not that obvious for many decision-makers. Yet, in the end, these determine environmental conditions such as tools, schedules, and priorities that play a vital role for the quality of work.
Preliminary findings
We first used interviews to get insights on the general sentiment in the community and the most common issues operators face. This is the first step towards acquiring comprehensive and quantitative data on that topic.
Although our interviewees show a large diversity regarding professions, experience and work environments, their statements on reasons coincided in key aspects: lack of experience, deficient processes, and the insufficient usability of tools are common themes, usually accounted for by, and supplemented with, unreasonable time and budget constraints.
Hence, there are many strings to pull but we are optimistic that the first hard data on this topic will allow us to better understand how misconfigurations, and thereby security incidents, can be prevented. Specifically, we are convinced that many incidents caused by misconfigurations can be prevented by providing decision-makers with clear data on the underlying pain points that lead to these mistakes.
Fortunately, the group of operators willing to talk about security issues grows as blameless postmortems become more popular and publicly available, one of many solutions suggested by our participants.
Call to action
We want to fully understand the issue of security misconfigurations, and for that we need your help. Please participate in our anonymous survey on security misconfigurations.
Regardless of whether they happened to you, or you discovered them, or you were the one who fixed them, we need your input!
What do you think? What can we do about these issues? Could it help to develop guidelines for management? Should it become common practice to evaluate whether in five years someone else will be able to service a system one sets up?
If you want to get a more detailed overview of the preliminary findings, see my presentation slides below and watch my RIPE 74 talk “Caught between Security and Time Pressure? ㄧ An Empirical Investigation of Operator’s Perspective on Security Misconfigurations”.
Original post appeared on RIPE Labs
Constanze Dietrich is currently working on her Master’s thesis at Beuth University of Applied Sciences in Berlin.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.