Ahyoung An

Brielle Nikaido, Community Manager, Focus

Sharon M. Shaw, CFE, Director Tampa Bay Chapter, ACFE 

The rapid growth and adoption of cloud computing leads to sometimes confusing situations where security remains an afterthought.

At a time when everyone is expected to do more with less, the difference between success and failure hinges upon the ability to communicate effectively. In fact, many people now realize the ability to communicate the value of security, and of their efforts, is the difference between career success and failure.

I recently considered how to cut through the confusion surrounding “cloud security” to successfully communicate the value of our efforts and shared some insights during the BrightTalk cloud security summit. Special thanks to Trend Micro, Symantec, Dave Shackleford and Lori MacVittie for sharing time, research and experience with me.

Blending their insights and experiences with my studies and models of how to effectively communicate value resulted in some interesting findings, including the need to translate our security experiences into the cloud is as (maybe more) important than selecting the right examples. The result is a 45-minute briefing, shared below.

Check out the recording here:

I work to help harness the human side of security; without a doubt, the challenges we face in our journey to the cloud is less technical and more dependent on our ability to successfully communicate with each other, with decision makers and with our colleagues who use the solutions we design, deploy and maintain.

This presentation is only the beginning.

I continue to research, test and help industry, enterprise and individuals to improve how we distill and and effectively communicate the value of security.

How can I help you?

Reach out with comments, questions and suggestions or share your communication challenges with me and we can explore how to solve them together.

It’s something I’ve looked for; the challenge is finding a way to review, distill and curate the best information from a myriad of topics and fantastic conversations. In order to fulfill my passion and purpose to help others harness the human side of security, I devote time each day to consume and process a lot of information.

A few months ago, I started thinking about how to best curate — distill down to the essentials – and share that information with clients, colleagues and friends. More than a simple list of “things I’ve read,” the purpose is to provide some light analysis and ensure the information can be more easily consumed, shared and discussed.

I think I found a format where I can share value and benefit your efforts. I invite you to subscribe to the Curated Catalyst Newsletter and help shape the experience by engaging in the conversation.

Each week, I’ll select and share highlights from articles and resources likely to be of interest to those working to harness the human side of security with a focus on communication, awareness, leadership and the multitude of fields that inform these areas. 

The underlying goal is conversations that count about the insights and ideas that shape our experience. By the way, part of the invitation to engage includes the desire for you to send me ideas, questions and resources of interest, too. I’m the curator of the newsletter, but it’s a larger effort.

While I experiment with the actual format and process (technical and procedural) over the next few weeks, I’m focused on putting forth a weekly summary expected to take 5-10 minutes to scan. More, each should have the analysis/context included to help guide focus and serve as a pre-formatted cut and paste to share with others (individual stories and thoughts).

Sign up for the Curated Catalyst by clicking on this link. Note: your information will not be sold, spammed or treated any differently than I expect my information to be treated. 

More information about the format, schedule and audience is included here: http://www.securitycatalyst.com/blog/curated-catalyst-newsletter/

I look forward to working together and learning from each other!

During the roundtable in July, we defined “security awareness” (recording at link) – an individual’s realization of the consequences of their actions with the ability to assess intention and impact.

So does emphasizing security awareness for a day/week/month make a difference?

Join us on Wednesday, September 21, 2011 at 11am Pacific, 2pm Eastern to find out which members of our panel don’t see the value (and why).

http://www.focus.com/roundtables/security-awareness-roundtable-security-awareness-month-trans/

Then stick around to find out why I now have a different opinion: I see this as an opportunity to turn a lackluster event into a transformed security awareness program.

Join our roundtable and engage with us to find out how to:

• Get buy-in for an event
• Structure an event to solve a single problem (and some suggestions on the problems to solve)
• Set the stage for and define success: why this isn’t a diet, but a lifestyle change
• Determine what elements to include, what elements to skip
• Measure the results to build an effective business case

Get engaged with security awareness

Each month I’ll invite select experts with hands-on experience with security awareness to the roundtable for our discussion. Designed to be more interactive than podcasting, here are some ways to get involved:

• Ask questions in advance
• Participate during the process on the event page or using twitter
• Make comments
• Follow-up with questions and comments after

The current accepted approaches to security awareness mask the real challenge; without understanding and addressing this paradox, the so-called awareness efforts increase risk (instead of decreasing risk).

Building on the last roundtable that defined security awareness, in this episode Steve Ellis and Chris Carpinello join me to explain and explore the real challenge underlying security and security awareness: the “human paradox gap” (HPG).

During this roundtable, I explain the “Human Paradox Gap” and the panel explores the role and impact it plays in their ability to be effective.

Listen to our recording to learn:

• The human paradox gap (HPG)
• How HPG impacts security and security awareness
• Why the gap has to be bridged in order to gain effectiveness

We also answered a question from Bert K:“How do you engage people who just want it to work so they can do their job and go home?”

The audio of the roundtable is now available for download and enjoyment.

We incorporated more stories, examples and considerations – and there is more to come.

I’ll be expanding on key concepts in this blog, my CSO column, and offering some additional resources to help the establishment of effective security awareness programs.

Check out the event page to see what others contributed, ask questions and offer your thoughts (I keep tabs on all questions, comments and contributions for future roundtables): http://www.focus.com/roundtables/security-awareness-roundtable-understanding-real-challenge/

In the meantime, while or after listening to the roundtable:

• Engage with me on twitter to talk about security awareness, effective communication of security or whatever is on your mind
• Send me email or submit questions for this or an upcoming roundtable
• Check out and participate in the security awareness section growing on Focus.com by clicking on http://www.focus.com/topic/security-awareness/

Please mark your calendars to join us for our September Security Awareness Roundtable – September 21, 11am Pacific, 2pm Eastern. Our panel is going to explore how to make the investment in security awareness – including how much is enough and how to make the case to get the funding.

 

The audio of the roundtable is now available for download and enjoyment.

Joined by Justin Bovee and Steve Ellis, we presented the definition of security awareness, explored how it sets the stage for success and offered insights into using the definition to build an effective program.

We also talked about how this definition makes it possible to turn what is often considered a cost into an investment – while satisfying compliance issues and a sometimes sour attitude toward “security awareness training.” We’ll go deeper on that topic in August.

We covered a lot of ground in a short period.

I’ll be expanding on key concepts in this blog, my CSO column, and offering some additional resources to help the establishment of effective security awareness programs.

Check out the event page to see what others contributed, ask questions and offer your thoughts (I keep tabs on all questions, comments and contributions for future roundtables): http://www.focus.com/roundtables/security-awareness-roundtable-defining-security-awareness/

In the meantime, while or after listening to the roundtable:

• Engage with me on twitter to talk about security awareness, effective communication of security or whatever is on your mind
• Send me email or submit questions for this or an upcoming roundtable
• Check out and participate in the security awareness section growing on Focus.com by clicking on http://www.focus.com/topic/security-awareness/

On August 24^th, join us for our second Security Awareness Roundtable and learn how to invest in security awareness, how to get budget and how much it should cost.

The first roundtable addresses a basic challenge: what is security awareness? 

When the concept of security awareness is tossed about without a clear understanding or vision, the results are mixed. The first step to build an effective program is to have the right definition of security awareness.

Join us to explore:

• The definition of security awareness
• How defining security awareness sets the stage for a successful program
• Why the right definition of security awareness moves the program from cost to investment

Check out the details and register here: http://www.focus.com/roundtables/security-awareness-roundtable-defining-security-awareness/

There is no charge to listen in and participate live, and if the time doesn’t work, an on-demand recording will be made available.

Get engaged with security awareness

Each month I’ll invite select experts with hands-on experience with security awareness to the roundtable for our discussion. Designed to be more interactive than podcasting, here are some ways to get involved:

• Ask questions in advance
• Participate during the process on the event page or using twitter
• Make comments
• Follow-up with questions and comments after

No one likes to be a user. Worse, no one wants to be a loser.

Maybe it goes back to the catchy tuned belted out by McGruff the crime dog when he sang, “Users are losers, and losers are users…”

Just last week, a friend pointed out to me that only drugs and IT have “users.”

The roots of calling people “users” are likely harmless and simple: when computers were new, expensive and in limited supply, only a handful of people actually used the system. As a result, it probably made sense to consider those folks as computer users, eventually shortened to “users.”

Today the situation is different.

Somehow this notion of “users are losers” (sometimes written as lusers) transcended drugs and became part of technology. When technology and security practitioners refer to people as users, I feel like singing some McGruff.

And I would sing, except McGruff was wrong: users aren’t losers.

We need to break this bad habit immediately to advance our practice of security and influence how people protect information.

Why the label of users creates a distance that makes it harder to practice security

The word “user” is a label that instantly strips a person of their identity and objectifies them in a way that creates distance and ultimately prevents us from serving their needs.

