Evaluating SharePoint's Security Model

Evaluating how well SharePoint's security model performs against a real-world business scenario.

In my last post, we established 4 core requirements for a new hypothetical security model for SharePoint. They were:

1) Accommodate business change,
2) Accurate,
3) Quick and Simple, and
4) Robust and Reliable

Let's now use these requirements as a lens to examine how SharePoint's current security model stands up to a real-world business scenario.

The Scenario

A highly confidential idea for a new product is to be developed and brought to market.

A SharePoint site was used by the 7 engineers involved so far. The documents and diagrams they shared in the site helped validate the idea. The CEO, CFO and their assistants were given access also.

Once the project got the green light, the team scaled up quickly. Three project streams were established, with a common program across them:

- Product Development stream (31 people): designers, engineers, marketers
- Customer stream (19 people): commercial and sales development
- Legal / Financial stream (8 people): patents, revenue projections, project funding

To minimize confidentiality risk, it is imperative that people only have access to precisely the information they need, and no more.

The plan was to isolate each stream, to keep information circles small. The original SharePoint site was designated for use by the program, and a sub-site (non-inherited permissions) created for each of the three streams.

Over the 9 months since, boundaries blurred a little. Legal weighed in on product decisions. Product Development needed commercial visibility. Outsiders needed to contribute or review certain details. 

The project team grew and shrank over time. The Product Development stream is dividing in two. Everyone is under time pressure. The project has at least a year to go.

How Will SharePoint's Security Model Hold Up?

Accommodating Constant Change

The project has already seen a lot of change: people joining and leaving the team, temporary access across stream boundaries, temporary access outside the project, a stream dividing in two.

Administrators would have had to carry out hundreds of manual permissions changes over the course of the project so far. Everywhere permissions inheritance was broken (such as every time Legal accessed a Product Development document), the number of changes increases.

All these changes are in no way automatic.

Accurate

To update every necessary permissions configuration every time something in the business changes, administrators must be aware of every single change. Even though they may work somewhat at arms-length from the rest of the business.

A single business change, such as someone transferring from marketing to sales, could give rise to dozens of permissions changes. Administrators must somehow work them all out.

The chances of a mistake being made, or something being missed - are high.

Quick and Simple

Every time something in the business changes, one or more people may need to be granted or revoked access to several collections of information. Many permissions changes will likely result from every business change. Identifying each change may not be immediately obvious. This is neither quick, nor simple.

SharePoint can allow business users to grant permissions for sites or documents themselves. But what about revoking access when it is no longer appropriate? Usually busy, business users will often forget.

Robust and Reliable

A business user needs to share a new sensitive document with their project stream. To what extent can they honestly trust that only the correct people will have access? How likely is it that site permissions aren’t aligned with the business circumstances? How can they know who will have access to the document once it is uploaded, and how can they evaluate the accuracy of that?

If people don't trust system security, they may choose to share information some other way.

The Bottom Line

So how did SharePoint's security model hold up? Probably not so well. Keeping permissions accurate for thousands of documents and dozens of users, in the face of constant business change - is a large and complex task which is highly vulnerable to error.

All it takes is one mistake, one change overlooked, one accidental inaccuracy. One administrator away on leave. One information owner frustrated under time pressure. It doesn't take much for inaccurate security to materialize into a serious breach.

I'll sign off with this fact: in a recent survey, 71% of business users thought they had access to more information than they probably should. This is not a small problem!

 

 

In my next post, I'll share some thoughts on designing Security-Centric Governance Plans for SharePoint. Trying to balance the needs of users, administrators and the business - while maximizing the security of our information.

Thanks for reading!

Peter

by Peter Bradley via Everyone's Blog Posts - SharePoint Community

Reimagining a New Security Model for SharePoint

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.

Constant Business Change

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.

Accuracy

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!

...oh, wait...

Quick and Simple

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.

 

Robust and Reliable

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,

2) Accuracy,

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,

Peter

by Peter Bradley via Everyone's Blog Posts - SharePoint Community

Microsoft Tahoe and the Evolution of SharePoint Security

In my first post, I explained the biggest problems of SharePoint security model and how it creates risks. With so much change, so much growth, so many new threats - perhaps SharePoint's security model could use a rethink?

Microsoft Tahoe - Where it all began

Back in 2000, an internal project at Microsoft called 'Tahoe' began publicising a new product they had been working on. Tahoe was a new technology that enabled small work teams to perform simple document sharing, collaboration and content searching through a web browser.

By the time it was released, the marketing department had come up with the name 'SharePoint Portal Server'. The market didn't receive the new product particularly positively!

Debra Logan, a research analyst at Gartner said, "SharePoint Portal is just document management based around one Exchange server. It is better than a shared file system, but big deal."

Ashim Pal, programme director for analyst Meta Group, said, "It is lightweight document management for the masses. There will be a mass migration to… [another technology] in the next 24-36 months, so users should be careful not to over commit to any development around SharePoint."

Computing Magazine UK actually used phrases like "too lightweight", "too basic" and "will soon be redundant"!

A typical SharePoint Portal 2001 home page

Looking at the information management powerhouse that SharePoint / Office 365 has become today, and as one of many people who have built a good career on top of it - its hard to resist a wry little smile ;) I don't know many people who would today describe SharePoint as "too basic"!

SharePoint Portal Server 2001 Security

The examples in Microsoft's documentation for SharePoint Workspaces reveals the thinking at the time. This was not a technology designed for serious deployments. They really didn't envisage more than a dozen or so people using them! It didn't use a proper database, it didn't support clustered server farms.

It was really just a small scale, browser-based extension for Windows Server and Exchange that let people share and search across a few documents.

With SharePoint Portal Server 2001, users could be granted one of three 'roles' to content in SharePoint Workspaces:

