When to bring in Security resource for project meetings

and when not…

Security is a key part of any business project new or old. It should be the heart of any design, and all should have the vision not to implement X without 100% sign-off from Security and Governance.

With that in mind, we should make sure we have a security resource in all meetings?
Nope

Security resources should be included in the initial decision-making meetings where input is required. That means that before the project decided what they are implementing and have purchased X, they will have needed to run it by an operational security resource and governance.

Why both? 
The reason is different levels of knowledge. Often “architects” or governance have a certain focus on their day-to-day. They know the high-level design and expectations however they don’t know the true run model. They won’t know the integration headaches, skill gaps or operational true state (Not just documented).

This is where the operations resource comes in. They won’t know the business’s high-level strategy due to not being invited to that kind of meeting, however, they will know clearly, what is running as of today, and be able to spot potential headaches or weaknesses. If it doesn’t fit the now, they will most likely be able to explain why.

After you’ve stumbled over the initial hurdles and purchased X for the project, the next stages are where to plan time. Again, a Security person doesn’t need to be present in every meeting. People on the project should have a security mindset already, so simple questions such as “Will we install AV” can be answered outside of the security department. A lot of the questions you may have should also be in the company policy or documentation on how business A runs Security.

When do we bring them in?
When it is relevant. Sharing designs prior to meetings is always a good idea. Security is vast so cannot always be answered on the spot. It would be more time effective to share the discussion prior so that the resource can review and come up with knowledge answers. Security often requires input from others, so again providing documentation/design ideas prior to meetings will only benefit.

If the security resource has no questions, then continue to plough ahead. Security should never be a blocker and instead should complement the design. The only time security is seen as a blocker is often when the project has no regard for security. For example, floating a server on the internet without thought due to roaming users. If you are going to propose that, you will have a lot of questions to answer.

Collaboration tools are also a great benefit nowadays. Meetings are slowly becoming less relevant, and targeted conversations are becoming the norm. For example, we don’t need to wait until Friday at 2 to discuss Security when the resource is free now (Monday, Tuesday etc..). Ping them a message, or speak directly for any concerns or questions.

Availability
Similar to my points above, the availability of a security resource is questionable. In the security space, we can’t plan an incident. It’s often best to attempt to bring them in on schedule however, on the fly will work with a more targeted audience. In doing so, you will often get more focus, rather than have them sit in a 1 hour meeting to simply say “bye” at the end.

It’s true, these points above may be relevant to non-security personnel however, in the cyber security space, it’s very relevant. Security can’t just be a tick box anymore, and the responsibility or knowledge of how you operate should be known throughout. Knowing when and how to bring in Security resources will only benefit you and the outcome of the project. In cases where security is stretched (Most cases), you will see the most benefit. Often, the resources can’t give 100% focus as they will most likely look to secure and move on due to workload. Security isn’t tied to recurring meetings and is a continuous process. Bring them in when you feel they will have input or have told you they have input.