Ivory Tower Anti Pattern

A Security team is like a central architecture team governing security aspects from a tower. When you form a centralized security team, the ivory tower anti-pattern emerges.

Before discussing anti-patterns, we should examine the pattern that caused them. Let's understand patterns, anti-patterns, proverbs, and principles.

Patterns

Patterns are recurring problems with context in place. For example, at a construction site, the rooftop gets flooded because of rain. The solution would be to add a drain and slope the rooftop so water flows through it. The context includes the forces involved: Do you have the investment? Can this be done in a mountainous region? What about legal rules and rainwater harvesting?

From Martin Fowler's definition, patterns are:

1. Reusable

2. Communication - people can identify the problem and solution via the pattern name

3. Proven solutions that are effective

To create a pattern, you should be able to:

1. Find a recurring problem in your domain

2. Identify the forces involved (context)

3. Develop the solution

Anti-Patterns

Anti-patterns are solutions that were suggested for the pattern or patterns that emerged due to system construction that cause consequences. To define an anti-pattern, you must first discuss the pattern.

(or)

Not going by definition and based on how anti patterns are shared, Anti-patterns are recurring problems that appear to cause consequences (debt) in the future.

Proverbs

Proverbs are advice without context or patterns without context. For example, the proverb "the pen is mightier than the sword" cannot be applied in the context of wars or peace negotiations. Many such proverbs circulate in the security industry.

Principles

Principles are good practices to follow that yield positive returns in the future. Some security principles are:

1. Trust but verify

2. Assume breach mindset

3. Secure defaults

4. Shift left

5. Fix what is reachable (can be considered a pattern)

Back to Ivory Tower problem.

The Ivory Tower Anti-Pattern emerges due to hiring pattern with forces involved such as investment constraints, organizations cannot hire a security engineer for each team (particularly in domain-based teams in microservice infrastructure). With limited bandwidth, organizations opt for a centralized team governing security from a high tower.

When a centralized security team governs certain quality aspects (security), they often don't engage with developers, stakeholders, or environments. The team simply issues opinions and best practices without understanding the infrastructure, culture, or developers. This leads development teams to take shortcuts or work around security rather than collaborating with a security team that lacks contextual understanding. This causes impediments for the organisation in delivering the secure product, block the developers , turning the development culture to untrust on security.

To avoid ivory tower, a centralized security team should work closely with developers, maintaining frequent communication. They should understand the environment, build systems, and involve developers in security decisions. To achieve this, the security team must be capable of understanding the technology and comprehending how teams prioritize and what they need.