Two Simple Steps to Protect Your Email Address and Phone #

by: James Carpenter, CISM, CISSP, CISA, MBA

     There are two pieces of information about you that, if they get out of control, your life starts getting out of control. Those two pieces of information are your email address and your phone number. What led me to devise a solution which controls these two data points in my life was the increasing propagation of interactions on the internet which require an email address, phone #, or other contact information to "continue" to use their service. Anytime I see the word "Free" I just laugh because nothing is free. Somehow, some way, when you give up your information - you will be contacted! There will be a cost! Therefore, I was always hesitant about giving out my email and phone # because I knew, once it was out, it was out. There was no turning back. These two simple solutions are useful when submitting resumes, filling out surveys, entering your contact information into drawings, or other situations where you don't want to give out your real information. Heck, I could even see it work great for the dating scene! For the record, I don't think I invented any of this; however, when I tell people about it, I see light bulbs going off - I see excitement - so I'm sharing it with you today.

Protecting your email

    The solution for your email is to first create or have a "home" email. This email account is your "real" email account. You've probably already got one. It's the email you use everyday. For me, this is a Gmail account but it can be any account you want. I like the idea of your real email account being an account with one of the big free email providers because you can count on it to always be available from anywhere. 

    What's great about this is, if you are unsure about giving your email out, for example when you post a resume on a public resume site, you can make up an email address for that particular scenario. If your name was Jane Doe, you could create one called Jane.D@yourdomain.us and post your resume with confidence. 

Here's some benefits:

1. If you start getting spam, you'll know right away where the compromise of your email address came from because you created that email for that particular instance.

2. You can cut all emails to that address off in one fell swoop! Simply log into your domain site and build a rule to kill emails destined for that address.

3. Best of all, by owning a domain, you have portability across your internet providers with a custom domain name you created. If you move or switch internet providers, you can keep your custom email addresses.

Protecting your phone #

    I use my cell phone for EVERYTHING! I really don't want my cell# getting out. You can do the same thing for your phone # that you can with email addresses - abstract your real phone number with a proxy number. There are probably many services that offer this but I personally use Google Voice. Services such as these allow you to obtain a free phone # and forward all calls and texts to your real phone. You no longer have to give out your real phone #. You can, ironically, find all these services and the Google Voice service by using Google. Search "Google Voice" or "Alternatives to Google Voice". 

