The Connection Between Cybersecurity and Business Process Management – The Value of Formal Asset and Identify Management

The Connection Between Cybersecurity And Business Process Management PART 1.jpg

This episode of At The Edge is made possible by the generosity of our sponsor, Edgescan.

Part 1 of a 3-part series.

By Sean Martin, host of At The Edge

Sean Martin is joined by Ryan Duguid, Chief Evangelist at Nintex, for a conversation connecting cybersecurity with business process management.

In this 3-part series, Sean and Ryan discuss how regardless of the level of formality surrounding business processes, these operational elements are critical to define and determine how well a company can and will run. Most of the time, people think about business processes in terms of reducing waste and driving up efficiencies. Today, however, Ryan and Sean get to talk about some additional value points to help keep things from “going off the rails.”

So just what do cybersecurity and business process management have to do with each other? Read the Q&A below to find out.


Sean Martin: Welcome to our chat here on At the Edge on ITSPmagazine. Today I'm joined by Ryan Duguid, Chief Evangelist at Nintex.

Regardless of the level of formality surrounding business processes, they define and determine how well a company can and will run. Most of the time, people think about business processes in terms of reducing waste and driving up efficiencies. That certainly makes sense. However, Ryan and I will talk about some of the additional value points of formally defining and managing business workflows. We’re hoping to help you keep things from “going off the rails,” shall we say.

So what does business process management have to do with cybersecurity? That’s what we’re going to capture here. As with most things on ITSPmagazine, we like to look at information security, both from an information and a systems perspective, as well as a privacy perspective. We’ll look at these things through the lens of risk and cross through that lens of risk by looking at business processes, workflows, orchestration and automation.

We have a lot to cover so we'll get into that in a second. Very quickly though, Ryan, if you could just give a quick background of yourself.

Ryan Duguid: Sure! I was born and raised in Edinburgh, Scotland and spent 17 years of my life in New Zealand as well as 13 years in the U.S. between New York, San Francisco and Seattle. I’ve been with Nintex for six and a half years, and prior to that, Microsoft for seven years, working on SharePoint.


SM: So, it’s obvious to me … you know a bit about getting information to people and letting them run their business with it!

RD: Absolutely.


SM: It’s funny because I actually tweeted the other day — after you and I already had this podcast scheduled — when I asked folks on Twitter what they wanted me to focus on topic-wise. I had some ideas for who I would speak to for different topics, but one of the ideas that I put out there was “going off the rails.” When the polling was completed, the Twittersphere actually selected “going off the rails.” While I didn't anticipate you and I would be talking about “going off the rails” when I put that question out there, that is, in fact, what we're going to spend some time talking about.

So, the idea that I want to dig into is how companies really need to understand their cybersecurity risk and if they're going to mitigate that risk. They can't just start throwing security technologies onto systems and train their employees for security awareness and hope everything is going to be alright—not if they have no idea of what they're trying to protect themselves from, and what things they're trying to protect people from getting at.

A lot of that is based on how their business runs. If they can't understand what their business is doing, there's little chance they're going to have any success in mitigating any risk related to how that business is run.

What I'd like to do in order to start off is to get a sense from you what's involved in running a business, and then we can talk about it in the context of the lifecycle of things, assets, identities or entities, perhaps. Please lead us off with the lifecycle of “stuff” and what some of those “stuffs” are.

RD: As to what those stuffs are, at Nintex, “entity” is the word we use. It’s a bit of a geeky term, but essentially, we ask ourselves for any given business, what are the core entities that keep that business running? There’re easy ones to identify, such as those businesses have customers and employees. These are always good places to start.

For a lot of companies, these two areas tend to be the biggest source of income, and the biggest source of expenses. Once you go beyond that, you're starting to look at the facilities where you house all those people, the assets, and the equipment that they're using. You also look at the products that they're building or the services that they're delivering, and that gives you a good lens through which to view most businesses.


SM: Certainly, those entities don't just magically appear. Somebody has thought—either purposefully or accidentally—about bringing those things into the business. Clearly, to start a company, there's at least one person that joins as an entity, they then find more people that start to set up systems and so on.

Let’s talk about the lifecycle of employee onboarding. Again, they don't just magically show up. It's not a case of the offer letter being written to the candidate and then they show up on Monday as an employee. There's a lot that goes into the hiring and onboarding process, and once they're there, that's not the end of the story either. Tell us a bit about the lifecycle of an employee.

RD: Employees are the easiest way through which people understand the concept of an employee lifecycle because everybody appreciates that people come and go from companies. I've seen this from time-to-time in fast-growth companies such as Nintex; people do tend to pop up here, and I have no idea where they came from, but that's to be expected as companies scale.

However, when you look at how that comes about for most businesses, the reason you hire people is because you're growing or looking to drive growth, which means someone has to justify the cost of the head count and related overhead. Your starting position tends to be identifying a need for growth in the business and the employee skillsets required to drive or achieve that growth.

Having done that, you have to get approval for the budget, presumably from your financial controller. Once that's happened, you’ll be working with an HR team, potentially even outsourced recruitment firms as you create a job description, and related advertisements to attract the right type of candidate. You then go through the interview process. There's scheduling involved in that, and at some point you make a decision: here's the employee you'd like to make an offer to.

There's a lot of paperwork involved at this point, especially here in the United States. A lot of documentation has to be sent back and forth. There’re probably some negotiations, some redlining of contracts, agreements around salaries, and signatures are put on paper. From that point, the person has to arrive on a specific date—let’s hope that there's a desk and a laptop ready for them!

