SharePoint's old security model was conceived in a different era. Let's imagine what a new security model might look like.
In my last post, we looked at the humble beginnings of SharePoint as Microsoft Tahoe, and pointed out that the security model really hasn't changed in the 15 years since then. Even today in SharePoint 2013 and Office 365, the basic approach to managing permissions is more or less the same:
We manually compile lists of people, then grant them permissions to stuff.
OK, so SharePoint's old model was conceived in a different era, under vastly different circumstances and hasn't much evolved. Let's try and imagine what a 'typical' organization's requirements for a brand new security model might be.
We'll stick to use cases around information management and collaboration, and avoid any specific technology. We're thinking about the enormous volumes of documents, spreadsheets and presentations, in various states of polish and approval, of various levels of sensitivity and importance, and stored in file shares and online systems.
If there is one thing that stands out about organizations in general, it is how much and how often things change. Strategies, priorities, structures, products, services, markets, people and positions. Roles, teams, departments, functions and systems appearing and disappearing. Political change. Environmental change. Economic change.
Change is so prevalent, it is possibly the only real constant!
So, our new security model has got to be designed for this. Flexibility to accommodate change, to adapt and respond swiftly when it happens - and keep information secure at all times - has got to be where we start.
Fundamentally, information security is about connecting people with the information they need, and keeping them from the information they shouldn't have.
Permission configurations (and their deliberate absence) are the mechanism we use to connect (and separate) people and business information. Permission configurations grant or deny access for people to information. X person has Y access to Z file.
We're dealing with huge volumes of files, and many, many people. So, a typical organization may have thousands or even millions of individual permission configurations.
A business decision lies behind every single one of those configurations. Each configuration needs to be an accurate reflection of the business requirements. Accurately ensuring that the right people only have access to only the right information is how we minimise the risk of accidental or malicious internal security breaches.
But the ground under those business decisions doesn't stand still. We've already noted the prevalence of business change. A person may require access to a document today, but should not have it tomorrow. It requires constant review and maintenance in response to change.
'Hackers' may make the headlines, but this is how the majority of security breaches actually arise: Permission configurations inaccurately reflecting business requirements which constantly change.
The scale and complexity of the challenge is immense. But hey, nobody said it should be easy!
People are busy. They have jobs to do, targets to hit, deadlines to meet. They create and use information to do what they do. When it comes to information security, and they need it to happen reliably and in the background.
So, if the tools and processes around keeping information secure aren't simple, out of people's way quickly, and largely automatic - people will find another way to get things done.
For people to trust the systems we give them for securing their information, they need to inspire confidence. If a business user grants access to their information to a certain set of people, they need to trust that those are the people who will get that access.
There can't be any hidden back doors, or extra people they don't know about. The system has got to do what it says on the tin - no ifs, no buts, no complications.
Otherwise, users will either avoid the system because they don't trust it. Or they will use it anyway, hope for the best, then a security breach happens, the business is damaged, trust is destroyed, and those users avoid the system next time anyway.
(...ever wondered why such a common complaint about SharePoint relates to poor rates of adoption…?)
So maybe these are four fundamental requirements we can start from:
1) Accomodating constant change,
3) Quick and Simple, and
4) Robust and Reliable.
In my next post, we'll use these basic four requirements as a lens to look at a real-world business scenario, and see how SharePoint Security stacks up.
Thanks for reading,
CEO and Principal Architect at Torsion Information Security