Distancing ourselves through language and labels is an unintended protection mechanism (I wrote about this in a 2007 column claimingIt’s time to reboot the security industry that reinforces our knowledge, experience and power while shielding us from the knowledge, power and experience of the individuals we work with.

When working with people, distance is a problem. It creates friction and generates resistance that sometimes results in an adversarial state where everything becomes more complex — and expensive.

Security technology and is not enough: we ultimately need individuals to make better decisions. Instead of creating distance, we need to get closer to people and partner with them to guide actions that bridge the Human Paradox Gap.

Introduced in Into the Breach, the human paradox is the unintentional disconnect created between individuals and the consequences of their actions. Because of the gap between actions and consequences, people do not take responsibility and we are powerless to hold them accountable. I explore this a bit further in: Why people are not the problem and where to look.

Our success depends on our ability to get closer to people, to work together to bridge the human paradox gap, to partner on how we protect information.

Dropping the label (protection) of user allows us to build the relationships we need to be successful.

If not users, then what?

We work with and serve people.

As a starting point, make a conscious effort to substitute people or individual(s) in place of the term “user.” In some cases, citing employees, contractors, colleagues or the like might be appropriate.

When possible, use direct names or descriptions of real people.

It is important to remember and keep focused on the point that we serve people, not users.

Change the words to change the perspective

By removing the abstraction of “users” and focusing on the people we serve we necessarily change our perspective.

It is a simple, yet powerful shift.

In turn, it changes our demeanor and approach.

For example, with my clients, our meetings reference real people, actual examples and explore the potential consequences (positive, neutral and negative) of our decisions. We invite non-security people to the meetings. And in some cases, we actually conduct interviews of individuals to better learn how they do their jobs.

McGruff sang a catchy tune. But when we realize our users are people, nobody has to lose. In fact, we can all work together to bridge the human paradox gap and make our jobs just a little bit easier.

When papers like this are released, most of the announcements focus on some quotes, perhaps a general impression and link. After my briefing, I took something else away – and I wanted to share.

Below, I break down my notes in terms of security awareness, security leadership, effectively communicating the value of security and a few thoughts on how a paper like this advances a security career.

The basic concern is clear: smart phones are gaining market share; increased reliance means they are loaded with personal and corporate information. Considering the continued growth of mobile computing, attackers are going to “follow the money” by turning their attention to mobile malware in search of easier, more profitable targets.

The challenge is determining where mobile device security fits into an already crowded and ever-expanding threat landscape.

How big is the risk; how fast do we need to move?

To put it into context, consider the magnitude of the risk: according to the Symantec Internet Security Threat Report there were 163 documented vulnerabilities in mobile device operating systems in 2010, compared to 115 in 2009. The growth demonstrates the rising attention of attackers.

Overall however, Symantec documented 6,253 software vulnerabilities in 2010 (additional context can be found in the most recent ISTR starting on page 15).

The impact of mobile malware on the enterprise is rising; while immediate action may not be warranted, there are some actions to take today to prepare for the future with less friction.

[pullquote]The impact of mobile malware on the enterprise is rising; while immediate action may not be warranted, there are some actions to take today to prepare for the future with less friction.[/pullquote]

Security Awareness

At this point in the year, the security awareness programming plan should be in operation – and no immediate changes are required at this time. The topic, however, does present itself as a good secondary or opportunistic topic – especially if people are starting to ask about it.

To get started, redefine the concept of mobile telephones: they do more than dial numbers these days. Ask questions about the type of information people store. A simple question gets this dialogue started, “what’s on your device?” Follow up with, “what happens if your phone is lost or stolen?”

Asking, “What happens if a rogue application gets installed on your device?” prompts a more advance discussion. The challenge to this level of security awareness discussion is preparing to talk about how this happens without accusing the individual/audience of being stupid.

Start the dialogue this year, if it makes sense, as an opportunity to learn the challenges people are facing and the language they use. This becomes valuable input for next years programming plan (where it still might not be a prime topic).

Security leadership considerations

Like it or not, mobile devices are connected to the enterprise. The growth of mobile computing coupled with the growth of “the cloud” means personal and corporate information is necessarily stored on the smart phones — approved or not.

Reconsider how devices are treated and then review current security policies, standards and procedures to understand how information is protected. Ask questions and consider how the policies address lost or stolen phones and mobile devices. The user experience matters.

Aside: I’ve tested “remote wipe” with clients before. Despite their assurances it would work perfectly, in each case, I was able to turn off the radio transmitter before the wipe and enjoy full access to the information stored conveniently on the memory card inside the phone. Lesson learned: check the policy, and then test to see if it matches reality.

Making the time now — before this becomes a hurried rush that never leads to good decisions — means the opportunity to consider changing functional and technical requirements.

Given the current average time to change policies and procure new technology solutions, this little bit of a “head start” might make the difference between future success and continued on-going struggle.

In short: do the work now, reap the benefit later.

Effectively communicating the value of mobile device security

As security leadership reviews and makes decisions, consider how to effectively communicate and incorporate the changes to the various audiences in the best possible way (hint: email may not work for everyone).

The key to effective user experience is striking the blend between connecting people to the consequences of their actions — restoring their ability to take responsibility — while providing a technical and procedural backstop that helps make it easier for people to do their jobs.

How this helps advance a security career

We’re in a profession where we need to know something about everything (aside: I believe the path to success, however, requires finding a niche and getting good – in addition to knowing a bit about everything).

Mobile device security and cloud computing are both on the rise. Investing time now to amass and understand facts, figures and the ability to explain the importance of these details to different audiences is important.

Breaking down the salient concepts of mobile device security to be able to teach these basic concepts to others in meaningful and appropriate ways is a way to advance a security career.

Your Turn

What do you think? How are you handling the rise of mobile malware, and the continued integration between mobile and cloud computing?

Share your challenges, and if my perspectives on this paper benefit your efforts (or what you’d like to have seen more of).

Can advice from a movie actually benefit a security career?

Short answer: yes, yes it can. In fact, I applied this advice to my own career long before the movie was ever made.

Building on what I shared in the column, here are two examples of how this advice worked for me, with some insights on how it could work for you, too.

Applying it the first time: Bartending for the win

The first time I really applied this advice was while working as a server at a Ground Round restaurant while home from college on summer break. My role was to provide an exceptional dining experience — the better I did, the better my tips (on average).

As a hungry college student, I picked up as many shifts as I could. Somehow, it dawned on me that the more I knew about the restaurant, the better service I could provide, the more money I could make.

I set out to learn as much as I could.

I volunteered to learn how to host (greet and seat), prep cook, line cook and wash dishes. In turn, I taught others how to take orders, present food and the like. The more I contributed to the restaurant, the more opportunity I got.

And I was right: the more I knew about how to seat people (and set the experience), prepare the food, wash the dishes and handle the entire experience, the more I communicated effectively with everyone around me.

The best part came on what felt like a daring offer: I walked into the general managers office with what I considered a great deal: I would work shifts “off the clock” in return for being taught and certified as a bartender.  In the end, he accepted and my training – which also including training on ordering for the restaurant – began.

For the rest of the summer, I worked pretty much around the clock – waiting tables, pitching in wherever needed and got certified as a bartender before heading back to school.

When I returned to school in August, I happened to meet the owners of Johnny’s – a local bar (and one-time staple in Ithaca; it’s not there anymore). I explained that I had just been certified in bar tending — including setup, ordering, pricing, etc – and asked if they needed a hand. After explaining why they didn’t need help, they asked for my telephone number, “just in case.”

I got a call a week later – they needed help. It turned out they bought the bar without a shred of bar tending experience. My efforts to learn all aspects of the restaurant and bar business turned into a job as the head bartender, with the opportunity to teach what I knew as we worked together to setup, open and run a successful bar.

How this helps you: learning the job of others in security careers is important; but sometimes, it’s the other jobs in the organization that hold the most promise. Learning how others do their jobs — and perhaps getting an opportunity to teach them yours — is a powerful way to build bridges, improve communication and set the stage for a successful career in security.

Source code version control launched my career in information security

After graduating college (and one more brief stint in the restaurants), I landed a job working for Andersen Consulting (now Accenture) on a large software development project. My initial role was manual source code version control: developers would email me requests for code and submit code changes to me. Prior to automated tools, this was a bit of an “interesting” position.

After documenting the process – initially so I had a personal checklist to work from – I started to make improvements in speed and quality. I improved the documentation and started to teach the process to others. While I didn’t necessarily enjoy the role, turns out someone I taught LOVED it. At the same time, I lived locally, and offered to come in early, stay late and work weekends to cover others and help out. I was always learning new roles — to the point where I could backup any member of the team.

It didn’t take long before one of the people I trained was in charge of source code version control and I was moved on to bigger and better things. In fact, one of the roles I got moved to was the direct start of my career in information security (a story for another day).

How this helps you: despite an irrational fear of losing your job because you taught it to someone else, one of the best ways to advance your security career is to actively document your current role. Once documented, teach the position to others. I’ve found no better way to backfill your efforts and free up time to focus on other elements, learn from others and create a path to a new role.

More than advice, this is a mantra

My focus is clear: security awareness that works and effectively communicating the value of security. In my role, I work with organizations of all sizes and audiences of all types and experiences from around the world. As a result, I continually seek out people to learn from, and even offer to “intern” with other professionals to learn their jobs. In the process, I gain the insight of their experience, learn the language of their position and come away a more effective communicator.

This advice makes me a better catalyst, allowing me to better serve others. The more I learn, the more I am able to share what I’ve learned with those I come across… and through keynotes, seminars and consulting.

So while it made for a poignant scene in a movie about war, the observation of Lt. Col Moore is a powerful mantra for building a successful security career. Today is a great day to get started.

It works for me, and it works for you, too.

Let me know how you’re putting this advice to work or if something is holding you back. I’m here to help.

Until today, I’ve not shared this with you. It matters, because my turning point (or what I now consider my first turning point) also revealed my passion to advocate for individuals while advancing organizations through security awareness, effectively communicating the value of security and helping individuals and teams use those blended skills to advance their security careers.

Since first putting my turning point onto digital paper, I’ve experienced at least one more (there is a hint in this piece). I’ll write more about that next week. In the meantime…

My Family at Mt. Rushmore

My Turning Point

My turning point is literal: the rolling wheels under our RV and the steering wheel that allows us, as a family, to explore the country, find new places and meet people “where they are.”

It started with a simple vow: to raise my children through active, daily involvement instead of watching them grow up in pictures.

That vow led to a promise to travel as a family. We started with a pickup truck and progressed, quickly, to a forty-foot “diesel pusher” RV (and we towed a “dinghy” vehicle behind us). While we continued to own a traditional stick house in Upstate NY, we used the RV to travel to speaking, training and consulting engagements. Our RV was our second home (arguably our first).

After traveling by RV for over six years (mainly for business), we’ve managed to explore 43 of the lower 48 states and a brief trip into Ontario, Canada. We found that the more we traveled, the less we wanted to be pinned down to a traditional house. Confronting our fears — and conventional wisdom — we finally decided to let go: of the house, of stuff, of the things we didn’t need in order to live and travel in our RV.

On the road, I live the promise (dare I say the dream) with my entire family as we embark on our quest to collect experiences instead of collecting things. Sometimes we look out and see the tranquil ocean, or a forest of trees. Other days we are treated to majestic mountains.

We are liberated to live deliberately.

By the nature of the physical space, we focus on simplicity. And it turns out that less physical baggage has the unexpected and welcomed benefit of less emotional baggage. The conventional wisdom about the things we own owning us is true, even when we deny it in a feeble attempt to fool ourselves.

Celebrating the “Small Things”

When explaining our decision to live and travel by RV, a lot of people ask, “You must be excited to be there for the big things, right?”

The power of this approach is that while I celebrate the big milestones in life, I never miss the small things either — from losing a tooth (literally) to swinging on a playground, cuddling up by a campfire and nightly bedtime stories. We have it all.

For six weeks we have lived “full time” in the RV as our primary residence. We “wintered” at an amazing campground in Myrtle Beach, South Carolina. Our journey is flexible, and includes planned trips to California, South Dakota and wherever else our turning wheels take us.

On the road this way, we get to sleep in our own bed each night, eat from our own kitchen and even have a complete office and school on board! We conduct road school – where we all set goals and work, as a family, to learn and educate each other.

We also learned quickly that leading a more deliberate life has family and business benefits, too. We have less to maintain and worry about – which translates into more time spent truly living, laughing and learning together. Which, in turn, forces better business decisions. And that leads to more business opportunities.

My Turning Point: Uncovering My Passion

The instinctive need to focus introduced a welcome challenge in the first few weeks of being “full time:” what did I do? What was the purpose of our company?

Beyond “information security,” what inspired me and would allow me to apply my experience and energy to drive value, revenue and still allow time to enjoy seeing the country with my family?

At this point, Into the Breach (amazon link) was published, I accomplished recognition as a professional speaker, and ran a successful seminar teaching others how to effectively communicate the value of security. And yet my consulting practice took me all over the industry. While that was great for the first decade, it felt like it was time to concentrate on doing one thing better than anyone else.

So began my personal journey to find the “one thing” to focus on, something that sparked my passion, that made me feel alive while providing value to my family. I wanted to build on my experience of almost 15 years in information security, communication and my love of advocating for people.

Living in an RV encourages time to get out, move around and connect with the world around you. For me, this meant daily walks around a lake (some days, it meant a lot of laps, too). After my walks, I would often reach out to clients, colleagues and friends to explain the pieces I saw coming together and get their feedback, learn from their insights and listen to their guidance.

My turning point not only brought my family closer together and put us on the path of a more simple life, it also helped me uncover and voice my true passion: the “human side” of security.

On February 18, 2010, it was clear that my focus was blending my background in human ecology, information security and professional communication to focus on security awareness, effectively communicating the value of security and helping people advance their security careers.

Living As We Are

Because of our approach, I invite clients, colleague and friends (anyone, really – I guess I’ve never really met a stranger) to join us at our house on wheels for a meal, campfire and conversation.

There is something powerful about meeting people where they live and sitting around the campfire. Beyond celebrating the simple life, this allows me a rich fabric for story development, genuine connection with any audience and the windshield time to think, make connections and improve my ability to serve others as a catalyst.

On our journey, I hope to sit by the campfire with you (this is an offer with no expiration).

In my next “flashlight” article (imagine me sitting around the campfire, holding a flashlight to my face, telling stories), I’ll share my next turning point, and the continued focus on awareness, communication and career.

I look forward to connecting, sharing and learning from you.

Life is great!

If you think that your tangled Cat5 in the server room is a mess, wait until you look at your network drive file structure. Licensed from Stock Exchange.

This is the seventh post in a series about data breaches you can prevent. We’ve covered Phones and Personal Computing Devices, Your Browser, Your Inbox, Your Thumb and External Drives, Your Old Computer, and Your Cloud Backup. Finally, we’ll discuss Your Network Drives.

Most companies have an internal corporate network with one or more shared network drives. If your company network drive is typical, it’s a layered mess of multiple naming conventions, files from employees who haven’t been around for years, and old documents with unrecognizable file extensions. Frankly, it’s impossible for anyone to know exactly what’s there.

Sometimes breaches happen when the internal network is not properly segregated. Only individuals or departments with a “need to know” should have access to sensitive information. The Human Resource department should never have access to trade secrets, while the R&D department shouldn’t have access to HR data. The Executive team should have access to confidential client information, while that information might be best kept away from the Sales department.

Aside from inappropriate network segregation network drives, like all computer devices, are eventually replaced. Old hard drives are sometimes donated to schools, sold on Ebay, thrown away, recycled through Best Buy or a similar program, or just stored and forgotten.

Several researchers, including Simpson Garfinkle, have demonstrated that with a small budget you can recover hundreds of thousands of pieces of personal information from used hard drives. Like other computing devices, old network drives must be scanned and completely wiped of all sensitive personal information before they leave your possession.

Remember the fundamentals rules of all data breaches: 1. If you don’t have it, you can’t breach it. 2. Old, forgotten data is dangerous data. Regularly scan these seven types of devices for personal information so that your next breach doesn’t originate from your own computer.

Cloud backups are like giving your house keys to your neighbor; Except that your neighbor then gives it to his neighbors, but doesn't tell you which ones. Licensed from Stock Exchange.

This is the sixth post in a series about data breaches you can prevent. We’ve covered Phones and Personal Computing Devices , Your Browser, Your Inbox, Your Thumb and External Drives, and Your Old Computer. Next we’ll discuss Your Cloud Backup.

Online cloud computing gives individuals and small businesses access to Fortune 500 computing services, for dirt cheap or free. Consumers have the choice of hundreds of cloud backup and file sharing programs.

A cloud backup is much like giving a copy of your house key to your neighbor. By choosing a trusted neighbor, you can be sure that your house key won’t fall into the wrong hands, and you will be able to use it you ever lock yourself out. You will also be able to change your lock if your neighbor’s house is robbed, or retrieve the key if your neighbor’s house is foreclosed.

If a cloud provider is like your neighbor and your personal information is like your house key, cloud backups go one step further. Each time you give your key to the neighbor (that is, back up a file in the cloud), your neighbor then makes several copies of your key and gives it to several other neighbors he trusts. While this means your key will probably never be lost, you have no way to know who exactly has your key, and retrieving all of the keys may be impossible.

Online cloud computing is still in its infancy, and the legal status of cloud backups can get rather, shall we say… “cloudy.”
You must recognize that once the information leaves your computer, you have very little control over where it goes, who owns it, and how many copies are made, or in which countries the files are stored. You may even forfeit your right to permanently delete a file once you put it online, in the “cloud.”

This issue recently came into focus after what has been called the first documented Cloud Data Breach. A bug in Microsoft’s cloud systems exposed confidential information and caused PC World to lament, “You’d better get used to this kind of thing because we’ll be seeing a lot more of it in the future. All any of us can do is pray we’re not a victim.”

Be sure to scan any files you backup online for sensitive information. If you choose to use a cloud backup service, always encrypt personal information, trade secrets, confidential data from third parties, and other sensitive information before backing it up online. Encrypting this information will ensure that should a breach occur, the information will be unusable to an adversary.

I use a cloud backup service called Dropbox. I love it. I use the program to share non-sensitive pictures with my family who lives 2,000 miles away, and share corporate documents with co-workers.

However, if I really need to back up truly sensitive information, I always encrypt the files before I put them online. Before you do a wholesale backup of your entire “My Documents” folder, make absolutely sure that you either encrypt sensitive data, or exclude it from the online backup. That way if a Cloud breach happens, you can rest assured that you won’t be at increased risk.

Digital pack rat: You probably have a backed-up copy of your old 256 MB hard drive, don't you? Licensed from Stock Exchange.

This is the fifth post in a series about data breaches you can prevent. We’ve covered Phones and Personal Computing Devices , Your Browser, and Your Inbox, and Your Thumb and External Drives. Next we’ll discuss Your Old Windows 95 Computer.

Technology has made it easier than ever to be a digital pack rat. Cheap and plentiful memory probably means that you have backed-up a copy of your old 256 MB hard drive, which you also have stashed somewhere in your basement. Before blindly making back-up copies of old hard drives, make sure that you first delete any information you don’t want to save.

I see this problem haunt people across the country. Once a week a university professor somewhere in the United States copies an archived copy of an old hard drive to a web server, without realizing that the hard drive contained social security numbers of students who graduated a decade earlier. Within weeks those social security numbers can be available to the world via Google.

If you’re a digital pack rat, make sure you scan those old hard drives for sensitive personal information before making backups. Your old hard drive is one of the biggest sources of preventable data breaches you’ll never hear about.

The Law of Portable Device Breaches says that the risk of losing a device, and the information thereon, is directly proportional to its portability. Licensed from Stock Exchange

This post is the fourth in a series about data breaches you can prevent. We’ve covered Phones and Personal Computing Devices , Your Browser, and Your Inbox. Here we’ll explore Your Thumb and External Drives.

Just about anything that can store information can be used to store sensitive personal information. Whether you use an external drive to back up sensitive data, or use a thumb drive to transfer large files from one computer to another. The Law of Portable Device Breaches (which I just made up) says that the risk of losing a device, and the information thereon, is directly proportional to its portability. In real terms, this extremely scientific law means that you’re more likely to leave your cell phone at the bar than your desktop computer.

Readers of this blog no doubt assiduously delete sensitive information from portable devices on a regular basis. But simply deleting files doesn’t actually erase the data. Just like cranberry juice on white linen, personal information stains hard drives.

Simply throwing a stained table cloth in the washing machine won’t remove cranberry juice stains. Likewise, simply hitting the “delete” key and emptying the recycle bin won’t completely remove personal information from your thumb or external hard drive. The hard drive usually remains stained with the sensitive information, which may be recovered until you proverbially “scrub” the drive. This scrubbing is called “shredding” the file, and typically requires at least a three-step deletion process whereby each byte is individually overwritten.

You should always think twice before copying sensitive files, such as tax documents, pictures, passwords, or confidential documents to removable media. Regularly scan removable media forgotten personal information so that when you leave your thumb drive in the taxicab, you don’t accidentally cause your own data breach.

Do you really know where that 2007 list of emailed SSNs is? Licensed from Stock Exchange.

This post is the third in a series about data breaches you can prevent. We’ve already covered Phones and Personal Computing Devices and Your Browser. The next source we’ll explore is Your Inbox.

Many people use web email as an extra online hard drive, saving important files and attachments in an easy-to access location. Yet because other people send you information via email, ironically you have less control over what’s in your inbox than on your hard drive. And the fact that the each email is stored in multiple places makes your inbox an important and often overlooked source of breaches.

Every email can be copied and stored on more than a dozen devices, many of which are not secure. Every time Outlook or Thunderbird checks for new email, a copy of that email or webmail is stored on your local computer. Smart phones also create local copies of your email so that you can open an attachment or read notes from your boss even if you don’t have access to the internet. A copy of every email you write is often stored on your local device (such as your phone), local servers (such as a work server), remote servers (like gmail.com), your desktop, your laptop, as well as all of the devices belonging to the recipient. The “Send” button should be more appropriately labeled “Make more than a dozen copies of this email and send them to insecure devices across the world.”

Keeping track of everything in your inbox and sent folder is a super-human task. Though most of your hundreds of daily emails are mundane, occasionally an unenlightened coworker might send you excel file entitled “Client Social Security Numbers,” or “Customer Username and Passwords.” Once your coworker hits send, the rogue file is copied to hard drives, cell phones, and servers across the world. Without your knowledge, the sensitive information quietly copies itself to your computers and cell phones.

With every copy of the email or personal information, the risks of a breach increase. And each day you receive hundreds of new emails, it is easy to lose track of old emails you were meaning to delete, but are now buried and forgotten. Old, forgotten data is dangerous because it is easily lost or misplaced. Lost email may create a significant breach of personal information, so make sure you are aware what’s in your inbox, because you shouldn’t expect to get a notification if your sensitive email ever falls into the wrong hands.

Your Stored Passwords: Not exactly secured. Licensed from Stock Exchange.

This post is the second in a series about data breaches you can prevent. We’ve already covered Phones and Personal Computing Devices. The next source we’ll explore is Your Browser.

Laptops, desktop computers and smartphones all have built-in internet browsers. A typical browser can store hundreds of passwords and usernames, credit card numbers, contact information, and browsing history. Even though we use our smart phone browsers to do a significant number of online transactions, typical smart phone browsers do not allow users the same degree of privacy control as desktop browsers.

Aside from browser hacks and viruses, it’s important to remember that your browser caches remain intact and accessible even after the machine is lost, stolen, or sold. That’s one reason why it’s important to scan your browsers for personal information and delete unnecessary information, and use a master password whenever possible.
I fancy myself a fairly savvy and privacy-aware individual. I use Firefox and have installed several plugins to help me manage my privacy, including Better Privacy, GoogleShairng, a few PrivacyChoice Plugins, and Abine’s TACO. But when I ran an Identity Finder search, even I was shocked to see the depth of information that my browser stored. It was very sobering to see that my usernames, passwords, and credit card numbers were accessible in plain text. Fortunately, Identity Finder allowed me to delete or secure all of that information.

If your browser caches are ever lost, it may represent a significant breach of personal information. So make sure you are aware what information your browser is storing, because you shouldn’t expect to get a letter in the mail if it ever falls into the wrong hands.

Smart phones are now portable computers which just happen to make calls. Licensed from Stock Exchange.

This post is the first in a series about preventable data breaches. Most Americans have received a letter, telling them that their personal information has been breached. But there are many breaches you’ll never hear about, and many of them are right under your nose. The first source we’ll explore is Your Phone and Personal Computing Device.

Remember when cell phones were telephones? Those days are long gone. The current generation of smart phones are powerful computing devices which just happen to also make phone calls.

Your personal computing devices perform almost all of the functions of a laptop computer. Smart phones, iPads, Kindles, and other devices are notoriously easy to lose, and store gigabytes of files, passwords, credit card numbers, social security numbers, digital photos, address books, and email attachments. Because of the wealth of personal information on a cell phone, most people would rather lose their wallets, and nearly all respondents to a 2009 survey said they would be “devastated” if they lost their phone.

Upgrading your phone can be as risky as losing it. Some people donate their old phones to charity or sell them on Ebay, and experts warn that personal information on the phone could easily be mined and re-sold. Periodically search your cell phone for personal information, and make sure that you digitally shred the entire contents of your mobile device before you get rid of it.

At the micro level, when a user transfers within a department, the transfer may be missed altogether if the affected job codes are not flagged in some way as needing additional information.

In this segment, we focus on two special-case terminations:

• The terminated user takes a leave of absence (LOA) prior to termination
• The terminated user is laid off as part of a reduction in force (RIF)

In each case, the user no longer needs access, but remains active in the HR system because they continue to be paid by the company.

This can pose a security threat, especially in the case of the laid-off employee.

The solution lies with HR…

In these cases, the simplest solution lies with HR: ensuring that the system has – and that HR representatives and hiring managers actively use – a “last day worked” field.

This field is ideal for access management because when it comes down to it, if the employee is no longer working, they no longer need access – irrespective of whether they’re still getting paid.

I strongly recommend working with the HR team to implement or clean up the last day worked field as needed to make it usable with identity management – it simplifies terminations tremendously. If it’s not an option, processes should be developed to handle the afore-mentioned special cases. For example:

• Design a process that will review the termination reason on the day that the termination is entered into the system. If the reason is RIF, determine when the access should be cut off (since RIF information is so highly sensitive, it is normally not entered into the HR system until the user is notified, so the date of entry might be usable as the last day for access)
• Alert on any user that goes into LOA status but that also has a termination date entered into the system, and design a process for verifying if the user is returning from LOA or going straight to termination, and process accordingly. Some manual intervention may be required here – some employees on LOA may still require their access, while others will not. HR should be able to help with this.

…but IAM configuration plays a part

When designing the interface between identity manager and HR, it’s important to consider how terminations will be identified.

If the HR system stores a reliable last worked date, the configuration of identity manager will be simple. If not, careful thought needs to be put into the design of the interface.

Simply going by the effective date of termination without any additional validation will preclude automation of the special cases mentioned above, and although they are relatively rare, these special cases can pose significant security risk if not properly addressed.

In summary

When properly configured, de/provisioning workflows help realize a significant portion of IAM’s value by reducing the time and effort of managing access, while tremendously increasing the accuracy.

However, in the case of transfers and terminations, there are some special cases that need to be thought through to ensure that the de/provisioning workflows are truly complete.

The activity this month was primarily to think about these special cases, and document how they will be handled. It’s possible that a “do nothing” or manual processing approach will suffice, but some organizations will want to spend some time designing automated solutions so that these special users don’t slip through the cracks.

Populating the requirements list

This month, most of the requirements (with the exception of the SoD requirements mentioned in Part 2) are not for the product, but rather for the design team.

Be sure to specify the needs when it comes to special cases for terminations and transfers. Engage HR and management to come to an agreement about how much effort will be put into handling these cases in an automated fashion versus simply implementing manual processes. As usual, there is no right answer here – as long as the right people are involved in the decision and they get a good understanding of the risks and rewards, the right answer for your organization will be reached.

How can I help?

Do you need some clarification or additional assistance? Do you have an experience to share with others? Leave a comment below so we can all improve together.

When we talked about the implications of HR as a source of record for identity management, we discussed that HR’s purpose is to pay people, not determine their access. The example given was that of a finance analyst – in HR terms, there’s no distinction between an accounts receivable analyst and an accounts payable analyst – they’re both finance analysts and they get paid the same way, so they have the same job code. In access terms, there’s a very big and important difference between accounts receivable and accounts payable.

When granularity is needed beyond what HR can provide through a job code, additional analysis is needed to ensure that these types of transfers are caught and handled.

Augmenting job codes

There are a number of ways to augment a job code to distinguish between roles when it is access-relevant but not HR-relevant.

The additional information *should* still be available from HR, as well. For example, consider the location of the individuals, or the manager’s job code or title. Manager name could be used as a last resort, but only if vacancy management is already in place.

The IAM team will need help from the HR team to determine what additional information can be used to accurately identify intra-departmental roles for transfer purposes. This can be quite challenging, and it may be a foreign concept to the HR team at first. This is again where prior relationship building will really come in handy.

As a last resort, identity manager can be configured with additional flags that can be set manually by an HR representative or manager if appropriate information is not readily available in the HR system. This, of course, will require the creation of one or more workflows.

Don’t forget the cleanup!

Once the job code augmentation parameters are identified, it’s good to run some reports and double-check current members of intra-departmental roles of interest. You may be unpleasantly surprised by what you find, but that’s always better than being unpleasantly surprised by what the auditors find. J

Populating the requirements list

Many IAM systems have built-in functionality to handle segregation of duties (SoD), but as with everything else, not all systems are created equal. If SoD is of particular concern in your organization, be sure to add the specific requirements to the master list so that they are addressed in the product evaluation.

In the next segment, we’ll take a look at special-case terminations and how they can affect access, and wrap-up the month’s activity.

To have truly effective de/provisioning workflows, however, we need to take a closer look at terminations and transfers. There are some “gotchas” that – while rare – can cause angst and give the IAM program a significant black eye. Namely:

• Handling cross-HR system transfers
• Transfers within a department
• Termination of employment vs. termination of access

This series focuses on these gotchas and shares strategies to avoid them.

The reality of multiple HR systems

It’s not uncommon for large organizations to have multiple HR systems – especially when there has been merger & acquisition activity. It takes time to convert new parts of the company to the standard tools, and in some cases it never happens. Worse, multiple HR systems doesn’t necessarily mean separate instances of the same system, but possibly different versions of the same system, or even different brands of HR system.

Clearly, dealing with multiple HR systems – whether they are the same version, different versions, or different brands – adds a level of complexity to the IAM implementation because HR is such a critical interface. This situation can be handled in a variety of ways – some more feasible than others.

Options for handling multiple HR systems

The best solution (but also the least feasible in many cases) is to consolidate the HR systems in preparation for the IAM implementation. This may be a situation where IAM can help HR – if this is a desired HR project — but they might need help convincing management to go for it. The cost savings that will be achieved in the IAM implementation by having a single HR system may give the consolidation project just the push it needed (aside: this is an opportunity to increase “security” with a focus on operational efficiency).

If consolidation is either not possible, or likely too distant to be useful, consider keeping the systems that will be consolidated (and their employees) out of scope of integration with IAM, and focus only on the system that everyone else is consolidating to.

In this case, the non-employee management workflows described previously can help manage the out-of-scope employees until they are brought into the master system. Some modifications might be needed, but they tend to be straightforward.

For example, ensuring that the user input form has one or more appropriate user types to accommodate out-of-scope employees. It’s best to have one entry for each out-of-scope HR system to be able to easily identify which employees come from which system.

Another option is to manually enter and manage out-of-scope employees in IAM until the HR automation comes into play. This is the least desirable alternative, but it’s better than nothing, especially if the non-employee management workflows haven’t yet been implemented.

Dealing with cross-HR system transfers

Ultimately, the problem with multiple HR systems is properly recognizing and handling inter-system personnel transfers.

Typically, when an employee transfers from one HR system to another (and the systems don’t communicate), they show up as a termination in the first system, and a new hire in the second system. From a customer service perspective, there’s nothing worse than terminating someone’s access when they’re still with the company – especially if it happens to be a senior executive.

The best way to handle this is actually to request a modification in the HR systems.

HR systems typically contain reasons for termination – add one called “transfer to another HR system,” or even add one for each additional HR system (e.g., “transfer to HR system x,” “transfer to HR system y,” etc.). We’ve discussed that HR teams may be reticent to change their system – this is where the past relationship building with the HR team can really come in handy.

Having a flag to indicate that a terminated user is actually a transfer can really help – identity manager can be configured to read and understand that flag, and trigger a transfer process/notification instead of a termination. Even if handled manually by the access services team based on HR reports, this flag will alert them that special processing is required.

If changing the HR systems to add a flag is not an option, then a clear process must be established with the HR representatives that process terminations. Access teams must be notified when an inter-system transfer is about to take place. The access services team will also need to document a process for receiving and handling those requests, especially if it entails over-riding or pre-empting automated processes. Care in coordinating these two teams pays large dividends.

A special case of a special case

Transferring from employee to non-employee is one more special case to consider. This can happen if an employee retires or is laid off but is retained as a contractor, or when a portion of the business is outsourced so the employee becomes a non-employee. In most cases, the user’s job function – and access – stays the same. The problem is that they are terminated in the HR system.

The solution to this is similar to the solution for handling inter-HR transfers. Ideally, the HR system can be modified to include a termination reason of “converted to non-employee.” The other alternatives described above can also be applied.

Looking ahead – unique employee numbers

Another key challenge of multiple HR systems is unique employee numbers.

Separate systems may use the same numbering scheme, which could result in different employees in different parts of the organization having the same employee number. When consolidation occurs, this is a problem – both in the HR conversion, and the linking with identity manager.

If the IAM implementation begins before the HR consolidations are complete, it is critical for the IAM team to work with the HR consolidation project to obtain the mapping of employee numbers from old system to new in advance. Once the employees are converted in HR, their employee numbers can be bulk-updated in IAM, which will allow for smooth automated linking.

If out-of-scope employees are manually maintained in identity manager for any length of time before the HR feed takes effect, some cleanup will be needed – undoubtedly employees will have terminated or transferred without notice – that’s the nature of manual processing.

It’s important to fully clean up the users before attempting to update the employee numbers and linking them to HR to ensure a clean linking.

In the next segment, we’ll take a look at transfers that occur within a department.

• Provisioning and deprovisioning (which I abbreviate as de/provisioning)
• Non-employee management
• User and access recertification

These workflows build on each other – it’s necessary to identify how access is de/provisioned before any recertification can be set up, because ultimately once the reviewer completes their recertification, the de/provisioning workflows are kicked off in some capacity to make the indicated updates to users’ access.

It’s possible to go after recertification first, but it’s a lot less powerful without closing the loop with de/provisioning.

Recertification is further broken down into non-employee management and everything else. Non-employee management is a fairly small and relatively simple sub-set of the larger recertification workflow set. By addressing it first, valuable experience can be gained and this is a high-visibility quick-win that’s desirable not only to the access services or security team(s), but likely also to finance, and possibly HR.

There is a lot of work involved in preparing for the implementation of these workflows. By spending some time up-front, it will not only speed the eventual implementation when a system is selected, but it will also generate invaluable requirements that will be critical to the selection of the right system.

The approach this month was as follows:

1. Identify ways in which the workflow set could be developed, ensuring that the right scope is identified for your organization’s specific circumstances
2. Populate the requirements list accordingly. This is critical – miss these requirements and the product selection could be flawed. Select the wrong product and at best ROI will be reduced – possibly significantly; at worst, a rip-and-replace may be needed.
3. Execute the prep-work that can be done in advance of obtaining a system.

Yes, this month “prep-work” can be considered a euphemism for “cleanup” but not entirely. And no matter what you call it, it’s gotta be done.

For de/provisioning, this means reviewing any current de/provisioning processes, streamlining them, and understanding the technical details in the access. The more work that’s already been done with role- and rule-basing (as discussed in June), the easier this will be. Now is also the time to start preparing target systems as needed – such as by cleaning up UNIX UIDs.

For non-employee management, the key prep-work is ensuring that the user entry forms in identity manager have the needed fields designed into them, and that timelines have been considered for handling renewing fixed-duration non-employees. It’s also important to begin working with the appropriate internal groups (e.g., security, audit, affected business groups) to determine an appropriate frequency for recertifying ongoing non-employees.

User/access recertification may have the most time-consuming and difficult prep-work: defining the mappings between the technical permissions and the business access that they provide. This will likely require significant collaboration with business “power users” and can be very time-consuming in database and mainframe systems where permissions are highly granular. It’s also important to think about frequency of recertification, and whether the line manager or data/access owner will be the reviewer for any given application/permission set.

Next month, we’ll take a closer look at some special cases related to terminations and transfers, and how those circumstances can affect the de/provisioning workflows.

How can I help?

Do you need some clarification or additional assistance? Do you have an experience to share with others? Leave a comment below so we can all improve together.

Having built some experience and achieved a quick-win, we’ll now move on to discuss the full user and access recertification workflows. This has become a key control for many audits, and it’s probably the most time-consuming of the controls to execute. Automating user/access recertification using an IAM product can save a lot of time and effort on the part of the access services team(s), and it will also make things easier for the reviewers.

Objective 1: Determine the appropriate scope

There are three decisions that influence scope. The first decision to be made is whether or not user recertification is needed. Sometimes it is sufficient to simply recertify access.

The ability to recertify access is based on the accuracy of the HR data being fed into identity manager. If HR is clean enough (possibly with the help of vacancy management), then it can be assumed that the right people will show up in the right job functions, and the reviewers don’t need to check for this.

The second scope decision pertains to access: the scope for access recertification may be smaller or otherwise different from the scope for de/provisioning. For example, security auditors don’t look at devices de/provisioned to a user, but internal financial auditors who are concerned about how money is being spent might. If automation of recertification were used purely for external audit purposes (e.g., SOX), then equipment would likely be out of scope.

The third scope decision is identifying the appropriate reviewer for the items in scope. For those roles that are well defined with role- or rule-basing, the reviewer might be the individual(s) that helped to design the roles/rules (e.g., the data owners). In the absence of role- and rule-basing, the reviewer should be the line manager.

This determination is important because the data owners tend to be more technically familiar with the system, so they can be presented with a list of permissions and they will understand what that means. Line managers will have no idea what the permissions mean, so they need to be translated into business functionality.

Objective 2: Populate the requirements list

When it comes to recertification, be clear in the requirements about what is important. Consider the following:

• Ability of the system to pull line management information from HR
• User-friendliness of the reviewer interface, including ability to display technical permissions or business translation
• Ability of the system to generate reports (and how customizable those reports are)
• Ability of the system to trigger manual or automated tasks to action the changes requested by the reviewer
• Ability of the system to handle escalations without human intervention

Objective 3: Identify prep-work

The most important prep-work that can be done in preparation for automating recertification is to generate the permission-to-business-function mapping.

Line managers don’t know what MECGRP60 is, nor should they have to learn. A key advantage of a good recertification tool is the ability to translate the techno-babble into meaningful information for a line manager: MECGRP60 grants write permissions to screen X in application Y.

In some systems, this mapping is easy – if there are just a few permissions. But in most database and mainframe systems, the numbers of permissions and groups are enormous. Worse, it’s likely that no one on the business or the IT side knows which permissions go with what access.

It could take a series of working sessions with business and IT working side-by-side to figure it all out. This could take months, but will pay big dividends when it’s done. And just as with the other cleanups we’ve discussed, once it’s done, it’s fairly easy to maintain going forward.

Other prep-work that can be done in this space includes identifying how frequently the recertifications need to be executed, and which data owners will be reviewers for what roles/rules.

In the next segment, we’ll summarize this month’s activity and wrap up.

Non-employee management is a problem that many companies have because non-employee data is typically not centrally stored in an HR-like system as employee data is. By implementing this set of workflows, it creates a closed loop which allows identity manager to be the source of record for non-employees and closely track their comings and goings in a timely fashion.

Objective 1: Determine the appropriate scope

The scope discussion for non-employees is pretty cut-and-dry: the scope is non-employees. J But there are a few nuances.

For example, if there are employees whose HR system will not be integrated with identity manager, they may be managed like non-employees and be considered in scope.

There’s also the distinction between fixed duration and ongoing non-employees as described in this month’s Introduction. Fixed duration non-employees are those that are around for a specified timeframe to do a specific piece of work – such as a project resource or temp. These individuals should be tracked according to their projected end-date.

Ongoing non-employees are those that provide a continuous or intermittent service – such as a supplier, and outsourcing provider, or the Cisco guy that the network team calls at 3am when something bad happens and the fix is beyond their expertise. In this case, the company has an ongoing relationship with the employer of the individuals in question, but the specific individuals may change.

For example, the Cisco guy may get a job elsewhere and be replaced by a new Cisco guy – the company still gets support from Cisco, but it’s important to know if this year’s guy is the same person as last year’s guy. In this scenario, individuals are recertified periodically on a schedule.

Objective 2: Populate the requirements list

The requirements for non-employee management are more internal. The associated workflows are straightforward and possible with any of the better products. But, there will be some configuration requirements. For example, the identity manager form that’s used to enter non-employees into the system should ask what type of non-employee it is (fixed duration vs. ongoing), and prompt for an end-date for fixed duration individuals. The end-date will be needed to trigger workflow tasks, asking the line manager if the person is leaving on time or if they are being extended.

The individual’s company should also be a required element on the entry form – it’s helpful to recertify all individuals from a single company on the same schedule.

Objective 3: Identify prep-work

Hopefully, the non-employee cleanup occurred as part of the activities outlined in February and March. If not, it’s time to get cracking on those – it’s important to know who all of the non-employees are, who they work for (their company’s name and your company’s line manager), what type of non-employee they are, what they do, and what their expected end-date is (if applicable).

This may be especially challenging for IDs of vendor support personnel like the Cisco guy, since they typically aren’t around very often, and are rarely if ever on-site. With this type of non-employee you typically have to go find the one manager who recognizes their name, and even the manager who should recognize the name might not. But having a good, clean list of non-employees and their associated data will make implementing the workflows a breeze.

It’s also good to start thinking about the timings of the workflows:

• How long before an end-date does the line manager first get notified?
• How many times does the line manager get notified before there’s an escalation?
• What if no action is taken by the due date – does the user get submitted for full termination, or are they just disabled?
• What is the cut-off for re-starting the workflow for an extended individual? (E.g., if the person is extended a week, it’s probably safe to trigger termination on the new end-date. But what about if they’re extended a month or more? In that case, it’s probably best to re-start the workflow and ask if there will be an additional extension.)
• How often should ongoing non-employees be recertified – quarterly? semi-annually? annually? This is a policy question that may take some discussion and vetting.

In the next segment, we’ll discuss the full set of user and access recertification workflows.

• Provisioning and deprovisioning (which I abbreviate as de/provisioning)
• Non-employee management
• User or access recertification

This segment explores the first of these, de/provisioning)

