Consider this a cheat sheet of cyber security (and other) things to consider when managing a project.
Herding cats can be a full-time job
If we consider some of the important dimensions (and common success factors) of a project such as Scope, Sponsorship, Leadership, Capacity, Capability and Competence, Processes, Technology, Tasks, Timelines, Budgets, Deliverables, Scheduling & Sequencing, Dependencies, Constraints, Risks, Compliance obligations and Communication, typically these are established (and vigorously defended) by a savvy project manager.
As projects often have many internal & external dependencies, one challenge for modern technology projects (or business projects that leverage, depend on, or impact technology) is to maintain visibility and awareness of things that can influence these dimensions (i.e. risks).
The young project manager watches his dependencies
I recall a conversation with a veteran project / program sponsor many years ago, who (initially averse to the language of risk) came to understand that most of her career had involved risk management of one form or another.
The mythical project checklist which details everything
So how can a project manager integrate cybersecurity risk management into their projects?
Here are a few tips which project managers have found helpful:
Request / obtain all relevant risks, audit items, requirements (policies, standards, procedures & compliance obligations)
Request / obtain all relevant business, technology, risk management strategies
Consider the items above as inbound requirements to a project, capture, confirm and manage these as with any other requirement.
Consider the delivery and execution risk(s) associated with what the project intends to do (i.e. activities)
Consider the risk(s) that are being addressed (controlled or improved) by the project (i.e. usually a project will help to reduce risk, having these documented provides a balanced benefit view and helps to keep stakeholders focused) - e.g. if the project is to introduce new ways of working and there are technology changes included (e.g. changing desktop operating systems) - invariably, these will bring reduced risks and improved security, as more modern, supportable platforms can reduce risk.
As projects can sometimes be the first time (in recent history within an organisation) that anyone has considered a pre-existing risk - take care to call out any pre-existing risks to ensure that stakeholders know this, and then ask the question, "What is changing, and how does this affect the pre-existing risk". In some cases the change may be a project initiated activity, but it could equally be the degradation of an existing control that is no longer effective or an increase in the consequence or likelihood of a threat.
Based on knowledge of the items above, resolution, escalation and approval paths will typically be clearer. Without this information it is often hard to know whether you are dealing with a well-known, pre-existing and accepted risk (that is usually owned by someone operationally) or something new or novel (and could be owned by the project or its sponsor).
What does a project security engagement model look like? Here are a few:
Cybersecurity is known to be associated with flouro blue
Dedicated resourcing - Specialist (architecture and design resources) security resourcing is established early in the project. This works reasonably well for large, complex and well funded projects. The downsides can be that skills may need to be generic (Jack of all Security Trades), and that this has a cost implication. The upsides are that (where properly integrated) this should avoid surprises and can provide a more streamlined simple model.
Key considerations: To be effective, security should always be driven from Risk, Compliance or Utility so managing security resources should always bring discussion back to what is being addressed and why?
Note also: General security practitioners may face a steep learning curve with new technology it is therefore important to allocate adequate time to research this or obtain external skills where required.
Periodic checkpoints - Specialist (assurance and consulting resources) are engaged at logical milestones in the project to provide input to and feedback on project activities and artefacts. This works reasonably well for maintenance and platform projects where there is a lot of documentation produced. It allows for greater precision in allocating security skills and allows for overall process efficiency to be considered.
Key Considerations: As engagement is centred on artefacts, the quality and completeness of these is important. In addition, the security practitioner may need to consult with resources that are now busy on other activities.
Risk of rework: as the project can progress too far down a particular path it may involve re-work. Also, project deadlines and limited notice can place additional pressure on external resources (e.g. compressing their timelines). The upside is that the engagement is highly targeted, and where there is a risk of slippage or other dependencies, it can be easier to integrate security and other feedback (e.g. architecture)
Moderation: Specialist security practitioners can have deeply held (almost religious) views on certain things, and these may need to be moderated and managed with a broader audience where required.
Anxiety Management: Using an early 'heads up' informal security briefing throughout the project can help keep the two camps aligned and reduce surprises in both directions.
Deliverable assessment and feedback - Formal project gates with requirements management and structured assessment and feedback can work very well where this is understood and part of the furniture. This works well in mature environments that would better wear a cost or time over-run than a security / compliance breach.
Key considerations: As with the previous approach, this is very focused on tangible artefacts, requires a very well defined governance structure and formalised accountabilities. Risk and Compliance must also be mature, well understood and agreed by the participants to avoid a 'build your own governance approach' during an inflight project.
Approval by committee: The drawbacks to this type of engagement are that documents and artefacts can go through multiple approval rounds and can (if not properly managed) miss / exclude / over-emphasise requirements or lead to a decision impasse that needs to be escalated. (matrix management). The upside of such environments are that there is usually less conflict as stockholdings and governance are better managed through the bureaucratic processes.
Governance: This approach can involve the escalation to risk and control owners, and as such is better suited to environments which have an effective GRC structure.
Efficiency, cost containment and execution
The last thing a project wants and needs is an expensive security person sitting & waiting.
The project manager paying contract resources
So how can we tackle this:
1) Understand the project lifecycle, milestones, and logical engagement points for security e.g. if you do not understand your threats, risks, controls, obligations and governance required get some focused upfront (security scoping) assistance to determine what is needed.
2) Leverage well-known (defensible) sources of guidance i.e. Internal Policies and Standards can help to quickly solidify organisational security expectations.
3) Conduct periodic, logical check-ins with security stakeholders based on project phases / milestones. We would usually suggest things such as the following:
Concept & initiation - identify any big ticket considerations / mega risks / mega costs as well as help to identify likely issues and incidents and pre-empt a response. If a project introduces more risk than benefit - here is the time to know.
Definition and planning - define any critical goals / activities that relate to security or risk management. Good security advice upfront will reduce cost, delays and re-work. Here also, a good security person will be proactive and make recommendations on what to do if things go wrong (e.g. having a data breach playbook to support a large and complex data migration).
Launch or execution - upfront planning for security and risk will take the guesswork out of what your security personnel will be doing, development, delivery, verification etc throughout execution.
Performance and control - just as with many other disciplines, data and timely information are vital. Key risk and key control indicators can provide early warning of an impending problem. Integrating security as an aspect of quality, and conducting testing to confirm resilience is a practical example and provides confidence.
Project close - More than just an opportunity for team lunch / drinks, it is important to circle back and confirm our closing risk position and outcomes. This usually involves discussion around the acceptance of some risks or new control custodianship.
The secret mountain lair of the reclusive security managers who were hunted to near extinction by early project managers
Common Gotchas: Here are a few security things that can sometimes get missed in a project:
Understanding information repositories and flows. This can help to identify weaknesses in processes or protection. e.g. "We simply extract the data onto a thumb drive and send it by post to our developer."
Having a plan for managing a security incident during a project. (This could be as simple as shut the system down, or involve a full step-by-step plan in cases where the system and its data are integrated across other platforms and possibly 3rd parties, e.g. using a 3rd party credit check API hosted by a partner).
Documenting the threats that will (and won't) be addressed in the project. (e.g. DDoS is usually an exclusion).
Consideration of what the changes will mean on existing security controls (e.g. implementing encrypted traffic will remove the ability to inspect it for malicious content).
Integration of the changes into security operations (and any training / uplift etc that may be required [see previous comment re: playbooks])
Integrating security testing (when, where and how) so that security defects can be considered in existing changes / releases / drops or remediation.
Capturing any specific security and risk objectives of the sponsor. (e.g. "The integrity of the website content must be protected at all times")
Consideration of any uplift in cost and effort for security management / licensing / storage etc. (e.g. uplifting this platform will produce another 500Gb of logs per day that need to be stored, processed and analysed)
Risk integration (management, assessment of changes, risk acceptance) & risk governance processes.
Security documentation (new or amended) such as a platform security standard or network security map.
Final thoughts: Project management is complex. If you have made it to the end of this article, I hope this has provided just a few tips to help better manage security in your projects.
If you would like to discuss how we can assist you to manage security and risk in your projects get in touch.
Author: Clinton Smith