• 'Coordinator' was for administrators and information owners
• 'Author' allowed the user to add and update documents
• 'Reader' allowed read-only access through navigation or search

Permissions to content were granted either to groups of people in Windows or Exchange, or to individual users. It was very manual and unsophisticated, but it worked.

Permissions in SharePoint Today

Fast forward to today with SharePoint 2013 and SharePoint Online / Office 365. First lets substitute a few equivalent terms:

Something obvious jumps straight out. The model hasn't changed!! In 15 years, there has been no evolution the security model at all - the concepts and basic ideas line up exactly.

Security in SharePoint is still managed in the same basic way as it was on day one: we manually compile lists of people, and grant them permissions to stuff.

• Even though SharePoint systems have gone from dozens of users to hundreds of thousands.

• The volumes of data have gone from a few folders to terabytes of mission-critical sensitive content.

• The intensity, relentlessness and consequences of the security threat have gone from fairly minimal to extreme.

• The role of SharePoint has gone from being "not much better than a file share", to being central to the operations of millions of organisations around the world.

• And the internet and the interconnectedness of networks became absolutely ubiquitous.

Some of the most notorious information security breaches in recent years have involved information stolen from SharePoint systems. Not hacked by clever anarchists in dark rooms, but simply downloaded by disenfranchised trusted staff with access to far more information than they needed in order to do their jobs.

But still, SharePoint offers the exact same ideas for securing content as it always has!

So, in light of all this change, all this growth, all these new threats - perhaps, the security model in SharePoint could use a bit of a rethink.

We've outgrown it.

In my next post, I'll dive deeper into how SharePoint's security model tends to cause huge problems for organizations, and some of the practical things we can do to minimize them.

Thanks for reading :)

Peter

by Peter Bradley via Everyone's Blog Posts - SharePoint Community

The Biggest Problems With Microsoft's SharePoint Security Model

Dear all,

I wanted to share with you my thoughts on SharePoint security model, and why it's clearly outdated for today's corporate environment.




SharePoint's groups-based security model

SharePoint security is based on groups. Whether you favor SharePoint groups or Domain groups, either way the groups model is based on hundreds of long lists of people’s names.

Groups must be manually populated with the people who should get access to information - a tedious task which is highly prone to human error.

SharePoint makes it simple to add new users who transition into relevant roles and assignments, but there is no clean-up of permissions when they transition back out.

And besides, organizations aren’t typically structured around groups – they are structured around people having roles, credentials and assignments. People move around and shift focus all the time.

SharePoint also provides very little support for an information owner trying to add the correct group to their SharePoint site. It is far too easy to make a mistake, and there is no help to detect if one has been made.

And so, without confidence in their actions to secure their information in SharePoint, the information owner will often feel it could be better to start yet another new group. And the wheel gets reinvented again!



The importance of maintenance

Modern organizations are dynamic places. People move around organizations regularly. Organizational structures change regularly. In fact, change may be the only real constant!

And so, because SharePoint security is based on lists of people's names, those lists must be constantly maintained. We need to ensure that the set of people getting access to information remains appropriate as business circumstances change.

But groups in SharePoint include no clear link to the original reason a person may be a member – so how are we to evaluate if it remains appropriate? Especially when the maintenance task falls to IT - who may be quite distant from the information involved, and who often don't have first-hand knowledge of the information or people involved. How can they possibly be expected to make good proactive decisions about who should keep their access?

Experience has shown that as many as 30% of SharePoint site owners have left their company or moved jobs. Over 50% of SharePoint sites are abandoned within 3 years, but sensitive documents remain accessible.

Permissions in SharePoint often get in a tangled mess - and people tend to accumulate access to information as they move around over time.

And the larger or more complex the organization, the more DIFFICULT, EXPENSIVE, and INACCURATE maintenance becomes.



'Silent' permissions

SharePoint includes several ways to gain access to information. Some of these are not visible to information owners.

For examine, information owners can’t see who are members of Domain groups. Also, Domain groups can be nested inside other groups, also without information owners knowledge.

Site Collection Administration rights, and Web Application Policies can effectively provide ‘silent’ access. That is, permissions for people to information without the knowledge of information owners. Although this function exists for the legitimate purpose of enabling administration of the system - the fact that information owners can't see this can create significant problems.

Ultimately, lack of visibility undermines trust.



The consequences of lack of visibility

SharePoint is designed to promote information sharing, but security information is not clearly visible.

Take a standard SharePoint document library. Exactly who can access it? Its not easy to tell. Users can’t easy know what permissions are on the SharePoint sites they are trusting their documents to.

SharePoint's ‘Shared With’ dialog is slow and unreliable. The ‘Manage Permissions’ page is buried inside settings.

Administrative permissions, such as Site Collection Administration rights, and Web Application Policies are hidden from users and information owners.

Membership of groups is hidden – we only see the group name, which may or may not be descriptive, helpful or consistent. And there is no way to view the membership of Domain groups

Without the trust of information owners, adoption and value is compromised.

And this can lead to an attitude of security being ‘someone else’s problem’ – rather than promoting a culture of shared responsibility!


Risk to the organization constantly grows



Since SharePoint began 15 years ago:

The volumes of information we deal with,
the general dynamism of organizations, and
the intensity of the security threat
...have increased exponentially! SharePoint’s groups-based security model has seen very little evolution over that time.

Ultimately, these factors create weaknesses in your information security armour - increasing risk to the organization of a serious security incident. You can read more here on solutions to tackle these challenges.







Let me know your thoughts :)

Peter

@TorsionIS
Let's #MakeTorsionGreatAgain together!
by Peter Bradley via Everyone's Blog Posts - SharePoint Community