We want to fully understand the issue of security misconfigurations. We have some preliminary findings. But we need your help: Please, participate in our anonymous survey on security misconfigurations.
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?
Does that sound familiar or are you one lucky operator working in an environment where nothing like that happens? Either way, only you can help us in our research by participating in our survey.
Introduction
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 which 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 yourself, you discovered them or you were the ones fixing them ㄧ we need your input!
What do you think? What can we do about these issues? Could it help to develop guidelines for the management? Should it become common practice to evaluate whether in five years someone else would be able to service a system one sets up?
If you want to get a more detailed overview of the preliminary findings, watch the RIPE 74 talk “Caught between Security and Time Pressure? ㄧ An Empirical Investigation of Operator's Perspective on Security Misconfigurations”.
Comments 0
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.