Lessons learned in Security Evaluation and negotiating with Governments

What an old memory I found!!! What did I learn from it?

Quality,????????????????and ??????????????. And 2 crucial skills.

Why did I receive a certificate for high-level IT Security if the "winner" was the client, not me?

Well, the way these certifications go is that the client has a product that they want (actually ????????) to certify to be resistant against attackers/hackers with high attack potential before being able to sell it on the market.

And the way to obtain that is to entrust the experts of one of the few companies worldwide who are accredited to perform this type of evaluation.

—

I had the honour of managing the team that made that evaluation a success!

They were working on the real deal, doing source-code analysis, penetration testing, logical attacks, physical attacks, and whatnot.

I was responsible for the compliance, for keeping the pieces together, for the formal certification part, and for discussing and negotiating with the Government.

—

Because, in the end, it's the Security branch of a Government that analyses the reports and evidence of the whole evaluation, and can decide to issue the certificate (or not, in which case the product needs either fixing some features or more testing).

—

- Quality

There is never enough Quality. I trained and worked with the highest quality standard (Military ones) for documentation, compliance and certification. People who worked with me know I have a great eye for this.

And yet... no matter how many times you revise a document, there is always something that will slip through the cracks -> even more so if you are the author.

Sometimes it's just a semicolon, sometimes it's a typo, sometimes it's a blunder.

It happens. Be prepared, and have a system in place to minimise it.

—

What else did I learn?

- The clients are always right... until they aren't

Pushing stringent (read: unrealistic) deadlines can be good to some extent [and I don't even know how we could manage to meet them at times], but the commercial needs cannot endanger the security.

Especially in cases where the security might impact the safety of the users.

—

- The team is always right... sometimes just a bit overenthusiastic!

The great privilege of working with those best-in-class professionals is that they were passionate about what they do, finding bugs and things that need to be fixed or a logical fallacy, or a mistake in one step of an algorithm.

Some of that stuff would make your head burst if you'd try to understand it.

Doing all the complete analysis to quench their thirst would take a year or more, and that's not feasible/viable/realistic.

—

The two crucial skills I learned:

1 - People often like what they do, but does not mean that they like HOW they do it.

The timelines, the (often unnecessary) pressure from the client, the mandate to adhere to the standard and not let them "play around" with the nice piece of technology they had in their hands... the part of writing the report, the inefficiencies...

And yes, probably at times I have been part of the problem... truth to be told, sometimes with as little decisional power as they had, because it's just the way it is.

But with a great will to improve things and make them better, challenging decisions and institutions when it made sense to do so.

And you know what?

Not a complaint about that: when you bring solid arguments in a polite way, there is almost always space for a civilised discussion.

—

- Being in the middle is not always fun!

There is a balance between analysing every line of code and possible facet of the product, and the client that has the urgency to put the product on the market yesterday.

Both of them are right of course, so frictions happen - oh if they happen - and it was my responsibility to find an acceptable middle ground (thankfully supported by other smart people, including sometimes escalating to my line manager at that time).

—

2 - Gauge people with (constructive) probing questions

What makes you say this? What if we do this other thing?

Are you totally sure your interpretation of this norm is correct?

What if we read this requirement in this other way?

Have we done all that we could to follow the certification standard?

(common answer: yes but I ???????? we are so close to finding something else!)

Honestly, I probably quite disliked that part.

—

- In hindsight, that is a GREAT GIFT for what I do now:

Gauge companies with (constructive) probing questions, listen to them, deconstruct all that hinders them from having the results they deserve, brainstorm, challenge them on some points - at the risk of sounding stupid.

Uncover the inefficiencies that have become so much part of the everyday work they are often overlooked... every company has them!

And when you address them, the whole system (people, processes, interactions) starts working again like a well-oiled machine, and you increase your Productivity: returns, margins, results, etc.

Do you have someone in your company who would challenge the Executive team with constructive questions at the risk of sounding silly?

If not, probably you might want to have a conversation with me and discuss potential synergies.

??? Just send me a message!