De/provisioning is the most common of IAM workflows. Done right, this workflow delivers tremendous ROI, improved audit results and improved customer satisfaction by significantly speeding up the de/provisioning process. It is also the most complex, as a workflow has to be identified for each access or equipment type. Furthermore, for those access items that will be automated, instructions may have to be provided to the IAM system on how it needs to grant or remove access.

Let’s now run through the objectives outlined in this month’s Introduction segment for this set of workflows.

Objective 1: Determine the appropriate scope

A workflow can be created for just about anything, but does it make sense to create one?

To begin answering this question, refer back to the previous lists of systems (created about seven months ago). Begin with the primary systems and move on to the secondary systems. Chances are, some degree of workflow will be needed for each one of these systems.

Also consider what manual workflows might be appropriate – for example, for computers, mobile devices, application licenses, etc.

Another important input here is the company’s service catalog. If one exists and it has built-in workflow, a good portion of the work is already done. Not all of it, since the service catalog triggers tasks for manual de/provisioning only. But at least the workflows in the service catalog should give some sense of order of operations (i.e., which tasks can be performed concurrently and which must occur sequentially), and it should contain the names of the teams involved in each workflow.

For equipment workflows that will stay manual, the services in the service catalog may be replaced by or augmented with similar workflows in identity manager. For access workflows that will be automated, those teams will need to be engaged to better understand the technical details.

