There is a lot of conventional security that is based on established ceremonies and an unquestioning faith that if we keep doing these things then all shall be well. If the ceremonies don’t produce the required results then we are deemed to have not performed them well enough - as opposed to it just being the wrong approach. The non-believers who point this out can even be subject to an inquisition for their heresy (it might even be unexpected).
Much has been written about security theater in this regard, although to be fair there is also much misunderstood security that is naively attacked as security theater without taking the time to understand the purpose of those controls - remember Chesterton’s Fence.
A wider example of such ceremonies is in what came to be known as cargo cults, most often in World War 2, where various Pacific Island cultures tried to recreate airfields and other paraphernalia in an attempt to have the planes and cargo reappear. There have also been analogies in software engineering such as cargo cult programming. The best summary of such failings come from Richard Feynman’s CalTech remarks where he rails against cargo cult science. His call for scientific integrity is something to remember in our own work.
The extrapolation of all of this can be seen as what Luca Dellanna has described as mimetic societies.
Let’s take a look at some examples of this that might feel familiar. You will see a pattern in each case where what was, and likely is, an important control may have been perverted by a ritualized version of it in the hope it can deliver results. It’s only when sufficient integrity is returned that these can be effective once more.
1. [Check Box] Compliance
Original importance: contrary to some snarky commentary, much of what is encoded in compliance regimes got there for an originally very good reason. Adherence to many compliance regimes actually yield a reasonably good baseline of control to build on. This is fine as long as it is viewed as mostly necessary but not sufficient for the levels of control your risk profile might need.
Ceremonial version: the problem is when this devolves into, so called, check-box compliance where satisfaction of the compliance regime is what matters vs. focusing on the intent of stipulated controls to mitigate important risk. Organizations build immense rituals, ceremonies and the equivalent of priesthoods to guard such rituals. This can crowd out alternative and better implementation approaches, or worse, it can stifle investment in additional controls that have less bearing on compliance that, nevertheless, represent important risk mitigating activities.
How to remedy: the main way to guard against this is to not have compliance as the goal itself, but rather to focus on risks to mitigate, controls to implement, for which some of those controls carry a compliance attestation burden. It is important to develop a common control catalog so that multiple compliance obligations can be achieved with a base of controls mapped to those. Another approach is to regularly do a bottoms-up assessment of what compliance regimes are still needed so that there is some regular pruning.
2. Risk Acceptance
Original importance: no organization can completely mitigate all the risks it faces. So, there’s always going to be some accumulated risk in your risk register. It’s important to make sure that such risks are reviewed at the appropriate level in the organization. This is so that the decision to accept that residual risk is consciously taken and perhaps other compensating steps or risk transfer undertaken.
Ceremonial version: risk acceptance starts out as a useful approach of informing and driving significant debates on residual risk appetite. Over time, though, risk acceptances are thrown around almost as an expected bureaucratic step in many business activities. You should be worried when the first question from some people (business, IT or otherwise) is “what do I need to do to record that I'm accepting the risk so I can move on?”
How to remedy: there are many ways of sustaining the strength and utility of a risk inventory management process, we talk about many of these here. But they all come down to making the “cost” of accepting a risk commensurate with its severity. This could be done by making sure the level in the organization at which something needs to be accepted maps to the degree of risk. This can also result in fewer risks being accepted - Board or CEO/CFO level acceptances are unusual as for many risks they would rather just mitigate it. It could also be how it is time bound along with compensating controls or other factors that are expected to mitigate the effects if that risk is realized. For example, a useful technique where some risks need to be accepted on, say, a customer facing application launch is to limit certain critical functions that might be exposed by the risk. In this way the business is highly incentivized to resolve the risks so as to be able to launch the full suite of functions. Keeping an appropriate level of tension in the process naturally stops the ceremony. Another approach is to have risk acceptances agreed by one leader be reaffirmed should a new person take that role. This is especially important to counter the occasional issue that arises when the risk is realized and the new leader might rightly say, “well I didn’t accept that risk!”
3. Constant Demand for Resources
Original importance: many organizations or security programs increasing their maturity need to grow budget and resources. But at some point you have enough resources to make progress in reasonable ways.
Ceremonial version: you become the team that year on year is simply knee-jerk asking for more people or other resources. Sometimes this is based on an ego driven need to grow because of a misguided approach to budget benchmarks. Worse, you may develop a ritual response that because you weren’t showered with all the riches you think your team deserves, this must mean that management doesn’t care about security at all.
How to remedy: clearly the main antidote to this is to take a commercial approach on how you determine what resources you need, and what your overall organization needs in order to achieve and sustain the necessary risk profile. This might mean that you do a regular zero-based budget to constantly check what new things can be funded by a reshaping of existing teams. This includes looking at where investment directed to you (the security team) should actually be redirected to the IT team to drive needed technology modernization. By far the best technique, or even just attitude, is to constantly think in terms of supply and demand of resources and to manage both sides of that - not just to seek more supply of resources. I’ve covered this topic here.
4. Password Rules
Original importance: there’s a whole history of why and in what form we should construct passwords to reduce the risk of their being guessed or easily brute-forced. There’s also myriad rules around password reuse across sites as well as rules to require the periodic changing of passwords, some of which even were justified when introduced.
Ceremonial version: but now many rules are simply not needed, especially forced periodic password changes, but we stick to them in any case because it’s an easy checklist security item. It's easy to stipulate and many people have just been bludgeoned into accepting the ritual of password changes and weird construction rules on all the websites you use.
How to remedy: move away from passwords as a critical authentication control and replace them with an array of more effective controls from phishing resistant cryptographic authenticators (preferred), other MFA through to anomalous login detection and step-up authentication driven device registration. But when you’ve done some or all of this then relax some of the more painful ceremonies around what passwords might remain.
5. Audits
Original importance: audits are necessary. Well constructed audits conducted by professional and credible auditors are immensely valuable to provide an independent check and balance on your work. I’ve always felt better having good auditors around me, both as a practitioner and as a Board Audit Committee member.
Ceremonial version: in some organizations audits can become ceremonial reviews of expected control conformance. This might still be valuable, but doing something that could be automated by continuous control monitoring is probably a signal the audit team needs to take a more strategic outlook. A more negative ritual for some audit teams is the apparent need to always find something to report on. This can result in increased risk inventory baggage that can detract focus from the right priorities.
How to remedy: leading audit teams probe whether the risks the organization focuses on are the right risks and whether they’re being mitigated in the right way. They additionally focus on identifying themes for leadership to focus on to position the organization in a better way for future as well as current risks.
6. Risk Governance / Committees
Original importance: like developing an effective risk inventory management process, a risk governance approach such as an executive risk committee is an important tool in your program toolbox - especially as you’re building or maturing a program. It ensures management support and gives you an opportunity to educate leadership on your challenges. It provides a platform to move from prioritizing tactical fixes to shifting the organization to better manage risk going forward.
Ceremonial version: over time, though, risk committees can devolve into a place where presentations are delivered to check the box that the risk committee “saw something”, or that pages of metrics are pored over at length. What happens in these ceremonies is the engagement of the business and IT leaders drops and the people (audit, risk, compliance, security, etc.) enmeshed in their rituals create an echo chamber of their own pedantry.
How to remedy: like with any meeting, a committee needs to be refreshed and constantly revitalized to maintain its usefulness. Now, there may be some formality required - especially in regulated industries - but for the most part the main trick is to only bring debates, issues, and problems to the committee. Anything that can be read in advance, that is for information or otherwise, shouldn’t take up committee time. Even reviewing metrics or other performance data should focus on the questions or meta-issues that stem from the interpretation of that data by the security team - including some solid recommendations. Always ask "so what?" about any topic. An always useful, enlivening, topic for such committees are incident or close-call reviews shown in case study like form. In short, focus on outcomes.
7. Professional Certifications
Original importance: being able to learn and demonstrate the mastery of a body of knowledge in any field of practice is vital. This is especially important when growing your career. There are ranges of qualifications that help you and potential employers gauge this, from relevant academic qualifications, rigorous professional accreditation (e.g. Chartered or Professional Engineer status) through to the myriad of certifications offered by commercial organizations or professional associations (e.g. CISSP).
Ceremonial version: a whole industry exists to get people through certifications as if the goal were to collect as many as possible badges as part of the ritual rites of passage into different roles. Sadly, as this has become commoditized it seems the main goal for the training organizations and some of those being trained can be to accumulate the certifications as opposed to the mastery itself.
How to remedy: the onus is on all of us to ensure we’re not overly relying on claims of competence solely based on commodity certifications. It’s also important to support the professional associations in their efforts to enhance quality and keep the body of knowledge relevant. For many, certifications have the most value in providing a structure for more in depth learning. All organizations also need to invest in training for mastery and to provide such paths from entry level to their highest levels of expertise.
8. Post-mortems
Original importance: post-mortems (or after action reviews) for actual events, close calls or analysis of what has happened to other organizations are crucial - to be able to find and apply lessons learnt. Post-mortems when done well can be an essential feedback loop for any risk program, especially the security program.
Ceremonial version: when post-mortems become a necessary bureaucratic step or event in a production environment (the thing people have to get through to close an incident), then they’re less likely to be useful. Worse, they focus on the immediate apparent cause as opposed to the true root cause, not following the path of the 5-Y’s. Even worse they can become a path of ascribing blame to people and so the ceremony, necessarily well-rehearsed by those subject to it, is the ritual shifting of blame or the recanting of the well-worn excuses of why the event happened the way it did.
How to remedy: the answer is blameless post-mortems and a rigorous adherence to its culture. I can’t describe this any better than the SRE book.
9. Information Sharing
Original importance: information sharing about threats, incidents, vulnerabilities or practices is important. No organization, even of tremendous scale, has sufficient aperture across the world to have a complete view of the information they need to constantly improve or to interdict an emerging threat.
Ceremonial version: the negative consequences here are less ceremony and more blind faith. In other words, the answer to any problem is a call for “more information sharing”. Unfortunately, this is rarely the case, and many organizations or communities across the public/private sector invest a lot in the sharing apparatus but not so much on the processes to actually make effective use of that information.
How to remedy: think of this as wiring together organizations. The purpose of sharing information is to achieve some outcome, the mechanics of sharing helps with that. Such mechanics are not the end in itself. Maintain the discipline that every information sharing activity has a cost (explicit and implicit) and so there should be a defined benefit worthy of that cost - which might be community benefit. But to realize that benefit then some outcome needs to be connected to that. For example, if you’re sharing information about threats, even just consuming threat intelligence, then you need to be able to show how that is wired into how you might better defend your organization.
10. Access Reviews
Original importance: it’s important to have continuous assurance that what people have access to (data, functions, services, etc.) is appropriate for their role. This is vital for not just confidentiality but also integrity and availability. The degree of stringency on access control will vary with your organization’s risk profile, but, all organizations have some degree of access control to maintain.
Ceremonial version: many organizations have to, by design or by imposition, conduct periodic access recertifications. The most weary version of this ritual is managers being required each quarter to review the privileges of their employees and to reaffirm or revoke those. That they are often required to do this with poor tools and insufficiently descriptive privilege names doesn’t reduce the perceived need for them to do this.
How to remedy: don’t do it. Ok, let’s be a bit more practical: develop alternative approaches to meet the need of policy adherence without the bureaucracy of reviews. This could be through the use of role or attribute driven privilege assignment (RBAC and ABAC). So, if your organization is maintaining a correct directory of people assignments you’ll implicitly maintain other policy adherence (yes, I know this is a stretch for some organizations). The other great approach if you have no choice but to review privilege assignments is to use privilege cluster analysis or other techniques (ML based or not) to give people guides to where excess privilege has accumulated or where anomalous assignments have occurred. Thankfully, there’s much more tooling available to do this.
11. Security Awareness Training
Original importance: training our employees, vendors and often customers on important topics to help them protect themselves is, of course, important. Even the more correct strategy of embedding ambient control so that people are intrinsically protected by the platforms they use still needs some awareness training about the importance to cooperate with, or at least not actively resist, those controls.
Ceremonial version: security training has for many organizations become an unquestioned ritual that many are regularly subjected to. The worst extension of this religion is the mandated phishing test that is exquisitely crafted to be practically undetectable and so can’t really fulfill its goal of keeping employees suspicious of non-routine requests.
How to remedy: the better approach is to keep implementing ambient controls and to look for the underlying security issue which needs resolving such that significant employee training or testing isn’t needed. For example, perhaps it would be better to invest in controls so a CFO can’t authorize a multi-million dollar cash transfer in an email - rather than train and test employees on business email compromises as the only line of defense. The same goes for moving away from passwords to phishing resistant authentication tokens. For what training needs remain then it should be integrated into people’s processes and roles as much as possible, for example the best developer education is inside an IDE or their overall SDLC process and the best education on data protection for customer facing teams might from their own leadership vs. a 5 year old PowerPoint presentation that probably requires you to break security policy just to get the macros working.
12. Breach Disclosures
Original importance: transparency is necessary. If an organization has a breach that materially exposes customer information then people should be told. This is so that actions can be taken to lessen the effect or to prompt post-incident recovery. Also, the prospect of disclosure that might be brand-diminishing provides a further incentive for security investments.
Ceremonial version: it seems we’re all paying less and less attention to the breach disclosures we see. I don’t really know anyone that benefits from the identity theft protection coverage provided any more. It also seems that (at least for a well handled breach) there doesn’t seem to be much brand impact on the organization affected, at least measured in stock price over the long run.
How to remedy: so what would make breach disclosure less ceremonial? There are actually plenty of activities that go on behind the scenes in well regulated industries. For example, if you’re a regulated national bank in the United States that has a breach, or indeed other types of control failure, then often outside of the public eye are some different types of rituals (prostration, sacrifice, recantation and more). These have the leadership of those organizations on higher watch to avoid recurrence. The regulators, in something akin to an immune reaction, promulgate an interrogation across the other major banks to see if the root cause is exposed there - and then require fixes. I’m exaggerating for effect (but not much). If the main goal of breach disclosure is collective learning and response then we need to do more things like DHS CSRB - perhaps with even more rigor and frequency, and to also create mechanisms to better incentivize control investment in many companies if the previous “fear” of a breach disclosure is having less effect.
Bottom line: over time many important risk mitigations become ceremonies. This blunts the effectiveness of the controls and in some cases outright perverts the original intent so that the control is not only ineffective but is actually counter-productive. You have to be constantly on your guard to monitor the effectiveness and the cost/benefit of the controls.