Here’s a common way of looking at security. Take a scale of two axes, X is people considering cybersecurity and Y is application security quality. It seems obvious that good people using secure apps will deliver data security to an organisation. It’s not obvious however that real security does not work this way. There are more axes to consider; application age, operating systems and staff.
A visualisation to make the point is a virtual wall around your data, with a big door to the Internet. Each member of staff is a brick. You can have 4999 solid bricks, but the problem is the loose brick that fails. It’s also likely that your organisation does not control all parts of the wall. It has outsourced parts, either to the cloud or third-party providers.
Let’s discuss the value of the cloud and outsourcing, not regarding cost, but security. Many outsource email systems. In security terms email systems are difficult to secure as they form the front line of Phishing and Malware defence. Attackers are agile, and attack mechanisms are complex. System Administrators (SysAdmins) haven’t got the resources to stay on top of email, web, infrastructure, database and application security. Therefore, businesses rely on experts to deliver a secure service.
If we outsource our CRM (Customer Relationship Management) system do we want best of breed or should we go with the email provider because these two systems will be tightly integrated. Hold that conundrum in mind as we take another track, through people and departments.
The inflexion point, where it becomes hard to get things done, is because stakeholders are often in different departments and come with different agendas.
The marketing department wants a specific application. The incoming marketing director has had success in the past with a particular solution. It works with the website CMS (content management system) and the email system.
Because you’ve been outsourcing stuff, you don’t have any development staff. A web search finds you an agency that recommends your email system and CRM combination to other organisations - great.
You have a route forward.
However, you’re about to be undermined for the right reasons
Your project has a four-month timescale. That’s what it takes to get that set of stars aligned. It would be way longer if you had a poor provider in the chain.
Switching to the people side. The marketing director is new, under pressure and with a sales team hungry for leads. They try sending web data through email – it’s too big and it triggers a content policy.
A member of the team suggests they wrap up the web site data and use an Internet drop box to get it to another colleague who can massage the data for the email system (a perfect shadow IT example). It gets the project underway and it’ll be fixed in four months. When security gets in the way of business people look for a work-around.
Driven by the internal customer.
From the perspective of the SysAdmins and DevOps team the best solution would be to have a SQL connection from a data aggregator to a data source. The data source is a VOIP PBX (phone system). They call the security architect who rightly says that the PBX system is attacked several times per second and there is no way SQL will be allowed from the corporate network to the phone system.
The DevOps are driven by their internal customer -the marketing director. There’s a SSH and HTTPS route to the PBX, and DevOps have the credentials to both ends of the project. They create a script that runs on the PBX that uses SSH and HTTPS to extract and surface data. These DevOps see the risk of embedding credentials in code so create a trust relationship over SSH, no passwords in scripts, and the code has a hard-coded address for the HTTPS transfers.
So, returning to brick walls even with well-intentioned staff we have risks:
- Business data at rest on an Internet drop box site. The Security Architect does not know this.
- Trust relationships between a system known to be under attack with internal and cloud systems.
- The Security Architect may be trusting the firewall rules by overlooking the fact that other protocols and data are being encapsulated in SSH and HTTPS.
- You’re one password away from disaster.
Within organisations, incentivised people trust 4-9 people, reasonable people trust 13-20 people - and can keep track of about 150 people.
In non-criminal organisations below 250 people, latent criminal activity is unlikely to cause damage. Above 250 people and problems are virtually inevitable. Who knows about that data at rest and who finds the trust relationships in those systems?
To visualise this further, we should think of a hard shell with pipes extending to the Internet. Within the shell there is a membrane of data cells that are easy to break through. If security, or people, fail the data is carried through the doors to the Internet.
Find a better way of doing things
Whilst we are layering on concepts, I’ll add a few more:
- As time goes by applications become weaker security wise. Active applications get more features, Apps no longer underdevelopment have vulnerabilities
- If the consequence of a security barrier is too high, the bar will be lowered. Systems and equipment in operating theatres do not use authentication.
- There is an exponential relationship between pressure and disregard for cybersecurity. In the height of a shift in an A&E department cybersecurity is not even in the periphery of clinical staff thinking.
And there’s the cloud; the security there is rolling on. Patches are happening, but the cloud is run by staff, and they are fallible.
The better way
We can’t change the shell, that’s the world around us. But we can change the internal relationships. On the people front this can be achieved by using identity as part of authentication and introducing a proper program of Privileged Access Management.
On the technology side it means associating trust and roles to identity. Tools and applications can have a lot more accountability.
If you’ve got this far, and not forgotten about that data was left in the cloud, if it were encrypted against an organisational identity the friction to decode the raw data would be very high.
Andy Harris, CTO at Osirium
Image Credit: Wright Studio / Shutterstock