A note of caution – be careful when approaching teams with an offer of automation. Those teams that are overwhelmed with work will very likely welcome the offer, but those that are less busy or if they perceive that their entire job will be automated will be understandably reticent to participate. They will perceive that you’re coming in to eliminate their jobs. And yes, it will be that personal – anyone on the IAM team will become persona non grata, bringer of pink slips.

It is worth spending time understanding how the IAM team’s efforts will be received, and engage management appropriately. This may also impact the scope of work, as items that should normally be included in scope or fully automated may have their scope reduced or be eliminated from scope if the political situation gets too volatile.

The questions that need to be answered for this objective are:

1. Is a workflow going to be created for this item?
2. If yes, will there be automation, or manual task assignments?
3. What are the teams involved?
4. How will the teams receive our efforts?
5. Is there an existing workflow that can be leveraged?

Objective 2: Populate the requirements list

The requirements list must be clear based on the determined scope. If full integrations are expected with any systems, the technical expectations should be documented (if they haven’t been already). Remember, not all IAM products are created equal, so selecting the one that best meets the requirements is vitally important.

Objective 3: Identify prep-work

There is quite a bit of prep-work that can be done to speed up implementation once a tool is selected. For example:

• Working with the people familiar with the de/provisioning processes to understand and streamline those processes – are the processes usable as-is, or are they a mess or outdated?
  • In particular, it’s important to understand the deprovisioning process: can an account simply be deleted, or does it first need to be disabled for a time (e.g., to allow for data backups)? If there is a disabled status, what will be the duration for that one week? two weeks? a month?
  • Similarly, can a piece of equipment be taken away directly, or are there data backup needs there too?
• Cleaning up existing service catalog workflows so they can be more easily transitioned (if applicable)
• Preparing target systems – this is especially important on UNIX. Integrating UNIX systems will be much easier if the UIDs are already syncrhonized across the enterprise. If not, this is a good time to begin the cleanup effort. If this already got done as part of the March activity, great job!
  • Also consider if directly integrating each UNIX box with IAM is optimal, or if an intermediary tool will be used to manage UNIX access via LDAP, Active Directory, or the mainframe.

In the next segment, we’ll explore the user/access recertification workflow set.

This month, we continue down the workflow path by considering the more traditional workflows:

• Provisioning and de-provisioning (I like to abbreviate this as “de/provisioning”)
• Non-employee management
• User or access recertification

These workflows can be significantly more complex than the vacancy management workflows described last month. But as with vacancy management, decisions need to be made as to the level of automation that will be implemented as this may impact product selection. For example, if the organization relies heavily on mainframe applications and a high degree of automation is desired for mainframe de/provisioning, then this should be front and center on the requirements list, as not all products handle mainframe integration equally.

Workflows, if designed and implemented correctly, can also provide significant ROI in terms of de/provisioning speed, reduced effort for audits, elimination of future user cleanups, and decreased costs for things like licenses and equipment.

Let’s look at the benefits of each workflow type in a little more detail.

De/provisioning

As discussed before, there are two categories of “things” when it comes to de/provisioning: those things that can be automated (e.g., access – it just depends how much money and effort you’re willing to spend on the automation), and those things that can’t be automated (e.g., equipment – a new laptop will never float down the hall to the waiting hands of a new employee, someone has to deliver it or at least call the employee to come pick it up).

Clearly, any de/provisionable items that are automated save time and effort if the system can automatically do something in a few seconds that might take a human being minutes to do. The trade-off is the complexity of the integration as compared with the expected usage. An application with ten users will likely never have de/provisioning automated – it’s probably too expensive. Then again, if it’s a critical application and likely to get overlooked since the access changes rarely, maybe it’s a prime candidate.

Items that can’t be automated are still great candidates for inclusion into a workflow, because it builds accountability and helps with tracking. The workflow would simply trigger manual tasks in this case, but by requiring the person completing the task to mark the item done in the system and tracking that, it helps with the following:

• Identification of what equipment was provided (or collected back)
• Monitoring of Service Level Agreements (SLAs)
• Accountability – the individual is less likely to mark the task complete if it isn’t, since they know it could come back to haunt them.

Although out of scope of this series, consideration should be given to integrating IAM with the asset management system to help with tracking of equipment and licenses over time.

Non-employee management

There are two types of non-employees at most companies: those that are there for a limited time (such as temps, consultants, etc.) to provide specific expertise on a project or act in a staff augmentation capacity, and those that are there indefinitely, because they are some sort of business partner (supplier, outsourcer, vendor technical support, etc). As such, workflows must be designed to support both conditions.

Ultimately, non-employee management is a special-case user recertification, which is discussed below. It’s helpful to begin with non-employee management for two reasons:

• It’s a relatively small and simple sub-set of user recertification, so it’s a good place to start and get some experience
• It’s a valuable quick-win, since non-employees tend to be a significant blind spot because non-employees are typically not centrally managed in an HR-like system as employees are.

In fact, managing non-employees will be of value not only to the access services or security group because it provides better control over a group of users that is generally less trusted, but it will also be of value to other groups – like HR if they’re trying to reign in management of non-employees from a presence perspective, and finance if they’re having trouble determining when non-employees come and go (to ensure they’re being paid – or not – appropriately).

User/Access Recertification

Many companies still do user or access recertification by hand – generating and emailing unintelligible spreadsheets to business managers asking them if the people on the list still report to them and if the access on the list is still appropriate. Not only is the initial data collection and distribution arduous, but the effort increases dramatically when the managers come back with countless questions in their attempt to understand the access listed, or when their frustration with the process leads them to become unresponsive, requiring repeated follow-up.

Many IAM products offer automation for recertification, but not all solutions are equally elegant. The top systems offer a variety of benefits:

• Web-based view of individuals and their access
• Individuals have already been compared against HR to ensure that they’re current (and if vacancy management is already in place, then the HR records can be trusted and “user” recertification is no longer necessary)
• Access is presented in business terms, not as technical permissions, so that reviewers understand what they’re certifying
• Whatever changes are indicated by the reviewer automatically trigger automated or manual implementation tasks which are tracked to completion and logged for easy reporting
• Non-responsive reviewers are reminded automatically, and the line management hierarchy is used for automated escalations
• Reports for the auditors are easy to generate

Sounds great, doesn’t it? At a large company, this workflow set can easily save several FTEs worth of work for several months each year.

Approach

This month, we’ll discuss each workflow set in part, with three objectives in mind:

1. Identifying ways in which the workflow set could be developed. There aren’t any right answers here. The goal is to ensure that some thought has been put into what the right answer is for your specific situation
2. Populating the requirements list accordingly – this is where a lot of ROI can be found, if the right product is selected that can support the requirements. It’s critical to make sure that the requirements list is well-updated this month
3. Considering some prep-work that could be done in advance of obtaining a system.

We’ll begin in the next segment by working on the de/provisioning workflows.

Tokens, Shopping Carts and Security Awareness

What can grocery-shopping carts teach us about building security awareness that works to influence behavior change?

Turns out perhaps more than imagined.

During a recent hotel stay, I took a trip to a local grocery store to buy some snacks. I pulled into the lot, parked and headed to the store. Since I only needed a few items, I walked past the carts toward the entrance.

At the entrance a rather LARGE sign explained, “change machine for the carts inside store.”

Something about the sign encouraged me to stop; I needed to understand the need for change for a cart.

Turns out that the carts had a strapping mechanism that essentially tethered them together when stacked properly. Unlocking the cart required a quarter. When the cart was properly returned, the quarter was released and returned.

But a quarter is only $0.25

At first, this struck me as silly. Even in this economy, a quarter isn’t much and I thought it lacked the value to influence cart behavior. And it seemed like an inconvenience.

In the thick humid dusk of the evening, I took a few moments to look out and scan the parking lot. Not a loose cart in sight. So I looked harder and longer for a loose cart to prove someone bucked the trend and “just didn’t care.” Yet all of the carts were either in use or put away.

The token is engagement

Then it hit me: the quarter was only a token, a gesture. The money, in all reality, meant nothing. People put a quarter in, but they got it back. They weren’t renting the cart. At play was the physical act – the token – to connect individuals to the cart.

The token (the quarter) engaged people, connected them to the use of the cart and essentially redefined normal.

The use of a quarter to unlock and use the cart connected people to the process. Awareness of the condition to use the cart ensured people carried a quarter, sought change from the machine (inside the store) and served as subtle reminder to return the cart – if only to get their quarter back.

So how does this apply to security awareness and influencing behaviors?

With a different perspective, these carts taught me a lot about the value of engagement and commitment. By asking for a small value – which will be promptly returned, in full – the interaction changes.

The key here is the token.

It was more than symbolic – and it required some thought or action, but it was not onerous. I suspect shoppers at the store routinely had a quarter or two in their pockets, purses or cars… without complaint.

The low economic value of the token is important to the function. Engaging people in this way does require a shift in behavior (and the first shift is sometimes the hardest), but make it too complex or otherwise costly, and it will be summarily ignored or revolted against.

In the coming weeks and months, we will continue to explore parallels, amplify the good and advance our ability to address the human paradox, shift thinking and inspire behavior change through security awareness that works.

How are you using “tokens” in your efforts?  More importantly – how did you figure it out, how is it working and how is it evolving?

Share your experiences in the comments, engage me on twitter, send me an email or pick up the phone and call. I’d love to learn about the token in your efforts.

Ultimately, managing the vacancies is dependent on building three key hierarchies…

• Line management
• Data/access ownership
• Cost center ownership

…and building the hierarchies is best done using a five-step process:

1. Determine the needed granularity
2. Collect what data is already available
3. Obtain the data that is not available
4. Develop the workflows for filling a vacancy when it arises
5. Establish the notification processes/integration with other groups/systems that have a need to know

Clearly, this can be another round of fairly arduous cleanups, but once established, the identity management team will truly demonstrate value to the business. By helping key teams like HR and Finance solve a problem not directly related to access that has plagued them for years (although there are clear access implications).

As we continue in the series, we will focus on workflows as they pertain to provisioning and de-provisioning, user-recertification, and managing non-employees.

Populating the requirements list

In the course of designing workflows or notifications, some desired integration points may have been identified, for example, where identity manager should directly interface with certain target systems to carry out the notification function(s). If this is the case, be sure to note this on the requirements list, including relevant technical information about the target system (e.g., which protocols it can use).

How can I help?

Do you need some clarification or additional assistance? Do you have an experience to share with others? Leave a comment below so we can all improve together.

As with data and access ownership, cost center ownership is typically a minor component of someone’s job, so when they leave it’s not the first thing that comes to anyone’s mind.

Worse, although there could be more cost center owners than data/access owners (especially in large organizations), there are significantly fewer cost center users – many people in a company have systems access, but only a few people knowingly hit a cost center by buying things. So whereas a data/access owner vacancy is likely to be noticed fairly quickly, it could be months or more before a cost center owner vacancy is noticed – making it that much harder to figure out who the replacement should be.

This segment is about managing vacancies in the cost center ownership arena, to ensure that these vacancies are proactively managed, rather than reactively. We’ll again work through this hierarchy using the five steps I outlined in the Approach section of this month’s Introduction segment.

Step 1: Determine the needed granularity

As with our previous hierarchies, granularity speaks to ongoing management. A one-to-one mapping of cost center to role could result in thousands of roles at a large company, which is not sustainable in the long-term. So as with data/access owners, a middle ground needs to be struck. It’s less likely that a single role of “cost center owner” will suffice – some sub-division will likely be needed – perhaps on a functional or geographic level.