About Privacy

    It is critical that you know by using Gmail, or Google Voice or any other "free" service that nothing is "free". There is a privacy impact; that I believe it is "impersonal" in nature. Impersonal in the sense that, no person is involved; rather, machines. Free services scan your emails and your voice-mails and extract meaning for commercial purposes. The best example I can give is this; If you send and receive a lot of emails related to playing chess, don't be surprised if the advertisements running in your email web browser start showing the latest chessboards or custom chess pieces. I'm not so sure about voice-mail; however, I do know that certain providers can translate your voice mails into text and SMS the message to you. While this is quite fascinating, it is a clear indication of voice recognition technology at work and once one can convert voice to text one can then analyze for commercial purposes, i.e. advertisements. My personal position on this is - it's worth the trade-off. There's no human reading my inbox or listening to my voice-mails and even if they were, they would immediate hang up when they found out I was always talking about the latest crystal chess pieces available. (Maybe I'll write a future article entitled "Avoid privacy problems by having a boring life"). I digress...

Closing

    The world is becoming increasingly data driven. Corporations are seeking every ounce of data they can get to extract value. This great collection of data is often referred to as "big data". It is an appropriate label because the idea is to get as much data about you (and me) as possible to market effectively or achieve some other purpose (hopefully not nefarious!) This will not change and will only increase as we enter into this new age of data driven decision making and a data driven economy. The saavy among us will therefore sieze ownership of our information and move into the age with an attitude that recognizes the value of our personal data and creates efficient mechanisms to best protect it; either by not giving it out, or by abstracting it to those who would otherwise take it for "free". Using these "free" services to your advantage in this manner creates a symbiotic relationship which benefits both parties. It doesn't have to be a one way street. 

Identity and Access Management Considerations in Complex Environments

Identity and Access Management 

Considerations for Complex Environments

by: James Carpenter, CISA, CISM, CISSP

A friend and I were discussing the various opportunities and challenges with the enterprise Identity and Access Management (IAM) solution we implemented years ago in a large, complex environment. There were so many aspects of IAM covered in that conversation that I felt like I had to write it down somewhere so I wouldn't forget just how complex this thing really was! Wouldn't you know it, at about the same time I saw a job posting looking for someone skilled in IAM to assist in the IAM merger of two organizations and that sealed the deal. I had my subject for a blog! Following is my list of the major lessons learned, the opportunities uncovered, considerations in planning, and other anecdotal tidbits to help others along with this complex subject.

It's a Journey!

Firstly, implementing a full-scope IAM solution is a journey. This isn't something you knock out in couple of months. I think of IAM as a journey comprised of several back to back projects; each delivering it's own type of benefit. Additionally, some of these projects are more accurately represented as program components of IAM which are ongoing forever; maintenance, if you will. I modeled it below.

Figure 1

Starting from left to right, the first two things (orange) you'll want to do is set the proper foundations which drive your automation. These foundations are establishing Role Based Access (RBAC) and the HR Actions and Criteria that your HR system will use to drive the IAM engine. These are super critical to get right. There is room for tweaking but the farther you get down the road of automation, the more impact subsequent changes can have and the more complex the analysis becomes prior to implementing those changes. Also, different companies have different HR actions that they wish to automate and some that they don't want automated. I will discuss some situations where not automating may be in your best interests later in the article.

Moving into the green shape we connect our directory. This is where we get our first massive return on investment (ROI).  It is also at this crucial point where staff skillsets start needing to change and where your first technical complexities begin. I will also elaborate on this later in the article as well. Notice that upon connecting the directory we have P1 (Project 1) 'Migrate apps to directory'. This should have been going on all along as part of an overall application strategy but it simply means - "all those other applications that you have that aren't tied to your directory authentication" - those need to be aligned. You increase the power and ROI of your IAM solution when you standardize your authentication to something that is already "hitched" to automation. You won't be building new connectors to applications per-se; rather you'll be writing new logic within existing connectors. P1 is one of those aforementioned 'forever projects'. You will always have applications onboarding in large, complex environments. Thus, the arrow extends perpetually to the right. 

     

    By the model, the next area to hit is your critical applications. You'll have to determine what those are but typically an organization will have 5-10 of these. These are applications that are the backbone of your organization, are subject to heavy controls auditing, or comprise the majority of your authentication and access needs (volume). Once you connect these critical applications, you begin another 'forever project' called 'Access Certifications', or checking the validity of your RBAC decisions on a periodic basis. Times change and so will your IAM logic which maps to your RBAC settings in your IAM. For example: When you initially established your RBAC, you may have build a model that authorized staff in Finance to have Remote Access, Finance Department Network Drive Access, and access to the Financial Application. What happens if, over time, several new applications came on board and/or the network drive structure changed such that the old directory rights are no longer valid? You'll have to update your RBAC list and consequently the logic in your IAM solution. This can be ongoing by some cyclical process or periodically assessed to ensure you don't have 'role drift' - situations where designed network and application access drift from the requirements of the job role. Doing this will take you a long way (to the good side!) in your audits.

The last step is to integrate your remaining applications. This is the last step in my model because as you mature your IAM implementation, you will note that there will be increasing complexity and a decrease in 'apparent' ROI or 'bang for your buck'. The work you do from here on out will be a balancing act best characterized by a favorite phrase of mine - "automate until it becomes painful." See Figure 2 below. The sweet spot is high benefit to the organization and low-medium complexity. 

Figure 2

Three signs of decreasing ROI when automating an IAM solution are:
1. Less bang for your buck. You put in hours, days, or months of labor into automation but only automate a small percentage of users or applications. The effort may not justify the outcome.
2. Complexity becomes unmanageable - similar to point 1 but maybe your efforts should be on the "other side" of automation - an application strategy that reduces/consolidates the number of applications you have or centralizes the authentication to your directory. You might have other problems that you needn't tackle with your IAM solution.
3. You're having trouble justifying further expansion to your leadership. Maybe an IAM technician wants to do it for the sake of your IAM solution becoming a monument to technical awesomeness but if you can't justify it, your leaders won't buy in.

 

Automation and RBAC 

By the model in Figure 1, we're still talking about orange territory here but there's plenty to say about linking your IAM solution into your HR system and directory to create automation. Common automation use-cases are employee resignations or terminations, new hires, leave of absences, and suspensions. What does your company want to do related to access in these situations? This is where your RBAC decisions come into play. Notice that in the model, I started with connecting the directory. In my experience, starting your RBAC with the directory first is a massive win. In most cases, your directory will be Microsoft's Active Directory (AD). By connecting to AD first you instantly gain automation against network file shares leveraging AD, your desktop and laptop environment, and a good chunk of all your applications leveraging AD authentication. This is a big win and here you should write your first rules.

The first rules to get established should be those around access - not necessarily the roles within an application or what network shares can be accessed - just whether the account can log in or not period. Is this account enabled or disabled? So many audit findings and incidents revolve around accounts that were not disabled in a timely manner. Linking your HR system to your directory via the IAM engine creates a rapidly compliant and effective environment for this problem. It's your first big ROI out of the box. See Figure 3 below for how this can be architected.



Figure 3

 

When wouldn't I want to automate?

Earlier, I noted that there are some situations when you don't want to automate. One such situation might be your employee portal where all employees, even former ones, can go to view their paychecks (or past paychecks), W-4, benefits, etc. I've ran into situations where some companies allow former employees to retain access to their HR system. The key here will be to limit what is accessible for former employees. You'll have to be keen on restricting access within the HR system once the employee leaves, something the IAM engine can automate.

Another situation where you might not want to disable access relates to your training system. I've worked for companies where employees and contractors could be suspended until they took mandatory online training. In such cases, their access was disabled. You might be surprised at the number of employees in a large organization that fail to take their mandatory training on time and get suspended. Of course, the real fix here is to ensure all employees take their training but in the case where some don't and have their account flagged for suspension - you'll want to leave the training access enabled so they can work their way out of suspension.

There might be a few of you out there that are saying "Automate everything! Even these two scenarios should be automated." To that I say, "Thank you" because it introduces a nice segway into the next section where I discuss a key concept - flexibility.

Architect to Promote Flexibility

As you clean up your environment and automate by building the IAM engine and adopting an application strategy that centralizes your authentication back to your directory, your directory engineers may start complaining that the directory is running slow. One reason for this is that you are aiming an increasing amount of authentication queries at the directory and it's getting bogged down. There are ways to optimize this; for example, by ensuring your users are organized properly and LDAP queries are not searching the ENTIRE directory. However, even after all optimization is done, you may need to peel off separate authentication directories to promote flexibility. See Figure 4 and 5 below for a before/after example of this.



Figure 4

In the "Before" example we see that all the organization's applications are querying a single directory. Also, there are some inefficient queries going on that are searching authentication requests from the root. Yikes! I bet it takes a long time to log in at this place! And, for all the Directory admins out there, we see the unnecessary OU that exists in every organization. You know it's true!!




Figure 5

Now we see the "After" configuration. We have created a separate directory to store user information and have synchronized it with the root directory. Also, we are only propagating what we need to authenticate the applications we move over to the new directory (Directory2). We have selected a few applications, such as our training and HR application noted above, to move over to this directory. By doing this, we have fixed the "all or nothing" problem related to enabling/disabling accounts and created some flexibility. Also note that the admins still didn't get rid of the unnecessary OU. They'll probably bring in contractors for that. :-)

