For an effective security posture

I’ve been working in the IT field for more than 10 years now and I’ve worked with a lot of “security” teams within the companies I’ve been in. I’ve been a security guy (Cloud Security Architect) for a little over a year now.

During these years, I often noticed a blocking posture of the security teams, sometimes even disconnected from the field, leading to slowdowns and tensions in the projects.

Today, I’m going to present you the posture I chose to adopt and explain why. I will also give you my point of view with a little hindsight after one year.

A little background

In most of the companies I’ve worked for, security is often a mandatory checkpoint, but not necessarily useful or efficient… I’ll explain.

Often, this team is called upon at the end of the chain to:

• Perform a penetration test on an infrastructure
• Verify that the deliverable is compliant
• Ask for specifics “right passes”

Moreover, we avoid soliciting them as much as possible, because we know that the response time will be long, often in weeks.

To add another layer, I have often had to deal with people who are disconnected from the reality of the field concerning:

• the maturity of the implementation teams concerning cybersecurity
• tooling
• business needs
• delivery times

In other words, we often end up with a deaf language, each one not understanding the other.

When I arrived in my mission, I was in a position where a barrier existed between the dev/ops and security. The former did not understand the interest of the measures being implemented.

This barrier creates resistance to change and therefore slows down the speed of the teams, in addition to creating a not necessarily pleasant atmosphere.

Coming down from the ivory tower

One of the major issues, as I mentioned earlier, is the disconnect between the operations (DevOps) teams and security.

One of the first things I manage to deploy to improve this situation was to organize regular check-ins between myself and the ops.

In this model, the ops team is an “ambassador” for security. This doesn’t mean that I don’t exchange with the development teams, but rather that a SPOC (Single Point Of Contact) must be designated. Humanly speaking, I can’t talk directly to 200 people.

Indeed, the purpose of this point is mainly to be bidirectional. This allows:

• Security can present its roadmap in advance of the phase, by explaining it
• That the teams can bring up their concerns, needs or current blockages as soon as possible
• Generally speaking, this improves communication between entities

Moreover, taking into account the feedback from the “field” teams also allows adjusting as much as possible the tools or the security rules that are being implemented.

Be careful, however, the goal is not to justify the choices, but to explain them. You must therefore be in a pedagogical posture, and not be defensive or defensive.

Zero trust … yes, but not only!

I am a fan of the zero trust model (a blog post on the subject is coming soon); however, I am among those who consider it a model, a target to reach, not an immediate objective.

The concern I have often seen is an inconsistent posture on this subject:

• Hardening too much: we prevent teams from working by putting too strong a technical framework (for example, by not giving any autonomy on a software installation)
• Not being able to adapt a rule if it is too rigid (e.g., network filtering, or an incompatible protocol)
• Being in a blocking mode on a project, preventing any delivery

My approach is more to say that we need to understand the technical and operational constraints of the teams to see how we can best apply zero trust.

This means:

• That I sometimes tolerate giving more rights than necessary temporarily to allow projects to progress
• That it is necessary to trust the teams
• That we must show that we are available to answer questions, and that we are in a constructive approach, the goal is to find a solution

Supporting projects rather than blocking them

This is the point I often insist on. In my mind, security is meant to accompany projects as best as possible. The idea is therefore :

• To document upstream as much as possible, so that the information is shared
• To be available to help the teams
• To listen to the needs of the teams
• To have a benevolent approach
• To be in an advisory role rather than a “finished work inspector

You will have understood, I am completely in a DevSecOps approach, which, from my point of view, allows to be efficient.

Positioning oneself as a coach also saves time, by becoming a full-fledged project actor, it allows to be listened to and to ensure that security needs are taken into account as early as possible in the projects.

Adopting this posture also allows the teams to become allies rather than adversaries to be fought.

This also requires a lot of communication, as I often say, a large part of my daily work is to explain and document. The clearer and more available information is, the more the associated rules will be adopted.

This also means that a CISO must know how to surround himself with technical people in order to best support the teams. As a reminder, the role of CISO is not so much technical as organizational.

In conclusion

I apply to myself the rules I mentioned earlier, and I must admit that in one year, I have seen the direct benefits:

• I am asked at the beginning of the next ones to see what points of attention I can bring
• Security decisions are understood (not necessarily accepted, but the objective is understood)
• I am no longer seen as a blocking point

My approach probably comes from my background as an Ops person, which means that I myself have been on the other side of the fence. I am therefore better able to understand the problems that teams in the field may face.

This does not mean that everything is rosy, there will always be dissatisfied people, but instead of being involved at the end of the chain, I have become an actor in the projects.