In my experience when a business brings security people into their systems engineering process they are trying to solve a problem. Usually there has either been a painful security incident or some security testing pushed them over the edge and they feel exposed. Sometimes they are undertaking a big enough change or the security implications of a change are so obvious that they realise they need to ensure security is covered off.
However, while the senior management of the business is looking to solve the security problem there is commonly confusion amongst the system engineering teams, the new security team and the middle management of the business about what it is they are asking for and what it is they are getting.
- The senior management of business sees this as a financial investment in solving a problem, they fund a couple of heads who focus on security and expect the process to start delivering security without necesarily a clear view of what that means. Although no more security incidents and better test results would be a good start.
- The systems engineering team initially see the security team as a problem to be navigated around or driven through. They generally focus on their own areas of responsibility and are unlikely to see security as one of them. They will often involve their customers, the middle management of the business, in any conflict or delay.
- The middle management of the business can be threatened by the security team as they are highlighting flaws in their day to day practices.They have committed their career to the organisation and see consultants or contractors who are brought in to drive change and improvement as a threat to their position and reputation. They also see a danger that the security change and transformation will distract the business from their own plans to drive the business.
- The security people often see themselves as the voice of sanity in a crazy world and find themselves trying to secure every system and remediate the entire enterprise at once whether it likes it or not.
What the senior management of the business really wants is a team of experts to tell them how much confidence they can have in their systems for a specialist area they don’t understand, and for that team to advise the business on how they can increase that confidence.
What they don’t want is a source of friction slowing down the systems engineering process or a source of conflict with middle management that needs to managed by senior management who would rather focus on generating revenues.
A good security expert dropped into a green field systems engineering process needs to tread carefully and understand the environment.
- What is the measure of security success being used by the senior management of the business? Incidents? Test results? Audit reports?
- How does the business measure and manage risk in other areas? (Legal, Compliance etc)
- What technical standards exist?
- What security standards already exist?
- What are the governance gates for systems design?
- Which teams or individuals are involved at which gate?
- Who makes the decision to pass each gate?
- How many systems are being developed at any one time?
- How long do systems generally take to deliver?
- Is there one centralised process for systems engineering or a series of processes distributed across the business?
- What projects are in flight at the moment? Are they open to change or too far through the process to influence without causing undue disruption to the business?
- What is the business strategy and plan for the next 6 months, the next 12 months or the next 36 months? Who is responsible for the delivering against the plan in middle management?
While gathering this information the security expert needs to start engaging with the system engineering team. Understanding the technical specialties they have or the business processes they are responsible for supporting and starting the long process of educating them about security.
What is clear is that the sort of transformation that makes security requirements part of every system delivery project is not overnight and cannot be mandated from senior management without significant engagement with the system engineering teams. Engagement is consultant-speak for conversations, demonstrations and gentle explanations not lecturing or hectoring or generating security panic among the system engineering teams customers.
If this sounds like a very light-touch approach that’s because long term change has to come from the system engineering teams themselves and cannot be imposed from outside.
One of the most satisfying moments of my career was with a large client I helped through this transformation of the system engineering process. After 12 months of engagement with the business analysts, the solution architects and the technology administrators I found projects coming to me for review at the design gates where all my normal security questions had already been asked and answered by the system engineering team. The security standards were already being applied and the architectures took account of the threats. I had made myself redundant for all but the most complex projects.
After a recent talk about ‘how security works’ to a large group of devs and their management (which I wasn’t initially hosting, but was called up to explain something), the DSO quietly folded up the flipchart sheet I had written on. At that point the Head of Dev said “Can I have a copy of that?” and they proceeded to very quietly squabble over the A0 sheet. It was nothing special (publicly available guidance) but it was detailing something they have never had explained to them in a way they understood.
That was a brief, satisfying career moment for me.
There’s still a lot to be done though – I agree completely that its a long term process where security people can’t get away with not socialising the issues within teams. In my current environment, ‘Information Assurance’ has been historically supplanted by ‘do a pentest’ and I’m undertaking a big resetting expectations exercise to tell them how they are probably over-spending budget on security and under-spending their time on risk by doing it this way.