The finance team definitely needs to be involved in these discussions – they are the right ones to advise on the appropriate level of granularity.

I use the term “finance team” generically – it may be that there’s a different finance team for each functional or geographic unit.

Step 2: Collect available data

The finance team is also the group that will be able to provide any existing cost center ownership data.

Step 3: Obtain missing data

In some ways, determining missing cost center owners may be more challenging than obtaining the line management hierarchy. In the latter case, the difficulty comes from the sheer number of people involved. With cost center owners, the difficulty is figuring out where to look. How do you equate a number with a person?

You first have to understand what that number means before you can even begin determining the person.

Just as it should be HR’s responsibility to fill out the line management hierarchy, it should be the finance team’s responsibility to fill out the cost center hierarchy.

However, unlike HR, the finance team will be much less familiar with the employee population, so they will need a lot more help getting from number to person. In fact, the HR team may be needed to help bridge the gap, although if the line management hierarchy is already complete, it’ll be a lot easier.

Step 4: Design the workflow

The cost center ownership workflow design principles are the same as those for the data/access ownership workflow:

• Determine if the person authorized to fill a vacancy is a line manager or a finance manager
• If the authorized person is a finance manager, determine the course of action for upward vacancies
• Specify the default action if an approval is pending and a vacancy hasn’t been filled.

Step 5: Notification

The group most likely to require notification on cost center ownership is finance, although as mentioned previously there could be many finance groups across a large company. HR may also have a need for this information.

As with the other hierarchies, email notification is a cheap and simple solution for notification, but you get what you pay for – there’s no guarantee that the updates will be made. A better solution is again a closed-loop task at the end of the workflow, although finance people are typically so far removed from IT and identity management that receiving and completing tasks from an identity management system may not be well-received.

Updating the finance system automatically may be possible if an integration is already planned between the finance system and identity management. Otherwise, automation could be costly. If HR needs to be updated, that should be possible since HR and identity management must be integrated anyway. If HR and the finance system are integrated, it may be possible to auto-update the finance system indirectly via the HR system.

In the next segment, we’ll summarize the month’s activities and wrap up.

Properly managing data and access ownership is important not only from a compliance perspective – ensuring that the right people are approving access to data at any given time – but also from a customer service perspective. It doesn’t do the company any good to have people not being able to do their job because their access request has stagnated, nor does it do anything for the reputation of the access services team. Although it’s not the access services team’s fault that the vacancy didn’t get reported, they will bear the brunt of the complaints and blame.

The good news is that there aren’t that many data/access owners in the enterprise, relatively speaking. It’s really a small percentage of the total body of users. So then why has it been so difficult to manage historically?

Data and access ownership are typically minor components of someone’s job, so when they leave it’s not the first thing that comes to anyone’s mind – “Oh! Johnny left the company and he was the approver for ad-hoc batch job access – he approved 3-5 requests per month. We need to make sure to assign a replacement for that!”

Typically, this is discovered when an irate employee wonders why his request has been sitting around for three weeks with no action. Then it’s a scramble to figure out who should decide who Johnny’s replacement should be.

This segment is about managing vacancies in the data/access ownership arena, to ensure that these vacancies are proactively managed, rather than reactively. We’ll again work through this hierarchy using the five steps I outlined in the Approach section of this month’s Introduction segment.

Step 1: Determine the needed granularity

As with the line management hierarchy, granularity speaks to ongoing management. If your service catalog has hundreds of services, each with its own approver (that is not the requestor’s line manager), it would take hundreds of entries in role manager to account for every last approval role. This becomes difficult to manage.

If there is a centralized service catalog with workflows that auto-route requests to the right approvers, the good news is that there is an easy way to determine which individuals approve what access – just ask the service catalog administrator.

So it may be sufficient to create one role, “data owner” or “access approver.” Or, if the catalog is big enough, maybe narrow it down and create one role per category, such as “UNIX access approver,” “Windows access approver,” “Database access approver,” and so on.

Step 2: Collect available data

Again, if there is a centralized service catalog system, the data (who approves what) should be fairly easy to collect. Even in the absence of a system, it’s likely that the access services team at least maintains some good spreadsheets – otherwise your organization has much bigger issues that managing vacancies.

Step 3: Obtain missing data

Even if Step 2 yields good, comprehensive results, there’s still one thing missing: the roles of the individuals who should fill the vacancies, and this is not a trivial analysis to undertake.

If Johnny leaves the company, should it be his line manager that decides who takes on his approver role, or should it be someone else, like the owner of the system that runs the ad-hoc batch jobs that Johnny was approving?

It’s important to ensure that the information collected on filling vacancies matches with the roles created previously. If there’s only one role defined (e.g., “access approver”), the vacancy has to be filled by the line manager, because there isn’t enough information to determine a system manager. If the roles are set up by category, then it might be possible to deduce who the system manager is based on roles.

Another missing component here might be missing approvers – it’s possible that the approver spreadsheets or service catalog records contain approvers who no longer exist and have already left vacancies. These need to be filled as part of the data gathering process.

Step 4: Design the workflow

The first step of the workflow depends on the granularity of the approval role. If there is only one role, then the workflow is done – use the line manager workflow.

If there are a handful of generic roles, the first step in the workflow will be a task to the service catalog administrator or access services team to identify what approvals the individual performed. Then a task can be routed to the person authorized to specify a replacement.

If each ownership type has its own role, then the workflow can route a task directly to the role identified as having authority to specify a replacement.

The latter two scenarios lead us to the second possibly tricky part of the workflow: let’s say that the system manager is asked to replace Johnny, but the system manager role is also vacant. Does the request go to the system manager’s line manager, or to someone else?

Whereas the reports-to hierarchy presented problems with data collection, but the workflow creation was straightforward, the opposite can be expected for data/access ownership. There aren’t *that* many data owners/access approvers in any organization, so getting the list won’t be that difficult. But getting agreement on who is authorized to fill vacancies and how the workflow handles additional upward vacancies can take a while – it will involve potentially different people for each role, and possibly significant discussion.

Part of the discussion also needs to include default actions – how does a pending approval get routed if the vacancy has not yet been resolved?

Step 5: Notification

The two groups most in need of data/access ownership changes are the access services team and the service catalog administrators.

Since the number of changes is relatively small (as compared with reports-to) and since the number of recipients is also fairly small, sending email notifications is more reasonable in this situation, but still not ideal.

As with the reports-to workflow, the better solution is to create an additional step in the data/access ownership workflow, assigning a task to the two groups, requiring them to update their respective information.

The best solution, of course, is still system integration, which again may be fairly simple and inexpensive if the approval information is already stored in an LDAP-compatible repository. Since identity management can easily integrate with such a repository, automated update would be highly achievable. If the data is stored in spreadsheets or if the service catalog repository is proprietary, automation is likely not possible (or cost prohibitive).

In the next segment, we’ll develop the cost center ownership hierarchy and workflow.

We’ll work through this hierarchy using the five steps outlined in the Approach to this month’s Introduction segment.

Step 1: Determine the needed granularity

Granularity speaks to ongoing management – the more layers of management that are collected, the more complex the setup will be in role manager, the more complex the workflows will be, and thus maintenance over time will be more involved.

It is extemely important to think carefully about granularity at the beginning. Think in terms of what needs to be done, not what can be done. Anything can be done, but is it worth it?

For example, many large companies have a team lead or supervisor type position. This is a good thing – it gives employees the ability to take on more lead/management roles in a relatively safe and protected way. But do these individuals need to be part of the reports-to hierarchy?

Maybe, maybe not.

If they ever approve anything (access, equipment, vacations, travel, training, etc.) or even write and deliver performance appraisals, then yes, they do need to be part of the hierarchy. If they only recommend approval or contribute to the performance appraisal but it’s a manager or higher that has ownership of these things, then the team lead/supervisor level is not needed as part of the reports-to hierarchy.

Selecting the right level of granularity up-front is essential – not trivial. The decisions should also not be made by the identity management team in a vacuum.

The identity management team has the opportunity here to really add value to the organization. I mentioned before that some HR systems only store management data at the director level and higher. That doesn’t mean that HR wouldn’t love to have management info at lower levels, but if their system doesn’t support it, it makes it much harder for them to acquire and maintain the data. The identity management enterprise can pick up where the HR system leaves off, providing much-needed information to the HR team, and building a lot of good will.

There may be other organizations that have a need for up-to-date reports-to information that should also be a part of this design process.

Step 2: Collect available data

Now for the reality check: ask HR for whatever reports-to data they may have, and get an understanding from them of the condition of the data. Is it kept meticulously current, or is it only as accurate as it was during the last salary increase cycle that happened nine months ago?

Step 3: Obtain missing data

Hopefully, HR keeps meticulous reports-to data and little if anything is missing. If that’s the case, buy the entire department flowers or take them to a nice dinner – they’ve just saved you a ton of work.

If that’s not the case, let the grunt-work begin.

There’s no easy way to obtain this information, which is why many large organizations covet the data yet can’t keep it current.

Certainly, getting the most current data should lie with HR, and they do have to get the information current (to a certain level, which might not be the desired level) at the next pay cycle. So worst case, wait it out. Theoretically, HR will be motivated to help with an off-cycle cleanup of management data in anticipation of getting help in maintaining the data going forward – help them envision a world when they never have to do a reports-to cleanup again – it’s a powerful motivator!

HR should take the lead on this – due in no small part to the fact that they have representatives in most or all locations who possibly know much of their employee population by name if not by sight. At a minimum, they should know all of the managers in their area, and can collect the names of individuals that report to each. In fact, you may find that some of the local HR reps keep this information for their own people, even if it doesn’t make it up to a more centralized location.

Administrative assistants might also be helpful in this arena – they too may collect and maintain some sort of organization chart for their department.

Of course, it’s not a good idea to just dump this activity on HR – the identity management team should do their best to be supportive, whether that means making some phone calls to collect names, or offering up the team’s script writer to help expedite the data collection process.

Step 4: Design the workflow

The line managerment workflow is the most straightforward of the workflows – basically, the request to fill a vacancy goes up to the next person in the hierarchy. If that person is also missing, it goes to the next person, and the next, until someone is found (or it reaches the CEO). The complexity is in connecting roles to people (e.g., Suzy Smith is the Manager of UNIX Engineering; John Doe is the Manager of UNIX Operations). There should also be a default set that until the vacancy is filled; for example, “any approvals that are needed get automatically routed to the next higher person in the hierarchy.”

The only tricky part here is keeping up with the constant stream of reorganizations that seem to plague most companies. This can either be handled on an as-they-happen basis, or via a periodic verification process. For example, consider a quarterly or semi-annual workflow – which could also be run ad-hoc if needed – that sends each manager (manager in the generic sense meaning someone who manages people, not a specific level of the organization) a listing of their direct reports for review. As part of the workflow, the manager should be able to not only confirm if each individual still reports to them, but they can also select the name of a different manager for individuals who may have moved to another team.

The reports-to hierarchy and workflows should also apply to non-employees. As long as the non-employee’s manager is recorded at the time that they are first entered into the identity management system, they can be included in the periodic verification process, and they would be covered in the vacancy management process.

Step 5: Notification

At a minimum, the people that expressed an interest in the reports-to hierarchy (i.e., the people that participated in Step 1) should receive an email notification any time any changes occur. However, for something as fluid as reports-to hierarchies, sending emails is likely not sufficient because there’s no guarantee that the recipient receives or acts on the email.

A better solution is to create an additional step in the workflow, which is assigning a task to the right people to make the changes wherever they need to do that. The act of making the update is still a manual task that someone has to perform, but by requiring them to mark a task done on a system the task is more likely to actually get done – or if it doesn’t, it will be easy to see by the growing queue of incomplete tasks.

The best solution, of course, is system integration. This ensures that any needed updates are made automatically, without human intervention. The cost of building and maintaining such an integration may or may not be worth it – that’s up to the organization to decide, based on the value they place on having accurate and timely reports-to data. To some degree, though, automation should be fairly simple, if the system being updated is the HR system since the HR system will be integrated with identity management anyway.

In the next segment, we’ll develop the data/access ownership hierarchy and workflow.

What is vacancy management?

Vacancy management is identifying and proactively handling the vacancies created when people change positions/roles within the organization or leave altogether.

How many times has an access request or purchase order stagnated without approval because the approver left the company and a replacement wasn’t identified? In a large organization this is a daily occurrence. Vacancy management can proactively prevent this problem.

This is a challenge because vacancies are out of scope of the general HR focus on managing payroll.  From an HR perspective, a vacant role requires no salary and no further consideration. But from an approval perspective, someone needs to be in the role – even if it’s a temporary someone until the role is officially re-filled.

That is the power of vacancy management: vacant roles are proactively identified and workflows are triggered a workflow to solicit a replacement. Easy, right? Of course not!

As usual, there are a few gotchas, including setting up the approval hierarchies to begin with, and then defining the workflows for the actual vacancy management.

Hierarchies

There are three hierarchies that influence vacancy management:

• Line management (i.e., the chain of command: individual contributor reports to team lead reports to manager reports to director reports to VP reports to CXO reports to CEO)
• Data/access ownership (e.g., the UNIX engineering manager approves root access)
• Cost center ownership

The first hierarchy – line management – may seem like it’s something that would be available from the HR system, but it may not be. This is a discussion that should be had with the HR team. Some HR systems only store management information at the director/cost center owner level or higher, which may not provide the needed granularity. Also, the HR system may not be updated with reports-to information very often. Some companies only do it if there’s a major re-organization or when annual salary increases need to be assigned.

Data and access ownership information is strictly an identify management construct, and hopefully some decent information is already available in this area – it has to be if access is already being granted and audited. However, that information may need some “massaging” – for example, are approvers documented by name or role?

We already touched briefly on cost center ownership last month by saying that it may not make sense to create a role for every cost center. In a large organization there can be literally thousands of cost centers, and they change all the time for reasons that only the finance people could ever explain.

Some decisions will need to be made on what level of granularity is appropriate for this hierarchy – this is also true for data and access ownership.

Workflows

Once each of the hierarchies has been determined, workflows need to be developed to handle a vacancy when it occurs. The following questions need to be answered:

• Who does the workflow go to?
• What if the recipient of the workflow is also a vacant role?
• Are there default actions that can be taken and/or can any of the information be obtained in an automated fashion (e.g., from HR)?
• Once the workflow is completed and the vacancy has been filled, does anyone/any system need to be notified?

Each vacancy management workflow should be designed to handle any vacancy situation to ensure that it ends in success. This means being able to handle multiple tiers of vacancy (i.e., keep going up the food chain until someone is found), and also establishing some default actions that the system can take to either minimize the human interaction or augment it. It should be noted that the intended scope here is to address permanent vacancies – those created by job changes and termination – not temporary vacancies created by leaves of absence or vacations. It’s actually a little harder to deal with the latter – it’s important get the permanent vacancies right, and then tackle the temporary ones, if desired.

The final step in the workflow – notification – closes the loop on the entire process. Although role manager and identity manager can facilitate identifying a new person to fill a vacancy, neither system has any particular use for this information. The information is actually only relevant to other groups or systems – for example, the finance managers and/or the finance system would need to know about a new cost center owner; the access services team or access provisioning workflows would need to know about a new data owner.

Notification can be as simple as an email confirmation, as efficient as a task issued by identity manager that must be marked completed (to ensure a closed loop), or as complex as a system integration to fully automate the update process.

Approach

This month, we’ll develop each hierarchy using these 5 steps:

1. Determine the needed granularity
2. Collect what data is already available
3. Obtain the data that is not available
4. Develop the workflows for filling a vacancy when it arises
5. Establish the notification processes/integration with other groups/systems that have a need to know

We’ll begin in the next segment by working on the reports-to hierarchy and workflows.

Your paradigm is so intrinsic to your mental process that you are hardly aware of its existence, until you try to communicate with someone with a different paradigm. ~ Donella Meadows

Considering the meaning, purpose and expression of security awareness is a personal and professional pursuit. In fact, it’s my sole focus and the reason I created the security  Awareness that Works™ system.

