Have Questions About This Guide?
Book a 30-minute call with one of our experts. You’re in safe, experienced hands.
Quite a few different types of projects will attract cyber risk, or what is sometimes called ‘cyber debt’.
For example, any project that handles a lot of data faces the risk of potential exposure if that data were to get lost whilst the project is being developed or as it starts to mature.
First things first, no matter what the project is one of the most important things to realise is that we need to bake security into it from the outset.
It becomes very expensive to start bolting security on at a later stage which is why it’s really important in the early stages to consider cyber security as one of the key project risks and prioritise it accordingly.
Other risks include:
Regulatory impact
Organisations need to think about any regulatory implications that may arise out of this project.
For example, if the project involves processing lots of sensitive personal data, healthcare or financial information say, there may be regulatory responsibilities regarding the availability of the IT systems.
Integrity
Something else that people don’t always think about is the integrity side of security.
In other words, if a project is going to be relying on information that is accurate, then certain controls and measures need to be put in place to make sure that data remains intact and does not get modified or changed deliberately by others.
Safety
As companies increasingly rely on digital products and solutions – there’s an element of safety that comes up too.
For example, if you’re embarking on a project that might eventually be relied upon by hospitals or transport and could impact the safety of individuals, you must consider how cyber-risk might affect that.
Usability vs. Security
Another thing that raises security questions is the trade-off between usability and security.
Those people developing apps and websites often want a seamless user experience, but they will need to make decisions between ease of use vs. security.
Third parties and supply chains
We also need to take in to account the supply chain and any third parties that the project might interact with.
How are considerations made for who those parties might be and how dependent the project is going to be on them?
Lots of us when we go into projects are reliant on other people to collaborate with us to achieve our ultimate outcomes, often sharing a lot of information or using software without really thinking that that’s a third-party supplier and could be a cyber vulnerability.
Those parties, such as the software or the hosting platforms etc. all have an impact.
Therefore, the key thing at the beginning of the project is to look through where your dependencies are going to lie, which parties we’re going to work with?
What data we’re going to share?
What level of access is being provided and for how long?
Are we going to use passwords or a stronger form of authentication?
These are all really important things that do come up.
So, thinking about all of these things from the outset and prioritising which of these you need to consider is important.
Security needs will continue to change throughout the different stages of the project, from the initial stages of design and development through to production and operation.
Companies must recognise the different levels of security compliance and implementation needed in each stage as they move closer to the operational end of the project, because security requirements grow and change as the project goes on.
Where they have thought about security, some companies will budget for security within the project lifecycle but fail to take into account just how they’ll hand that over into the operational environment.
In other words, the people, processes and governance don’t necessarily get factored into the project, and ultimately, this means things get more expensive.
Remnants of these ‘bad practices’ that may have been put in place during the development of the project can remain long after a project has been handed over into the live environment.
Sometimes, it’s those remnants that cause the big data breaches that we then see in the newspapers.
Finally, one thing people should start to consider is the concept of threat modelling.
This is the idea that before you even start a project you take some time to think about what security threats could impact it and consider those things strategically to help you get ahead on cyber security before embarking on the journey.
Data risks
Returning to the topic of data, there are quite a few associated risks such as data leakage, confidentiality of the data being taken or stolen, and the integrity of the data being modified or changed.
You may also need to get hold of a lot of data at the beginning of a project, find a source for that and input it into the system and the environment before you can start to use it.
So how that data comes to be used by the project, i.e., do you have the right permission to use the data that that you have obtained? – is a really important point, especially because of data privacy regulations like the GDPR.
Volume of data
Volume of the data is quite important as well.
Are we talking about megabytes / gigabytes of data that’s going to be processed?
And again, the sensitivity of that data is important.
All these things help us to gauge the level of security controls that need to be put in place as the project evolves.
Access
And staying with data concerns for a moment, you must also consider how to manage who has access to that data.
How do you set up an environment where people can securely and appropriately access the information that resides within the project and make sure that only the right people have access to their data?
If you don’t put in all the right controls at the beginning of a project, you may have a situation where lots of people in the business or lots of people that have access to the project sites are able to make use of that data inappropriately.
All of these access controls, passwords and defective authentications etc. become quite important and we need to think about the lifecycle of these users.
Who do we need to have on board so they can get the access and who we can off-board?
For example, when collaborating with any third parties, you may need to let them in to do their thing, but once they’re done, you’ll want to be able to lock them out.
Software development cycle
The security of the software development life cycle is extremely important.
If you’re starting a digital or technology project, there’s going to be some software development component involved.
That means there’s going to be source code that’s written or modules that have been purchased through a third party.
As people develop projects and code, they need to ensure that there’s a certain level of security and security mindsets applied.
There’s a great movement – the DevSec / DevSecOps – around how to effectively ensure that a lot of security controls get put in place within the software development life cycle and not outside of it.
Doing it this way ensures that security holes and vulnerabilities get weeded out as software gets developed before it goes live.
Operational risks
As projects evolve from the development stage into the operational stage there’s quite a few considerations to be made.
Sometimes balls can be dropped if the project development team and the operational project operational management teams are not in sync.
One higher level risk is when companies don’t put a plan together for how to address security at the beginning of the project. In our other cyber guides, we’ve discussed carrying out that risk assessment on the kind of things that might impact an organisation at a corporate level, the same thing should be done at the project level too.
There are tools out there to assess project risk that require you to answer some very high-level questions such as what kind of data is being processed?
Is there a regulatory requirement?
Is there sensitive data being processed in this project, such as credit card data, personal data, health care data etc.?
Is there a regulatory component to this data?
Are we using third parties?
It’s like a checklist that addresses each of these different elements, and, as each one gets ticked then the risk levels go up.
Testing
Security testing is often used in the same way you would use a checklist at the end of the project to see if certain things have been done.
We would argue that carrying out security testing throughout the life cycle of the project is really important too, and that testing should often be done by an independent party that’s not involved in the project.
You’ll often have different layers of testing, doing some of your own testing internally, before passing it to the independents to do their tests of their own.
But the worst thing a company can do is leave their testing until the very end of the project.
In doing so, they’ll undoubtedly find security holes and other gaps which need to be fixed.
Not a great outcome if you’ve only got a short time to go before you go live.
So, anticipating and putting in place a number of test cycles throughout the product development is really important.
One of the key things we can do is to learn the lessons from the past.
Where other organisations have experienced security risks, we should be able to pick these up and replay them within our own environment.
There are some common types of security risks and exposures that people experience such as hacking attacks, phishing, data leakage etc. and these are things that we could look for in our projects.
Monitoring
Constant monitoring is also really important.
Often trying to solve and clear every security vulnerability or risk is going to be an impossible task and one of the ways that we can do to manage this is to look for behavioural patterns.
What’s considered normal activity and what’s abnormal?
Where we see abnormal activity, that could be a red flag that is identifying a risk.
Training
Throughout our other cyber-security guides, we’ve stressed the importance of providing appropriate training for staff.
Staff and the users of the applications and systems can also help by reporting any unusual activity and spot the risks very quickly.
Risk assessments
Experienced project managers will be carrying out various types of risk management throughout the project.
They’ll be thinking about financial risk management, project risk management, delays and dependencies etc. and security fits into that risk management lifecycle too.
From the beginning of the project, if there’s any major changes to the scope or any new third party, piece of infrastructure or module or piece of functionality, these are all triggers and should raise concerns of extra risk being introduced.
Having a regime that does regular risk assessments can be a really good tool for helping to pick up these risks, put them on a risk register, prioritize them and knock them off as the project develops.
Culture
It’s also good to establish a culture where people feel they can open up and talk about any particular doubts or any concerns.
Often, it’s the human firewall which is going to pick up any suspicious activity, and even if they’re wrong, it’s better that people feel comfortable raising these things and doing those extra checks than having to suffer the consequences of a dramatic attack or breach.
So, encourage employees to be part of the security regime.
If people receive a phishing email or a visitor comes to the office to install a piece of equipment and something doesn’t feel right and they flag it, that can really help make it harder for the attackers.
There’s also another point to raise here about people not stepping outside of that security regime.
For example, by choosing some free online tool to transfer large amounts of data hasn’t been reviewed by somebody on the project team for security risk.
It may be quick and efficient from an operational point of view but actually using free versions of tools these without thinking about how secure they might be is certainly an area of vulnerability in many businesses.
IT & Security – The department of “how?” not the department of “no!”
One of the things that’s really important for IT and security as a whole is to make it easier for people to do business.
If they’re successful, then staff don’t have to go out and use software that they’ve found themselves.
Being able to anticipate some of that business demand and providing solutions that enable the business is extremely important.
But it can be a tough balance for some companies.
Nowadays, it’s so easy to buy software online or download something for free and you can have a situation where IT and security are perceived as being blockers.
People would rather act now than wait for a solution to go through IT and security before being put in to action.
But, if these departments can anticipate that demand, are accessible and can offer assistance when it comes to checking particular types of software – known as ‘Sheep dipping’ in cyber-security circles – they can give users a chance to install that software in a safe environment before it then gets exposed.
This is something that’s especially specific to development environments where we want to encourage innovation and look at the different tools and technology out there as it’s how we grow and develop quickly.
Separation
The concept of separation and segmentation is something else we’ve spoken about in our other cyber guides, and it applies very much to the project environment as well.
Does the project environment have to be linked to the corporate environment and do we have to give people working on the project access to everything in the whole business?
Or can we help reduce the potential for damage by just giving people access to the things that are going to make them successful in running and implementing those projects.
In some large organisations where there’s frequent collaboration, even between competing firms there’s an additional dynamic where you want to leverage the skills of a collective group but need to balance that against the potential impacts that bringing together these (sometimes) competing groups might have.
This is something that has to be done regularly, depending on the length of the project.
But there are some key triggers such as whenever there’s a key change to the project.
Doing a review at these points – and assessing whether that change is impacting security – is really important.
Setting a regime for the level and regularity of testing can be done at the beginning of the project, depending on how important this project is and how big the cyber risk exposure is.
In the same way that you would generally perform a number of different iterations of quality review on the product itself, so we expect the same thing to happen in the security world, throughout the project life cycle.
We make lots of assumptions going into projects about the way things are going to be.
Reviewing and testing the robustness of security often catches out any assumptions that may not turn out to be true in reality.
Sometimes that could be an assumption that we’ve removed all users that no longer need access to the system or that default passwords have changed once a new product has been installed, but in reality, we often find that those things are not actually in place.
Independent testing
When testing robustness of cyber security, it’s also important to have an independent perspective on things.
That way, not only do you tend to find that you might get a lot more value out of the process, but it also helps establish a set of criteria into the project lifecycle, against which you can implement and test the robustness of your security.
Levels of testing
When talking about robustness, there are also different levels of testing.
You may be looking at the availability and resilience of the environment to cyber-attacks or it could be something more specific such as whether changing certain conditions in the environment affects security controls.
In other words, are there enough levels of security to catch failures that might happen in different layers?
For example, if the passwords control fails, are there additional controls like data encryption to protects the data and secures it?
If access has been breached in one layer, another layer of protection might be required to be breached before the data gets exposed.
Is it safe to work with third parties on business projects?
A number of us – particularly in the small business community – are novices at all of this.
So, spotting risks, reviewing them and how to apply the right measures and tools requires additional expertise.
Many of us will rely on third parties to do some or all this work for us, so what’s really important here is effective communication of your security requirements.
To do this, you need to have a good understanding of what it is that you want.
Know what kind of protection you want for your business and for the project and be able to properly communicate that to any third parties that you’re going to be using.
For example, if you want to host a website on a platform, they will give you three or four different price points for different types of hosting services.
At one end, offering a very general service that everybody can use, all the way through to a dedicated, fireproofed and very secure website just for your company at the other.
But at the end of the day, deciding which option to go for needs to come from you.
To some degree though, it’s only you, or the company itself that can make the decision about what level of security to apply.
So, it’s up to us to understand our own exposure, and while sometimes that might be very complex or difficult to dial into, it’s really key.
Fundamentally, it boils down to what it is that we’re most concerned about and what could go wrong with our projects or our business that really bothers us.
And, if we can tease that information out at a higher level, we can work with our experts and third parties to understand and explain the different ways that these risks could potentially manifest themselves.
But it needs to come from us, it needs to be well communicated and well-constructed.
Once that’s in play, you could ask another third party to check whether your requirements – which hopefully have been documented – have actually been implemented by the initial third party.
If we look at the data privacy world from a couple of years ago, we didn’t really have full measures in play to hold people more accountable.
One of the things that the GDPR has done is give us very clear standard contract guidelines for data processers and data controllers on whose responsibility it is and what their responsibilities are.
Away from data privacy, the security end of the scale is still a work in progress.
Ultimately, all we can rely on are these independent security standards such as the ISO 27001 Standard.
For companies that are in this business and are responsible for providing secure solutions, these standards are a method for them to be able to demonstrate that they are at a certain level of security maturity.
They are the industry stamp marks to demonstrate the credentials, standards and accreditations that small and large businesses will need to rely on and point to for their cyber-security.
These standards give an indication of how seriously companies are taking cyber security and compliance.
However, as vulnerabilities, threats and technology are constantly changing, providing 100% security and assurance is something that’s almost impossible and this is likely to be the case for many years to come.
Bake security in from the beginning:
Don’t leave it until the end of the project to add it in because by then, it’s going to be too late.
Carry out your risk assessments:
Understand the key risks that your project could be exposed to.
Prioritise and work out whether they’re critical, high, medium or low risk and use that to dictate the level of security investment and activity that you put into addressing them.
You’re going to identify a lot of risks, so you need to prioritize the ones that are potentially more likely to happen or that you’re most concerned about.
Testing
Test and ensure that there are appropriate levels of security testing.
Establish a set of security actions and controls that you’re going to be putting in play and then test whether those controls are effective or not throughout the project.
It’s also really important to understand that throughout the life cycle of a project your security requirements are going to change.
You may have to apply different levels of security to each phase of the project, from its early design when you’re thinking about an idea, all the way through to the implementation and ultimately the operation of the project that you are delivering.
Book a 30-minute call with one of our experts. You’re in safe, experienced hands.