by Michael Helwig
A good security team is implicitly present in a multitude of aspects in an organization and its culture. However, often we see security teams proposing security requirements without taking care or even encouraging proper implementation of the proposed security concepts and requirements. But if security teams consider themselves as a mere function that is just setting the guardrails without business or users in mind, they will be reduced to that and will have no long-lasting effect on the overall security of an organization.
In traditional organizations, security teams often start with compliance, mainly defining standards, policies, and processes and expecting everyone to adhere to those. In smaller organizations, security activities might start on a technical level, trying to follow general best practices and avoiding issues in operation (incidents) that might result from a lack of secure configuration. In both cases, teams usually lack the perception of end-users who do not understand security well. Therefore security teams do not see the need to guide employees through a proper implementation and adoption of the proposed security best practices and requirements – leading to either frustration or ignorance on the part of the users. This neglect is to a degree understandable – a security specialist or sysadmin is not a project manager, nor can they be put in a spot where they must shoulder all the security responsibility for everyone else. In addition, the role of a security function can be severely limited by the amount of how much a business is willing to spend for its security capabilities. However, a security team not driving any projects and not feeling responsible for the actual state of security in an organization across all layers will likely fail in creating anything more than security on paper.
To form a successful security team, it is important to understand that security is more than a function. It is a living organism; it is water; it is a meme – it is whatever creeps into and influences every process, every design, every product of the organization increasing its resiliency in the best case – and what stays a bunch of documents no one wants to read and cumbersome processes no one wants to follow in the worst case.
Luckily, in recent years, certain areas of security – and especially product security – have transformed from a compliance role into an enabler role. The necessity of connecting security activities to business goals and thinking about user adoption has become more important. Their mission: Enable business to make business, to stay afloat by preventing hacks and incidents, and help product teams to deliver secure by default products with a reasonable effort which their users can use without getting frustrated by security processes. A good security team will look for ways to optimize processes and achieve security and compliance without spending endless time and resources on it. One key sentence formulated in CISA’s “Security by Design” principles is that (software) manufacturers should take responsibility for customer security outcomes. This, we believe, is the key sentence for a successful product security program and potentially even for a whole enterprise security program in general. What it means is simple: Feel responsible for implementation and not just formulation or configuration of good security practice. Feel responsible for the outcome – that includes bad user passwords, insecure authentication choices, careless sharing of profile information, post-it notes with passwords on the computer screen, etc. Take ownership of these issues and consider and prevent them before they happen. The work of a good security team may start with the decision on adequate security controls, followed by implementation or configuration, but it does not end there. A security team needs to ensure the user is made aware of the implications of their security-related decisions, grasp the reasons why security processes benefit the company, and encourage decisions that will protect the user – internal or external – of a company’s products and services.
If we widen the perception of “user” a bit, we can take the sentence from the CISA paper as a key attitude also toward an organization’s employees: A security team should feel responsible for the phishing rates, for the hardcoded passwords, and that users might avoid your security tools because they are so difficult to use and no one ever cared to do a proper rollout or onboarding. If people don’t talk to you about security concerns because they are afraid you will cause them more work without resolving their concern, you are ultimately failing as a security team.
In the same way that product security is moving to an enabling culture and the clear understanding of shared responsibility, traditional enterprise security needs to move to care about implementation and culture. It is no secret that there usually is a big compliance gap: A company has their ISO 27001 / TISAX / NIST, etc., audit done, but the experts inside know that the technical security level is still lacking, and good security practices are limited to a small scope of the systems and processes. Documents and process definitions exist but they are not followed, and if they are followed, their outcome does not really contribute to a better security posture of the enterprise. This is what we see as the most dangerous form of a compliance gap: Not the gap between documents that an auditor requires and which a company might or might not have, but the gap that exists between the compliance stated on paper and the actual security of a company’s systems and processes. This is the gap that matters when you are talking about security and this gap might not even be properly reflected in your risk management activities, which are usually based on paper and checklists as well. And ultimately, this is a dangerous gap between a security team and its users. The paper is just a transport mechanism. If the ideas and concepts formulated in the security team fail to reach the company’s workforce, then there is no communication, and no actual security improvement will be achieved.
Coming back to the title of this paper, the Doorman Fallacy. The Doorman Fallacy, as mentioned by Rory Sutherland, is this:
Business, technology and, to a great extent, government have spent the last several decades engaged in an unrelenting quest for measurable gains in efficiency. However, what they have never asked, is whether people like efficiency as much as economic theory believes they do.
Alchemy: The Dark Art and Curious Science of Creating Magic in Brands, Business and Life, Rory Sutherland, p. 126 f.
The ‘doorman fallacy’, as I call it, is what happens when your strategy becomes synonymous with cost-saving and efficiency; first you define a hotel doorman’s role as ‘opening the door’, then you replace his role with an automatic door-opening mechanism.
The problem arises because opening the door is only the notional role of a doorman; his other, less definable sources of value lie in a multiplicity of other functions, in addition to door-opening: taxi-hailing, security, vagrant discouragement, customer recognition, as well as in signalling the status of the hotel. The doorman may actually increase what you can charge for a night’s stay in your hotel.
The Doorman fallacy is not only relevant from a business perspective (e.g. a company investing in tools to save costs on it’s security team); it is also relevant from a security team’s perspective. A good security team is like the doorman in a hotel: They guard people on their journey to use the hotel’s services. They recognize customer needs, are helpful, provide useful guidance and pathways. They need to be concerned about the end-to-end service the Hotel provides. Their notional function might be to take care of systems, policies, or standards or do proper system configuration. But if they stop there, they are not only missing out on opportunities to show the value of their work but run into the danger that they will never have a real impact on the security of their organization. Taking care of the end-to-end process, security can become a business advantage instead of a mere cost driver. If a security team and the organization start to understand that the security team’s work is not only about formulating requirements, documenting and following processes, but that they are part of a business context and that their users matter – then we will see significant improvements in the security of an organization, the breaking of “security silos” and the start of a real security culture with security as a doorman and its own, valuable contributions to the business.