Technical Complexity and Staff Skillsets

I did note that I would elaborate on staff skillsets and technical complexity. The more you automate, the less staff you'll need on the manual side of things (creating accounts, disabling accounts, modifying accounts) and the more staff you'll need on the automation side of things (managing the IAM solution) although it's not a one-for-one relationship.

One reason for this will be the mechanisms used for account touches (creating accounts, disabling accounts, and modifying accounts) will be form or web based from the IDM engine vs. logging into each application and setting up an account. Access Management staff can enter the data into a form or webpage hosted by the IAM solution and the IAM solution can create the accounts. Your goal will be to standardize on these form or web based entry points to promote consistency. Another good reason to utilize the IAM form or web based entry points is workflow. Most enterprise IAM solutions have some form of workflow. You'll want workflow for your non-RBAC (manual) processes because most access requests will need some form of approval workflow.

Another reason for the shift in skillsets will be the upkeep of the IAM itself. Connectors will need to be built to applications, troubleshot to ensure updates are occurring in a timely manner, forms and web pages developed, etc. This is an opportunity for your organization to grow your access management staff. Access management doesn't have to be a dead-end job. It can lead to IAM and subsequently workflow development which can open all kinds of doors. Once an individual understands that most applications are essentially forms and workflows atop a database and they can develop in those environments - a bright new world opens up. It's much more than programming and testing - it's talking to people, understanding business, and translating that into workflow. Good people skills and business process understanding come in handy. Have any people like that? They will be good candidates.

 

Wrapping Up

 There is much more to say on this subject such as staffing models for transitioning to an IAM, Budgeting for an IAM, project plans for implementation of an IAM, how to sell IAM to your leadership, etc but I've run out of steam!

I will finish with this: If implemented and managed properly, an IAM solution will become the backbone of an organization's access management solution, save money, increase compliance and efficiency, and provide opportunity for growth of IT staff.

If you're interested in learning more about IAM solutions or are implementing an IAM and would like assistance in planning and design please feel free to reach out to me through LinkedIn or email me at iamhelp@98g.us. I would be happy to help your organization get it done right the first time.