As a result, I regularly discuss successful security awareness programs, and I start most discussions with a simple question, “what does it mean to be aware?”

The range of answers – from blank stares and silence on the phone to lengthy lectures – have little to do with awareness. In fact, I had one executive suggest to me that trying to define awareness was akin to US Supreme Court Justice Potter Stewart attempting to define pornography when he wrote, “… I know it when I see it…”

I disagree.

And here is the challenge: without a clear understanding and functional definition of security awareness, it is impossible to obtain (for ourselves, let alone to influence the awareness of others). Worse, this means there is no vision, guidance or purpose to awareness that is easily understood; awareness becomes a burden to fund instead of an opportunity to invest.

Good news – it doesn’t have to be this way.

If the goal is to shape the culture and increase “awareness,” it is essential to understand what awareness is, what it can do, and how to recognize when people are, in fact, aware.

How do others define awareness?

Awareness is not a new concept. Here are three definitions that share common threads, easily applied to the challenge of generating awareness with regards to security and risk:

• Wikipedia defines awareness as: the state or ability to perceive, to feel, or to be conscious of events, objects or sensory patterns. In this level of consciousness, sense data can be confirmed by an observer without necessarily implying understanding. More broadly, it is the state or quality of being aware of something. In biological psychology, awareness is defined as a human’s or an animal’s perception and cognitive reaction to a condition or event.
• Awareness is also defined in personal injury claims: Conscious of stimulation, arising from within or from outside the person.
• Marketing is keen on awareness: a measure of respondents’ knowledge of an object or an idea. There are two main measures of awareness: spontaneous (or unaided) and prompted (or aided) awareness.

The common threads with these and other definitions are a sense of individual, recognition of actions and a measurable component related to some sort of message. Also consistent is the notion that awareness can be spontaneous and internal, or external to the person and aided.

These definitions prove a good starting point for considering what it means to be aware. But we also have to consider the underlying challenge individuals and organizations must solve: the human paradox (for more see: Why people are not the problem…).

How The Human Paradox impacts Awareness

When it comes to managing risk, information and the relationships with people, the real challenge is The Human Paradox: individuals have been systematically (albeit unintentionally) disconnected from the consequences of their actions. This results in a challenge where people no longer take responsibility and are nearly impossible to hold accountable.

The human paradox has an interesting impact on awareness: the more disconnected people are from the consequences, the more complicated – and costly – the effort to reconnect them.

This is why traditional “security awareness training” falls short: failure to address the human paradox. In some cases, these programs may actually increase the gap between individuals and consequences, creating more risk, increasing complexity and wasting money.

Security Awareness, Defined

For awareness efforts to be successful, we have to start with a clear definition. After considering awareness and the impact of the human paradox, I propose a short, clean and simple definition for awareness:

Awareness: an individual’s realization of the consequences of his or her actions (or decision).

When Awareness that Worksâ„¢ is obtained, the definition is enhanced by the ability to assess the impact of the consequences. Soon I will explain why we absolutely must reconsider consequences.

This definition of awareness actually shifts the purpose of the program. By improving the vision of awareness (we have more work to do there), the potential for training and other resources to provide measureable return is clearer.

Of course, there is more to consider: how to define the program, generate awareness, measure what matters and communicate what counts. But sometimes the simple shift of a definition and proper use of a concept is the spark that brings change.

So what does awareness mean to you?

Do not put your faith in what statistics say until you have carefully considered what they do not say.  ~William W. Watt

Over the last few years, we have been presented a series of reports, complete with statistics, suggesting the cause of security breaches is people. Whether external attackers taking advantage of individuals, insider mistakes or even insider espionage, the overly simple and false conclusion seems to be that people are the problem.

Well, they aren’t. Except, of course, they are.

When I wrote Into the Breach, I realized early in the process that “breach” (no matter how it is defined) is a symptom. So focusing on preventing security breaches basically creates a losing situation where valuable time, money and other resources are wasted… only to leave the real challenge untouched.

The real challenge is what I dubbed the human paradox: individuals have been systematically (albeit unintentionally) disconnected from the consequences of their actions. This results in a challenge where people no longer take responsibility and are nearly impossible to hold accountable.

If people aren’t the problem, what is?

When introducing the concept of the human paradox in the book, I suggested we face a people problem. Upon further research and considerations, I would write that section differently: we face a human paradox where people are not the problem.

Consider this: “people have been unintentionally and systematically disconnected”

This raises the question, “who disconnected people from the consequences of their actions?”

Short answer: we did. But it wasn’t intentional.

I liken the current experience described by practitioners as  “security pain” to what new parents learn as “short term gain, long term pain” – or the idea that actions designed to quickly diffuse a situation often create more complicated problems down the road. Basically, the actions taken over the last decade for short-term gain have disconnected people from the consequences of their actions – creating the current pain we feel.

The rapid pace of change in technology and security over the last decade or so makes it more difficult for professionals to keep up with solutions and potential consequences. Even more complicated, then, is breaking down the range of outcomes and explaining them in a way someone else (without the same background and understanding) could easily understand.

When users rightly questioned changes, the path of “short term gain” was to suggest they wouldn’t understand and take the decision – and resulting consequences – out of their hands.

But it’s okay.

It’s part of human nature.

This means that instead of blaming “users” generically for not knowing and not being good enough, we should first look in the mirror. We played a role in making the situation we lament.

So we recognize it and move on.

The question is what comes next. And that’s where I have focused my passion, blended with my experience and skill as a human ecologist, in security and in the tradecraft of effective communication.

The Path Forward

The answer lies in connecting people to the consequences of their actions; it means we have to bridge the gap. But it’s easier – and more complicated – that just inflicting pain and punishing bad decisions.

So – tell them the consequences and we’re all set, right?

Well, it’s not that easy.

We need to change the way we think, change the way we act and work to cultivate a new culture to address how we manage risk, information and the relationships with the people we serve.

We need more deliberate dialogue: conversation with a purpose that “meets people where they are” and works in a way that allows everyone to learn. When we enter the conversation as equals, each with a valid set of experiences – and a desire to reach common understanding, something magical happens.

Best part: no new investment in technology is needed. This costs time. It requires being present. For some, this is simple, easy and obvious. For others, this is a challenge and will be a rough start.

We have a lot of work to do. I’m here to contribute and lead the change we need.

The moment we judge someone, we forfeit the ability to help.

Seems like a lot of what is being promulgated in so-called “security awareness” today is nothing short of berating people with a list of the things they shouldn’t do, coupled with a non-intuitive list of what they should do.

I read a lot of suggestions to “call people out” and “catch them doing the wrong thing.” For obvious reasons, I’m not going to link to any of these articles, columns and blog posts. My experience and success in changing behaviors suggest a different approach is more effective.

Why the need to embarrass others?

The reason so many focus on lecturing and berating stems from the misguided belief that we know better, know more than other people and will grace them with our wisdom.

Memo

From: the users

To: the security people

RE: get over yourself

Businesses existed without you before, and while perhaps not in the future, we can do better. So can you. Start sharing with us and stop trying to embarrass us and make us feel stupid. Teach us what you know – but in our words – and we will work alongside you.

My practice delivers “Awareness that Works™” – where awareness serves as the catalyst for effective training. I enjoy several conversations a day – and welcome more – on the topics of awareness, training and the broader issues of rethinking how it all works in the organization to go beyond “security awareness” by building a system that cultivates a culture of optimization.

Awareness is generated, not prescribed

In the process of sharing Awareness that Works™, I recently sent a note to a person I met while keynoting a conference. Our dinner discussion suggested to me that he “got it;” that he understood the purpose of awareness and the vital role it played in the organization.

But his reply to my note blew me away: he had no interest in discussing awareness because he simply told people what awareness was, told them what to do and told them how to do it. He saw no need for awareness or training, and no desire to discuss it.

Wow.

How would you like to be the user in that session? Actually, how would you like to be a security practitioner in that organization?

Either way, I suspect the point is lost on that chap and those he is supposed to serve. And that’s too bad for everyone.

In my consulting practice, I ask people about their experiences and what they expect. Turns out people are pretty clever: they do brilliant things; they know they need to change (and are willing to) and have reasonable expectations of you and the organization.

So why the disconnect?

A misguided belief that we know more, are smarter and that users are unable to get it right contributes to the disconnection and failure of “traditional security awareness.”

I’ve read where others suggest inane things like “there is no patch for stupid” and that we need to inflict pain on people in order for them to understand. And then I watch other security practitioners applaud and cheer. Step back and watch it through another lens and perhaps you’ll be as appalled as you should be.

We don’t know better, we just have a difference experience.

In the course of practicing “security,” we literally spend hours a day steeped in risk, understanding actions and trying to successfully solve problems.

But we also make mistakes. Lots of them.

Ever over-hardened a machine (to the point where it is a brick), blown a patch and screwed up configurations, backups and the like?

Spend a night in a data center correcting your own mistakes and things start to look different. As a result, we have cultivated a different language, experience base and set of expectations.

We may have started on a more equal footing in terms of experience, but the nature of our profession changes us. Sometimes, however, that change is a bit harder to see, and even more challenging to consider in context.

But we have hope.

The people we serve are willing to make a change, if and when needed. But they want to be made aware of the consequences of their actions in their words, in their experience and on their turf.

No one likes to be embarrassed or talked down to – and that has to stop. Now!

In the end, we’re all the same. We have an opportunity to all work together. We need to reconsider what awareness means, consider the perspective of our users and work to share and educate, but not embarrass.

Stick with me and I’ll show you how.

This series, underwritten by Configuresoft, now part of EMC, is the full and unabridged audio version of Into the Breach, written by Michael Santarcangelo and read by the author.

What you’ll find in this episode (Chapter 12)

This chapter addresses the challenge of changing first in order to lead and influence change. The concepts introduced and explained in Into the Breach – the Strategy to Protect Information, The Catalyst Method™ (recently updated) and others – produce rapid and lasting results for those who embrace them and implement them in their organizations.

Michael shares two basic analogies to consider while summoning the courage to break from tradition and take action: the process of building a flywheel and reconsidering Newton in a new light.

Into the Breach provides a wealth of ideas and information. The Awareness that Works™ system is the implementation of the guide from the book – and more. Contact Michael today to learn more and explore the guaranteed results.

Put the power of Into the Breach to work for you…

After listening to this segment of Into the Breach, keep the energy going and support the shift in thinking and inspire behavior change by