There's also an account that's been created under their name, and they should have been given access to all the core business systems, whether that's your CRM system, your content management system, or other enterprise systems. And you typically want to schedule review cycles every 60-90 days to make sure this person is happy, comfortable, and that it's a good match for the organization. That's your onboarding piece.

To your point, these entities within the employee lifecycle don't just turn up. They're born, they live, and then they die. At the end of the day in a company, that middle section is where you’re doing regular check-ins, annual performance reviews, pay reviews, and managing benefits and compensation. There are lots of processes attached to that along with lots of regulation.

And then ultimately, a person is going to leave the company. You hope they're leaving on good terms. When they are, there's a flow that you have to follow. Sometimes they may be leaving under bad terms, and at that point in time, it's even more critical that a certain set of steps are carried out in very precise and rapid fashion.

If you have to exit someone from a technology company, for example, you need to make sure that the minute you have that conversation with them (but not before) that they no longer have access to source code for the products they are building. They need to be prevented from sending out e-mails to customers and stealing confidential information. Their access rights have to be revoked, and their network credentials have to be shut down. There's a lot of things that have to happen and ultimately, at the end, there’s more paperwork to manage and more issues to deal with such as exit interviews and final salary payments.

That's a good example. If you look at all the things that work really well or really poorly with that process, you understand that while you would think of the employee lifecycle as a process, it's actually a set of processes or workflows; maybe 10, 15, or 20 workflows could be associated with just that one business entity.


SM: In that middle piece, where the employees are living, chances are if they're a good employee, they're not doing the same job for the entire duration of their employment period. Hopefully they're expanding the scope of their work, they're getting promotions, they're beginning to manage people, and gaining access to more systems and information as a result of that.

So how do companies view that? I'll refer to that as scope or rights creep, to steal from a project development process. Do you see much of that in the customers that you work with?

RD: Yes, and it's a huge space. A lot of dedicated tools exist for the sole purpose of dealing with that type of access control, roles and rights concerns. Take SharePoint for example. There are probably 20 vendors that have built multi-million-dollar businesses exclusively around managing this type of thing. This problem isn’t isolated to SharePoint—for those folks that throw stones at SharePoint and say it is part of the problem—that's just how it is for any information repository. You can buy dedicated tools to deal with some of that stuff, but ultimately, they tend to treat more of the symptoms in isolation as opposed to taking a more holistic view of the problem.

For example, at Nintex, it's very common to see that when you onboard a new employee, there's essentially a template set of rights that are prescribed. So as soon as you onboard someone who's a part of an onboarding workflow, we're actually stamping out the employee into the various systems based off of that template. As the first thing that happens as a hiring manager is that you have to identify whether or not they are part of the base role and whether you want this person's rights modeled off of that template.

Nine times out of 10, for most companies, this stuff is left to chance or typically what happens is, someone says, “Hey, we're in IT, I've just become a manager. I need access to the manager folder.” Someone responds with “Okay” and goes ahead and does that.

The problem here is that a lot of time is wasted, and there's not a lot of arbitration around it. How does that IT person know that your request is legitimate? How do they validate the request and seek proper approval for it? Is the approval logged anywhere? And because an employee has that set of rights, you know what parts to revoke if you ever need to offboard the employee—but do you remember to do that?

There's a lot of those types of concerns and, to your initial point, if you don't know what's going on in your business, this gets super hard.


SM: Another thing I want to touch on is this concept of systems, applications and data sets and who has access rights. One might think that when someone is leaving the company—either on good terms or on bad terms, it doesn’t matter. Simply flipping the switch to “off” is all they need to do, and all the rights are removed. That isn’t always reality, though, is it?

My guess is, because as we both know very well, that IT and the business define and select the systems and applications that they believe the company will succeed in using. However, employees often find many other tools, services and applications on their own to help them do their jobs better. And therefore, lots of stuff might be getting used in the company that won't get turned off when the flip of a switch takes place.

RD: Yes, it's interesting. Just look at my background. I was a long-termer at Microsoft where it's all Active Directory, Windows, and SharePoint. When you turn off the Active Directory account, that's it. You're gone!

Now I look at the companies we work with and find that most use Active Directory for identify management. But the challenge is, they also have Salesforce. They might also be using Box for collaboration and file sharing. Odds are they're using Slack for engineering, Facebook for marketing and churning out ads, and a plethora of other tools to support the other departments in the business. For example, a small/medium business might be using Jira in R&D, the HR team has Greenhouse for recruiting, Workday for employee management, and ADP for benefits and payroll. And the list goes on and on.

At Nintex, there are a number of systems that we use for development, and I have to purposely make sure those are shut down independent of our core internal systems. So, the importance for that off-boarding process essentially means I know what's happening when the actions need to be taken.

Now I can't cater to the completely rogue application that an individual brings in. That can be a little harder. But I do know that as I expand the set of tools that are used in some sort of mandated way, I can at least cater to onboarding, off-boarding, and even the ongoing permissions changes within those applications.


SM: Great point!


Stay tuned for Part 2 of this 3-part series: The Connection Between Cybersecurity and Business Process Management – How Many Process Can You Automate? Why?


Want to comment on this article? Use Twitter. You can tweet to Ryan (@PvtRD), Sean (@sean_martin), and their companies Nintex (@Nintex) and ITSPmagazine (@ITSPmagazine). Use the hashtag #BPMsecurity to connect this thread together!

About Ryan Duguid

Ryan Duguid is Chief Evangelist at Nintex, where he is responsible for setting product and platform vision, driving continuous innovation, and delivering technology to help everyday people solve their process problems. Ryan joined Nintex from Microsoft where he was responsible for the content management business in the SharePoint Product Group.

More About Ryan