1. Engage with Michael on twitter (http://twitter.com/catalyst) (and he’ll engage back with you)
2. Subscribe to The Security Catalyst podcast & blog to get more insights; ask a question and get an answer!
3. 3. Check out Awareness that Works™ – Michael Santarcangelo’s program to guide smart investment in people, with guaranteed results (this program pays for itself).

In either case, the process is the same.

Implementation

There are two parts to implementing the new access for all applicable role members:

1. applying the new access (it’s sometimes easier to just delete what’s there and start over rather than trying to compare as-is vs. to-be and adjust), and
2. removing any extraneous access.

Care should be taken here – is that extraneous access indicative of another role, or just a relic from a past job function? Hopefully these situations have already been caught, but it might be useful to develop a process to handle issues like this – to ensure consistency and quality despite the 11^th hour discovery. But it’s very important to do something about the extraneous access – if it really is just a relic, revoke it!

Before making any access changes, it is critical to clearly communicate with impacted users – let them know when the changes are going to be made, and whom to contact for help if anything goes wrong. Also be sure to pick a time that is convenient to the users (the week before year-end close activities is not a good time).

Setting up for future access requests

Applying role- and rule-basing to a group of people may change the way they request access in the future. Be sure to make the necessary changes to access request processes, and communicate this information clearly to the users.

The best approach is to post information about the changes in the same place where users request access. This is especially important when implementing IT roles only, and not full enterprise roles. The more clear the end-users are on what they need to request and what will come to them automagically, the better it will be for them in terms of satisfaction, and for the access services team in terms of workload.

Role and rule maintenance

Although roles will not change as frequently as the users who need them, they will change over time. At a minimum, a process should be put in place to review each role once per year or more often if something major happens, like a significant organizational change or a replacement or upgrade of a system. This is something that should be specified in the access control policy or standard. Ownership of this process should fall on the information security department, on a senior access administrator or (better yet) a role engineer. It’s also a good idea to maintain a network of business liaisons in each department that can alert the process owner if a change is needed off-cycle. Depending on the bandwidth of the people involved, this could be done all at once as a yearly effort, or a few at a time as part of a perpetual calendar.

Cleanup of obsolete permissions

When all of the IT roles and rules have been defined for all enterprise roles needing to use a particular system, there may be some leftover permissions that aren’t assigned to any individual or any role. It’s a good idea to remove those.

Extra credit (and waaaayyy out of scope)

One of the reasons why systems with really granular permissions end up with such a huge repository of permissions and groups is that new permissions and groups are created without any analysis of what’s already there.

To really do this right (time permitting, of course – yeah right!) the permissions assigned to each IT role should be analyzed for redundancy or excessive access and adjusted accordingly. Whether or not this is worth the time and effort will again depend on your specific circumstances, but if it’s a system that attracts audit and no one seems to know how the permissions work or what exactly they give, it’s a good idea. Also, if you’ve got mainframe users who require two or three IDs because their permissions won’t all fit on a single ID (I’ve seen this!), it’s definitely a good idea.

Action recap

This month’s exercise was to begin role- and rule-basing the organization to facilitate access request and granting:

• Prioritize departments and identify enterprise roles in the target departments
• Develop a strategy for designing IT roles (depth vs. breadth), and get to the to-be from the as-is, with help from the power users; remember to test each role thoroughly
• Clearly document and obtain proper approvals for implementing the roles
• Implement the roles carefully, ensuring proper communication with the affected users. Also set up processes for maintaining the roles going forward, and adjust request processes as needed.
• Remove any leftover permissions that are not in use.

Next month, we’ll talk about hierarchies of information, and rules for maintaining those hierarchies.

How can I help?

Do you need some clarification or additional assistance? Do you have an experience to share with others? Leave a comment below so we can all improve together.

Documentation and approval

Once testing is complete, the final roles should be clearly documented. This defines which permissions apply to which IT roles, and which IT roles apply to which enterprise roles. It is important to make sure the documentation is clear and detailed, leaving no question as to what is or isn’t included in a given role, all the way down to the granular permission level. Documenting roles in visual ways such as matrices is encouraged. In the case of rules, consider documenting the decision process as a flowchart.

Initially, roles may be captured in a spreadsheet, but that spreadsheet may quickly get very large and unwieldy. In the absence of a role management system, consider setting up a simple database to store the information.

This is where normalization becomes important.

It’s best to define IT roles as the lowest common denominator, and build out from there. For example, there might be two levels of accounts payable clerk – junior and senior. The junior level gets the basic access needed for that job function. The senior level gets the junior access plus some extra. This reduces role maintenance over time because if there is a change in the basic level access permissions, it only has to be changed in one role instead of two. This also explains why some enterprise roles will have more than one IT role on a given system.

When the documentation is complete, it is important to circle back and get approval of the roles from the appropriate parties – the department head(s) and/or the system owner(s). Consider this part of the running dialogue and relationship building that is essential to success of this process. This can be used as pre-approval when applying the access to new users in the future – since the access was already approved for the job function, as long as the correct role(s) are applied to the user, re-approval from the department head or system owner for each individual user’s request is not needed, shortening the delivery time for obtaining access, and also saving approvers time ongoing. Conveniently, this practice is also acceptable to auditors.

In the final segment, we’ll wrap up the month’s activity with implementing the roles and doing a cleanup of extraneous access.

Developing a Strategy: Depth vs. Breadth

As with enterprise roles (and departments, for that matter), IT roles may require some prioritization, because:

Each enterprise role can have many (possibly dozens) of IT roles.

This means there are a LOT of roles to define, document, test and implement, which raises an important question: is it better to spend a lot of time on each enterprise role, identifying it end-to-end before moving on (depth), or is it better to tackle the priority IT roles in each enterprise role, and touch each enterprise role multiple times (breadth)?

There is no right or wrong answer to this question and in fact the answer could be different for different enterprise roles.

The strategy is ultimately driven by whatever is going on in the organization – such as complaints that the access services team is taking too long to grant access (or making too many mistakes), an impending audit, or a process improvement project. It also makes sense to use this opportunity to successfully address a current challenge to curry favor for subsequent steps.

The argument for breadth is security – go for the sensitive/complex access first across all systems to stop the need for copying access and reduce or eliminate the mistakes when implementing access. Many companies employ a “model ID” system: “Jane needs the same access as John.” This is dangerous if John actually has more (or different) access than Jane needs – it’s bad for security. Interestingly, it can also be bad for customer service if John’s access doesn’t give Jane everything she needs.

The argument for depth is customer service – fill out each enterprise role in its entirety before rolling it out to the end-users to avoid confusion. This isn’t about implementing the roles – it’s about end-users requesting them. If each enterprise role is only partially filled out with its IT roles, the communication to the end-user might look something like this: “Going forward, you no longer need to request access for email, internet, shared folders, and UNIX applications because these are now included in your role. But you do need to request access for mainframe and Windows applications.” How many users will understand this?? None! So either they will not submit the correct individual requests, leading to missing access, or they submit requests that they didn’t need to submit, causing duplication of work for the access services team. In this case, not only has the workload for the access services team not been alleviated, but it’s caused a customer service nightmare, too.

In a perfect situation, each enterprise role is fully fleshed out with all of its IT roles, enabling a one-time cutover of all users in that role with flawless communications and an easy transition to the new process for requests. More often, however, the situation will be a bit less “perfect” and require a stepped or phased approach. The more planned, mapped, and understood the process, the more effective the communication and the less friction experienced in the process.

Once the strategy is mapped out and commitment to communication made, it’s time to begin defining roles.

Discovery: as-is access

The first step in defining IT role(s) is determining the as-is permissions for the members.

For any given system, obtain a report that specifies what each user in a particular enterprise role has. Theoretically, all users in the same enterprise role should have the exact same access on any given system. Practically, they probably don’t. Newer users may have less access than they should, while users that have been around for a long time may have accumulated a bunch of permissions that they should no longer have.

It’s also important to verify the enterprise role at this stage – if the group of users that should have had the same access seem to have two different groupings of permissions, maybe the original assumption was wrong and the users should actually belong to two different enterprise roles. Validate this with the department head – not by just saying that some users have different access, but by naming names: “John and Mary have these extra three permissions that the rest of the team doesn’t have. Do they do something special/different that the others don’t do as part of their job, or is this access a relic because they both held the same prior job?” Whereas a department head may not think anything of the extra permissions, if they’re put in the context of the specific team members, it will resonate, and they should be able to say exactly why that access exists. If the users do perform an additional job function, an extra enterprise role should be added to the list – this is where normalizing is helpful (e.g., finance analyst, senior finance analyst). If the users don’t perform any additional job functions, be sure that that access is removed from their accounts – more on this in part 4.

The discovery process is a great place to engage someone with scripting skills. There’s nothing worse than collating and analyzing data by hand, or trying to run manual reports. A decent scripter can significantly decrease the discovery workload, and it’s likely that the effort put into creating the scripts will come in handy later as well – when the identity management system needs to be trained how to obtain the same data.

Design: to-be access

The next step is to identify what permissions the given group of users *should* have. For some systems, this is very simple. Take internet access for example – either it’s allowed, or it’s not. Email might have a couple tiers, like standard access and executive access (with more mailbox space). A lot of systems have a small number of canned permissions that can’t be modified, like read only, update, and administrator. When these types of systems come up, rejoice in the ease of defining the IT roles.

Then there are the systems with a TON of permissions – relational databases and mainframes are notorious for this. This is where that power user will really come in handy – they hopefully know how permissions map to access, or at least they know enough about the system that they can help with the business side of that mapping if they get some help with the permissions side from an access administrator.

Coming up with the right IT roles on these systems can take much iteration. Remember to begin with the as-is access and eliminate from there, rather than trying to build the roles from scratch (although some people’s access may be so bad that a full rebuild is necessary).

There’s also another element here: level of detail.

Some IT roles will not be permissions, per se. Rather, they will be an indication of ownership – like “cost center manager” or “xyz data owner.” In cases like these, smart design decisions need to be made to ensure that the number of roles does not explode.

For example, a large organization may have literally thousands of cost centers, and they change all the time for administrative reasons that only the finance people can explain. Having a separate IT role for each cost center would be a maintenance nightmare, but having just a single role called “cost center manager” is too high-level. In this case, the right middle ground needs to be determined – maybe each department, business unit, or division has its own separate role. But such a middle ground will require some workflow design to get additional information on-the-fly when it’s needed. We’ll talk about this more next month when we talk about hierarchies and vacancy management.

Testing

In the previous article, I mentioned that department heads can get very uncomfortable about changing an entire team’s access, for fear of interrupting business function. In addition to building a good relationship with them, another way to alleviate those fears is by thoroughly testing the new IT roles with one or two users (in a test environment if possible) prior to rolling out the changes to the entire team.

This might seem obvious, but it can actually be pretty challenging to get someone to remember what all they do on a system at any given time. Special care needs to be taken when working with users that have periodic tasks – ones that only occur monthly, quarterly, semi-annually, or annually. Typically, periodic tasks are time-sensitive and critical to the organization (e.g., finance people who have to “close the books” on time) – that is not a good time for a user to find out that they no longer have the right access to do their job.

Non-access roles

Remember that roles and rules can apply to non-access items as well – like equipment and facilities. Although provisioning of these things will never be automated, having a quick and easy reference for the people that provide these services will make their jobs easier and allow them to provide better customer service. Consider defining IT roles for computer hardware, computer software, communication devices (phones, pagers, etc.), facilities (cube vs. office), badge access, and so on.

Other resistance

When designing enterprise roles, everyone is willing to play along because it’s very esoteric. No one thinks twice about categorizing who does what. In fact, other groups may find their own uses for the information, since you’re putting all the time and effort into gathering it for them anyway.

When designing IT roles, unless the access management function is already highly centralized, some (possibly significant) resistance may be encountered – mostly by the people who administer the access today. If they are completely buried in work, the thought of automating some of it will be welcomed. If granting access is all they do, they will likely interpret the automation of their job as a pending pink slip for them. Of course they won’t put it this way, but when you hear, “my application can’t be role-based – there are too many special circumstances that need analysis” or simply, “automation won’t work with my system” what they’re really saying is, “I think your project is a threat to my job and I don’t want to participate.”

This is definitely a problem, but not one that the identity management team should be saddled with. Early in the process, it’s easy enough to skip these groups and keep going – there are plenty of other systems and applications to role-base, so the luxury of deferring the “problem children” certainly exists. But for those that can’t/can no longer be deferred, escalate the issue to management and let them deal with it.

Next, we’ll discuss documenting the roles and getting approval for their use.

David caught my attention when he explained that the most important part of their approach is to empower users to take full advantage of their systems. He qualified this with the example that while you could probably use their equipment, in particular their Intrusion Prevention System, or IPS, out of the box, you wouldn’t be taking full advantage of the power in the device.

This struck me as a very interesting take on the user education system.

As part of my day job, I work with IPS systems. In fact, I have evaluated, implemented and operated a few solutions from different vendors.  One vendor in particular collects comprehensive statistics anonymously (from their opt in system) and publishes them for review on their site. They show that 60-70% of all of their end users use their IPS filters on the ‘Recommended’ settings, meaning without any modification from the vendor-produced filters.

In Cisco’s view, this would suggest that users of the other Vendor systems aren’t taking full advantage of their appliances.

So who is right?

We’ve all heard it, that “the user” doesn’t know what they’re doing, that the less power we give them, the better. In that case, wouldn’t it make more sense for the company with a full team designing and analyzing filters and threats to develop and maintain the IPS in a User’s network than for the User itself?

After all, if a device ships with the setting in place to auto-apply updates from the vendor, then the vendor can have significant control over the client network. Add filters when a new threat pops up, and in a few months, once the threat dies down, just recommend the disabling of that filter since the user no longer needs it. Minimal involvement on the user’s part, and they’re likely protected better than they could have done on their own.

But is that more beneficial to the user than education?

I point towards Michael’s Awareness That Works™. What if, instead of assuming the User is a lesser life form that has no idea how to properly secure their network, we assume that they’re just uninformed? You don’t call someone an idiot when they can’t spell a word or speak your language; you educate them instead. Why should we treat Network Security any different? We in the industry use acronyms, tools, and words that are often referred to as another language. Heck, we are proud when we say that we think in a way contrary to the average user. But how is that different than if I were to say I was better than a German, since I speak English?

It seems Cisco is on the right track, maybe we could learn something from their ideas.

What do you think? How do we strike the balance between providing solutions that help get the job done while educating people to really use the tools to their maximum advantage?

For me, this means a lifelong study of communication – verbal and written – blended with human ecology and the fundamentals of security. It’s an odd mix, but with my focus on Awareness that Works™, it serves my clients well.

A few months ago, I started a column for CSO Online dubbed the “Career Catalyst.” It allows me to build on my background as a catalyst and role as an advocate for individuals to share ideas, insights and strategies to help shape and develop powerful, effective careers. It turns out to be a perfect compliment to my approach to advancing individuals and organizations at the same time.

My passion in serving others is the driving force for this column.

I routinely listen to the challenges, observe the trends and think about the skills, aptitudes and attitudes for career success. But I also view this as an effort to serve as the catalyst for multiple ideas, experiences and challenges of the entire community.

Looking to improve your career and advance the profession?

• Share your successes or ideas you’d like my take on
• Ask the questions on your mind
• Share your challenges

Connect with me by email, telephone, twitter or through this handy contact form.

You can find my column here: http://www.csoonline.com/topic/41515/security-career-staffing

Here are the last three columns:

Security Careers: The Mic is Always On. Always.

Like politicians who’ve been embarrassed by public microphone mistakes, security professionals need to remember comments that are made in bad taste can put both a career, and an entire security program, in danger

http://www.csoonline.com/article/597056/security-careers-the-mic-is-always-on.-always.-

Cultivating a healthy addiction for career success

Going beyond the typical interview answers and resume claims will help you demonstrate why you stand apart from the pack. Michael Santarcangelo shows the way.

http://www.csoonline.com/article/594229/cultivating-a-healthy-addiction-for-career-success

Are You Making a Security Career or Working a Job?

In his first column as CSO’s Career Catalyst, Michael Santarcangelo outlines three essentials everyone needs to consider to make security work more than just a job

http://www.csoonline.com/article/590096/are-you-making-a-security-career-or-working-a-job-

Identifying the roles in the organization is like writing an outline for a book and helps with three things:

• Determining and documenting departments (similar to defining how many chapters in the book)
• Understanding which departments need to be addressed first (similar to organizing the chapters into a logical sequence)
• Defining which roles need to be addressed first within the department (similar to detailing the order of points in each chapter)

Prioritizing Departments

Consider that organizations with many departments and diverse access possibilities it may not be feasible to try to list out all of the enterprise roles in one shot. As mentioned in the introduction, an enterprise role may or may not have a one-to-one correlation with an HR job code, so it’s not as easy as asking the HR team to run a report. It begins with HR data, but then requires conversations with department heads to understand the details of their particular department. In many cases, it requires follow-ups, since the initial conversations develop new ideas – and provide an opportunity to make improvements. Remember, this is an iterative process, not a point-in-time activity.

If there are too many departments for a big-bang approach, start with a prioritized list to identify the most important ones – from an identity management perspective, that is. In this case, “important” boils down to three things (in any combination):

• High turn-over of users
• Complexity of access (more complex is higher priority because this is where access granting mistakes get made)
• Sensitivity of access (i.e., anything that’s likely to be audited; higher sensitivity is higher priority)

How many is too many, you ask? That depends on how many people will be working on this task, how long they have, and how complex the access is. The answer will be different for each organization, and it’s up to you to determine how many is too many in your situation.

Identifying Enterprise Roles

The process of identifying enterprise roles for each department begins with an analysis of the HR report: determine what job codes/titles are already stored in the HR system. This is followed by a working session with each department head. Notice I said working session, not meeting or “send an email.” Take this opportunity to build a relationship with each department head, and help them understand what you’re trying to do. Most will welcome the opportunity to set up roles and rules, because this greatly simplifies the process of requesting access for them (and probably receiving access too) – that’s all good.

There may be some resistance in anticipation of implementing the roles. This is normal (most people resist change); a common concern is people not being able to do their jobs in the transition to the new roles. By building the relationship now, it’s possible to understand and alleviate their angst before implementation begins.

This is also a working session because it will take time to educate the department heads and their direct reports on what needs to be identified. It’ll be hard for them to think of roles in terms of access – there will be vocabulary hang-ups with these individuals just like there were with the HR team. This will be very new and foreign to them, so start slow. Spend some time introducing the idea of role-basing, and helping them understand how it works and why it benefits them. Then engage them in the process of reviewing the HR output and filling in the blanks between HR’s reality and their own.

Identifying the roles with the department heads is only half the battle. After working with the department heads, it’s back to the HR system to figure out how those roles can be represented clearly, accurately, and uniquely. Typically, the HR representation of an enterprise role will be some combination of other factors – like job code + location (if you’re trying to distinguish between a clerk at Store A and a clerk at Store B), job code + manager (if you’re trying to distinguish a finance analyst in Accounts Payable and a finance analyst in Accounts Receivable), or job code + pre-defined rules (which get coded into identity management if there isn’t enough information in HR).

Although this information won’t be truly useful until the role management system is in place, starting to figure this out now will ensure that the roles are all built on the proper foundation for easy upload into the role manager.

It’s also important to start now in case the HR system cannot currently provide the information needed to get to an appropriate level of granularity of roles for access. If the HR system cannot provide the needed information, more research will be necessary:

• Can the information be pulled from some other source, like the recruiting system?
• Will a workflow be required to have a manager specify the missing information?
• Can the HR system be modified to contain more information?

Clearly, if system modifications are needed, it could take some time to get it done.

Prioritizing Enterprise Roles

Some departments are very large, and as such contain a large number of roles. But just as not all departments are created equal from an identity management perspective, not all roles are created equal, either. When faced with too many roles and not enough time, prioritize the roles using the same criteria that were used for prioritizing departments.

In the next article we’ll continue by discussing IT roles.

It’s taken this long to get here for a few reasons:

1. The initial user cleanups provided information on who’s who in the organization, and ensured that unused accounts were eliminated – no sense in role-basing users who aren’t around anymore, right?
2. The secondary user cleanups hopefully gave some ideas of what access users have, and provided the baseline data to do the discovery work that we’ll discuss this month.
3. The HR work set expectations of what’s available in the HR system, and also allowed the IDM team and the HR administrators to build a relationship and a common vocabulary. This will help the IDM team to ask questions in the right way, and the HR team to know how to interpret and answer those questions.

In the event the above exercises are still ongoing, I suggest you complete those as much as possible before starting on this one as they build the foundation for continued success.

Ready for roles and rules? Let’s get started!

But first, a little technical accuracy: Enterprise Roles and IT Roles

There are two different levels of roles – enterprise roles and IT roles.

An enterprise role is a high-level entity, like “accounts payable clerk.” The enterprise role generally corresponds to the person’s job title and is a larger bucket which contains multiple IT roles. However, since the enterprise role is a construct of identity management, it may not correspond exactly to a job code in the HR system. For example, the HR system may have a job code for “finance analyst,” which might contain the enterprise roles “accounts payable clerk” and “accounts receivable clerk.” More on this later.

An IT role is the set of permissions assigned to a particular enterprise role on a specific system. So using our previous example, the enterprise role called “accounts payable clerk” might contain all of the following IT roles:

• Email role of “standard email access”
• Internet role of “internet access denied”
• Financial system role of “accounts payable clerk”

In many cases, there will only be one IT role on each system that corresponds to an enterprise role, but that’s not always true. Similarly, multiple enterprise roles can contain the same IT role.

For the purposes of this blog, it’s not necessary to be quite so technically accurate. I will generally use the term “role” to mean enterprise role, and “permissions” to refer to whatever IT roles may apply. Where better accuracy is needed, I’ll be specific.

Roles vs. Rules

Rules transcend roles and either help the decision process of who gets what, or they provide caveats. For example:

• All roles in the IT department get “standard email access” except VPs, who get “executive email access.”
• The following Accounts Payable permissions may not be granted if the user is already assigned Accounts Receivable permissions
• Anyone above manager is entitled to “internet access permitted.”

The bulk of the work is actually in identifying the roles, so that will be the focus of this blog. Rules generally come after the fact, to plug holes and normalize permissions (i.e., they’re a higher level of maturity).

Approach

As with everything else we’ve done to date, this exercise is largely about brute-force effort coupled with some intelligent data analysis. At the end of the day the steps are as follows:

• Identify the enterprise roles (based on a combination of HR data)
• Design and test the IT roles/rules needed by each enterprise role
• Implement new IT roles (or full enterprise roles), and clean up old access

We’ll continue in the next segment by identifying enterprise roles.

This series, underwritten by Configuresoft, now part of EMC, is the full and unabridged audio version of Into the Breach, written by Michael Santarcangelo and read by the author.

What you’ll find in this episode (Chapter 11)

Outsourcing makes sense for a lot of organizations and continues to gain in popularity. Does this drive to outsource and partner actually increase security and protection of information?

By leveraging the strategy and concepts shared in Into the Breach, learn how to build a firm foundation for success – including how to measure the effectiveness of the partner and ensure mutual and lasting benefit from the arrangement.

• Learn how to establish appropriate and measurable criteria upon which to make better decisions
• Understand how to assess potential partners and providers to ensure appropriate fit and mutual success
• Gain insights into verifying and building relationships based on trust and mutual understanding

If outsourcing and working with partners is part of the process, then this chapter is a must listen.

Put the power of Into the Breach to work for you…

After listening to this segment of Into the Breach, keep the energy going and support the shift in thinking and inspire behavior change by

1. Engage with Michael on twitter (http://twitter.com/catalyst)
2. Subscribe to The Security Catalyst podcast & blog to get more insights; ask a question and get an answer!
3. Check out Awareness that Works™ – Michael Santarcangelo’s program to guide smart investment in people, with guaranteed results (this program pays for itself).

By Jill Van Zelfden

“Investing in Yourself”… I’m sure we’ve all heard this term at some point in our lives.  But what does it really mean and why should someone care?  And of all things: Why does my employer care?!

First, let’s start with a definition:

“Investing in Yourself” means that you are the driving force behind improving yourself in some aspect in your life in order to move ahead.

Examples:

1. Taking a college course to improve your job skills.
2. Reading a book to solve some problem at work or in life.
3. Listening to an audio podcast via iTunes to improve some aspect of your life.
4. Hiring a trainer to teach you something new.  (And no, although it could be a gym trainer to help get you into shape, I really mean hiring someone to teach you something new like Excel, or underwater basket weaving.)

Non-Examples:

1. Company sponsored training.
2. Company paid college course work.
3. Parent paid college course work.

Note: While it’s always great for these to happen and these all lead to something invested in you, these are examples of someone else investing in you.

Ok, so now that we’re clear on the definition, why is this important, how do I invest in myself, and why the heck does my employer care?!

So, why is this important?  Isn’t it enough that I am a parent, work full-time, do house work, make repairs on my house, eat, and sleep?  In short, the answer is “No.”

As human beings, we all want to achieve the next big thing.  Keep in mind that the next big thing is different for everyone.  What may be my next big thing could very well be different than your next big thing.  But human nature dictates that everyone has a next big thing.  None of us want to remain the same day in and day out.  We all want something more.

What’s your next big thing?

A month long trip to the Bahamas?

A new house?

A job promotion?

So, how to you go from the here and now to your next big thing?  You need to invest in yourself!  Take the time to sit down and figure out what is keeping you from that next big thing.  If you’re unsure, talk to someone who’s there and ask them how they got there or what they would have done differently.  Then take the steps you’ve identified.

For instance, if you’re after a job promotion, figure out why you haven’t been promoted.  Is it because your technology skills aren’t quite up to snuff?  Then take a look into community colleges in your area and find a class that will teach you the needed skills.  Is it because you don’t have experience with a particular skill?  Volunteer with a non-profit group that needs someone with that skill.  Then brag on the great job you’re doing for the local non-profit to your boss!

If I’m investing in myself, how could that possibly affect my employer?

Why is my employer wanting me to invest in myself?

Why does this topic come up in my annual reviews?

All great questions.

Here’s the secret that very few managers want to admit:

An employee who has an idea for their next big thing is more than likely an employee who is motivated in improving something.  This means that they want something from life, are happier, and are less likely to be here for just the next paycheck.

And if an employee’s next big thing is improving their job, then that’s an added bonus for the company.  After all, the more advanced work they can give you, the less they have to spend on hiring, benefits, training, etc on a new employee.  So, in the end, it usually proves to be a cost benefit to promote you instead of hiring someone else.  And if you’re in the right company, that cost savings flows down to you, the employee, in some form or another.  It might be a promotion, it might be a raise, or it might be both!  How awesome is that?!

But the key here is to let your new skills show!

And sometimes, that means identifying a hole in the company, learning the skill needed to plug the hole, and then spending an extra hour or two off the clock proving to management that you can handle more responsibilities.

Investing a few hours in yourself is very evident to those around you.  Because what you’re concentrating on and doing off hours will come up in conversation.  Think about a parent you know and the last time you asked them how their child was.  What was their answer?  Was it a one or two word sentence?  Or was it a story about how great they were at their last play/recital/soccer game/etc?

The same thing happens when you invest in yourself.  Your world all of a sudden becomes bigger and more exciting.  You start trying to relate your current knowledge to your new knowledge.  You start to say things like “See that rainbow?  Isn’t it amazing how light refracts like that?” instead of “Oh isn’t that rainbow pretty.”  And statements that show off your knowledge like that, is hard for your employer to miss.

So, I challenge you to:

1. Identify your next big thing.
2. Invest in yourself.
3. See how long before your family/friends/coworkers/boss notice or reward you in some way for working towards your next big thing.

About Jill Van Zelfden

After more than a decade in technology, Jill Van Zelfden found her passion for Information Security in 2008. Working to advance herself and the profession, she currently holds the Security+ and MCSE: Security certifications and is a member of ISSA.  She resides in the Dallas area and works for NetBoundary as a Security Operations Manager.  She’s available at twitter.com/JillVann.

At a minimum, you should know what to expect (or not) from the HR system, and how to get to the data that identity management will need. In some cases, changes may be needed to the HR system to really make identity management work.

Reliability

I’ve touched on reliability already in the context of new hires, transfers, and terminations. At a minimum, the identity management team needs to be clear on how quickly (or not) an employment event gets entered into the HR system. Questions also need to be asked about how quickly administrative events get entered into the HR system. For example, in August, we’ll discuss user recertification. In order to automate user recertification, accurate line manager information must be available for each employee at any time. Does said accuracy exist?

Any problems with the reliability of HR data are not the problem of the identity management team. Actually, it becomes their problem, but it’s not theirs to fix.

This is where the identity management team may need to influence (or guide) HR through the process of improving their own processes. This could be tough for a variety of reasons, but mainly because there won’t be any intrinsic incentive for HR to optimize their system in ways that don’t benefit them directly.

The good news is that in most cases, the HR system will be good enough for starters, and a lot more work will be needed on the identity management side to fully use what the HR system can initially offer.

If there is executive commitment to the maturity of identity management, there may come a time when identity management becomes limited by the HR system. The beauty here is that when identity management takes hold, various business units will start lining up to leverage identity management to do one thing or another. When they find out that identity management can’t meet their requirements because the HR data isn’t good enough, the issue of HR data reliability stops being the problem of the identity management team and starts being the problem of HR.

So my advice – don’t try to fix this problem from the get-go. Get your own house clean, and let others fix HR for you later.

Accessibility

Even if the HR data exists, where is it?

If the interface between identity management and the HR system has to go looking in every field and every table in the HR system to find what it needs, it’ll make for one complicated interface. More likely, the interface will rely on one or more audit tables to alert it when something has changed on the HR side. But does the audit table track everything that changes? Hopefully, the answer is yes, but definitely ask the question. I once discovered the hard way that the answer was no. It’s important to have the HR team confirm that every change made hits the audit table – including bulk loaded data.

Updating the requirements list

This month’s exercise should feed the requirements list with a few items:

• After identifying which HR system(s) will be interfaced with identity management, identify which protocols can be used (this may have already been done back in January, but I’m repeating it here just in case)
• If there are plans to interface with the recruiting system/module, identify those protocols, too
• List which HR tables contain information that’s needed by identity management, and begin laying out the data map
• Specify any requirements that identity management will need to address based on the reliability of the HR data

Action recap

This month’s exercise was primarily to build a relationship with the HR team that administers the HR system that will integrate with identity management (remember, there could be multiple systems, but for the sake of clean writing, I’m trying to keep it simple). The goal of the relationship is to:

• Build an understanding of how the HR system works and how identity management will leverage HR data to automate provisioning and task assignments for new hires, transfers, and terminations
• Understand the potential limitations of the HR data and feed that into additional requirements for identity management
• Clarify the nuances in terminology and data usage between the HR system and identity management.

Next month, we’ll talk about creating access roles and rules to populate into role manager, and do a permissions cleanup.

How can I help?

Do you need some clarification or additional assistance? Do you have an experience to share with others? Leave a comment below so we can all improve together.

When we left off, I had just decided it was time for me to throw my hat in the ring at BSides Austin; it was one month until my talk, and I had no idea what was about happen.

When I signed up, there were about 5-10 people signed up to attend, and 5 set up to speak. I could speak to 10 people, no sweat. Plus, I had only put myself down for a twenty-minute talk. That’s only ten slides, two minutes a slide. No sweat, right? Unfortunately, I failed to take something into account: the propensity for people to procrastinate.

I had signed up for my talk on a random whim, and as a result, had put it off immediately after I signed up. I had a basic outline of what I might want to say, but I had nothing concrete. So when I went back to the wiki a week or two later and saw that instead of the ten people that had previously been signed up, I was now looking at thirty people, the possibility that I would be streamed live over the internet and the fact that some people who I knew as bigger names would also be speaking at BSidesAustin. (I ended up sharing an hour slot with Robert “RSnake” Hansen, to give you an idea of the caliber of people there.)

Suddenly, this talk was real. When I signed up, I put my name down, tossed a few points in a document for an outline and didn’t think much of it for a few weeks. But now I was looking down a gun barrel pointed at the head of my career. Now, something that had seemed like a quick hop up, hop down thing seemed way more daunting than it had looked from far away. I quickly realized I was in trouble. Big trouble.

I was sitting and staring at my outline and looking at a dire situation. I wasn’t prepared for my talk. Heck, the talk I had lined out wouldn’t have passed my college course, much less a conference full of some of the most awesome people in InfoSec. So I turned back to where the whole idea of this talk had come into being: Twitter.

Ok, so I didn’t actually ask for help, per se. If I remember correctly, I believe my tweet read something like this: “Oh my God, what have I doe? I’m not in any way going to be ready for this talk. Maybe I should just withdraw my name, now that other people have signed up.” In my mind, I had no other options! I had read the articles, I had heard the rumors; InfoSec was a closed off, hard to enter industry. Why would they want some young punk with no speaking experience to say what’s been bugging him? I was an inexperienced professional speaker, and had no real credibility even in InfoSec.

Thankfully, other people didn’t agree with me. My tweet of defeat brought folks out of the woodwork to encourage me. People were telling me to stick with it, that BSides was the perfect place to make my entrance, that I would do ok. But one person in particular responded with more. I received a direct message from a guy I had followed in the past because I liked the idea of his site. He sent me a simple message: “If you quit now, you’ll regret it for the rest of your life. Send me what you have, if you’d like me to take a look.” An offer for help? Awesome! Just who is this guy?  Sant…Santar…Santarcangelo? Hey, this guy is a professional speaker! And he’s offering to help me without expecting anything in return? Maybe I can pull this off after all…

Tune in next week to see a heroic rescue, and the backbreaking work of our hero start to come together!

Compared to transfers, terminations are pretty easy, but there are a couple of gotchas, as mentioned in this month’s introduction. A termination in the HR system means the employee is no longer getting paid. However, the termination date for getting paid may or may not coincide with the date the employee should stop having access to the company’s systems.

As with transfers, removing terminated users’ access in a timely fashion is a key control for a variety of audit regulations, including SOX and PCI. On the other hand, it’s also a customer service issue – remove the user’s access too soon and it’s disruptive to the business (and can cause significant turmoil if the employee has not yet been notified of their termination).

Here are the key considerations for how HR data can be manipulated to feed identity management the right information to handle terminations.

“Last Day Worked”

If your HR system has a Last Day Worked field and it is actively populated and used, you’re home free – 99.9% of the time last day worked = last day access is needed. In this case, there is one possible gotcha: if the employee stays on in their current job function, but as a contactor.

Remember, the HR system focuses on payroll. Because of this, if an employee changes status from “employee” to “contractor” they may still be terminated from an HR perspective – especially if non-employees are stored in a different HR system. From an access perspective, it’s business as usual, although such individuals might need to be run through the transfer process to re-approve their access.

There are three ways to handle an employee becoming a contractor in the same job function; by handle I mean ensuring that the user does not experience an access interruption:

1. Find out if this is even a possibility at your company. If it isn’t, you’re done.
2. Find out if the HR system has some sort of flag (e.g., a termination reason – see below) that will identify this situation. If they don’t, see if this can be added to the system – that would be ideal.
3. Accept that this is a rare occurrence and not worth handling with technology. In this case, consider launching an awareness campaign with hiring managers and HR so that they remember to notify your access services team when this situation arises.

Analyzing termination reasons

If Last Day Worked is not a field that is reliable, an analysis must be done on termination reasons. Typically, the HR system will provide some sort of drop-down menu where the reason for termination is specified – things like “got another job,” “retired,” “reduction in force” (i.e., laid off) – although these are typically represented as codes, not text.

There is usually an indication if the termination was voluntary or involuntary. The list of reasons isn’t trivial – there can be a couple dozen reasons including things you might not expect like “deceased,” “going to active military duty,” and “didn’t like the dress code.” As an aside, I was amused to see one HR system in which military duty was considered an involuntary termination, while deceased was considered a voluntary termination.

It is important to analyze all of the termination reasons and determine (with the help of the HR experts) which termination reasons would normally correspond with the last day of work, and which might not.

The terminations reasons that most likely need to be flagged are listed here, but there may well be others – make sure that the HR team clearly explains any of the more ambiguous reasons:

• Reduction in force
• Retirement
• Leave of absence (this is one that might need to be looked at even when there isn’t a termination associated with it, but that’s outside of our current scope)
• Becoming a contractor (if that’s an option)

You may also want to discuss executive termination with the HR team. Although this may not be flagged specifically in the termination reasons, executives are the most likely to keep getting paid for a long time even when they’ve stopped needing access. Additional workflows may be needed to handle this situation, or simply an awareness campaign with the HR department so that they remember to notify the access services team when an executive gives notice.

“Termination Date” and “Action Date”

In the identity management world, we typically consider the termination date to be the last day that someone works. In the HR world, termination date is usually the first day that the user doesn’t get paid – in most cases this would be the day after the last day worked. This is an important distinction, and one that should be confirmed for your HR system, because you don’t want to cut off someone’s access on the last day they work – this is the day when they’re trying to wrap things up and get going. There’s no telling if they’ll be done by 10am or 10pm, and it can have a pretty negative business impact if a premature loss of access keeps them from finishing their work.

If HR termination date = last day the person works, make a note to configure identity management to begin the auto-deprovisioning processes on HR termination date + 1. If HR termination date = first day the person isn’t getting paid anymore, it can safely be used as the date to start auto-deprovisioning.

For those termination reasons where the access termination date is before the HR termination date, the action date might be useful. The action date is the date on which the information is entered into the system. For example, it’s common practice to enter a termination into the system for someone being laid off after they’ve been notified of the layoff. If laid off = escorted out right away, identity management could use the action date (or action date + 1) to trigger auto-deprovisioning. In this case, action date would be before termination date.

In the case of a vacation or leave of absence before termination, there may not be usable data in the system. These scenarios should be discussed with the HR team, and a workflow or awareness campaign might be warranted.

In the next article, we’ll wrap up this month’s activities with a general discussion of HR data cleanliness, and how identity manager can find the HR data it needs and pull it.