GDPR: direct marketing vs natural/legal persons

Just a quick hint if you want to contain legal spam under GDPR.

Recital (14) “The protection afforded by this Regulation should apply to natural persons, whatever their nationality or place of residence, in relation to the processing of their personal data. This Regulation does not cover the processing of personal data which concerns legal persons and in particular undertakings established as legal persons, including the name and the form of the legal person and the contact details of the legal person. ”

Recital (26) “The principles of data protection should apply to any information concerning an identified or identifiable natural person. ”

In short, GDPR only applies to natural persons (people breathing), not to legal person (like, the thing with a VAT number or company registration nr).

So: Companies/legal persons can be legally contacted or spammed.

Conclusion: use a general mail address (like info@ or company@) in all non-personal company registrations and contact details, white pages, yellow pages, VAT or government paperwork…

Make sure your official company registration DOES NOT refer to a personal address.

And as owner or delegate, keep your mail address for your personal professional communication, eg signature with personally identifiable contact details (mail, phone, mobile, skype, IM, …).

Because then your personal mail account is related to an identified and identifiable natural person, and covered by GDPR, protected from direct marketing violations. Should be.

Advertisements

That alphabet of Security starts with I of “Identity”

It’s an understatement to say security is moving fast, it’s changing very rapidly and the pressure to keep up with it, increases too.

From various angles, people in IT (as in Information Technology), are under fire to keep the infrastructure secure. Cloud is getting mature, new features pop up every week.
It’s almost a contradiction, but also legislation is catching up to close the holes regarding the protection of people’s security and privacy.

In many cases, the first reaction of customers, management, ITPros, Developers, DevOps,… is to look for the ultimate and ideal tool that will help to plug the security hole.

But if you only focus on the tooling, you’ll discover rather sooner than later, it is not sufficient to get your security watertight.
One of the basic reasons is that tools can’t be implemented properly without involving people and processes. I don’t need to explain the PPT (people-proces-technology) or PPP (people-proces-products) triade, right?

Lots of security management approaches and certifications handle this triad (ISO27001, CISSP, … I’ll cover that another time.

(credits: smart picture of ITGovernance.co.uk)

Rather than diving into the search for a tool, you better take a step back and consider first.

What’s the primary function of security?
Protecting an item that you want to keep (safe), right?

[The reason (“why”) for keeping it safe = the CIA triad, Confidentiality, Integrity and Availability]

When you think about the processes (“how”) to secure  an asset (anything that is worth securing), there are 3 basics actions you need to define

• authorization: what you can do with the asset (the CRUD stuff, create/read/update/delete)
• identification: who needs the authorization?
• authentication: the method to proof your identity (using passwords, passes, cards, 2FA, MFA, …)

This is essentially the foundation of my credo “no security without identity”

Just by interpreting the basic components of security, you directly hit the “PROCESS” part of the PPT triad.
Now, here’s were most technical people get into trouble… not knowing how to put this in practice.

But let me ask you a simple question: within the normal, usual businesses or companies, where does the identity process typically start?
Yes, correct, HR (Human Resources)

The second question: can you name at least 2 typical high-level HR processes (for people).
Answer: something like “hire” and “fire”, or synonyms like “onboarding/off-boarding”, “termination”, “end-of-life” (but that sounds pretty dramatic when talking about people…).

These 2 events announce the beginning and the end of a lifecycle, the identity lifecycle.
And to make it complete, you also need to define the life-in-between as people change over time.

BTW, just a small side step here: this does not apply to humans only, but any other asset in your environment has pretty much the same cycle and it does not matter if it’s considered “IT” or not… computer, certificates, smart cards, disks, tapes, … but also cars, documents, …

This idea to consider the lifecycle as universal, is a great approach to explain the “identity lifecycle” to non-techies that get involved in the identity lifecycle processes.

This is the common ground you can use to talk to HR people, business managers, Executive level, …

Now, if you look on the internet for pictures on identity lifecycle management, you’re smashed with a lot of complex schemas…

Many of results are variations of 3 essential processes

Depending on your background you might name them differently, like:

For the sake of simplicity, when teaching IDM and security workshops I usually only keep the keywords “Hire”, “Change” and “Fire”.
Short and easy to remember for most people.

For your understanding, the circle approach  would assume you start over again after the “Fire” block, but that’s not always the case. The cycle might stop.
So, the approach below is easier to visualize for most people.

Clockwise:

1. Starting the cycle at (1),
2. updating the identity at (2),
3. exiting the cycle at (3)

As I mentioned, earlier, virtually any IT or asset related proces is basically working like this.

Now, let’s take it a step further… How does identity management control security?

A first thing to consider is the typical length of the hire-change-fire modules.

How many tasks/steps does it usually take to complete each of the 3 steps?
Keep the asset in mind and keep it simple…

Typical actions in a hire process:

• signing contract
• getting an network/AD account
• getting an email address
• getting building access
• IT stuff (laptop, …)
• …

Pretty straight forward…
How much time would it take, in simple cases to start working?  Hours if not days.

What about the change process? For example, you get promotion to team lead or head of department…

• hand over your tasks to peers
• get ramped up on new job
• in some cases, there is segregation of duties, getting rid of existing rights permissions
•  getting access to new environment
• changing communications channels (notifications to stakeholders of change)
• …

In reality, this usually takes a few weeks.

And what are the typical things your consider for the “fire” process?

• informing stakeholders/customers
• disabling the account
• changing password
• lock account
• removing access
• extracting documentation form personal storage
• move documents to manager or team
• handing over ownership
• knowledge transfer
• data backup/archiving
• cleaning the mailbox
• deleting the account (* not always allowed for various reasons)
• sending legal / tax documents
• and more…

As you can understand, this entire termination process might take months… In many situations the termination process must be executed in different steps, like:

• Disabling the account till x+30 days (for example, revert in case the person gets a renewal)
• Removing access on x+60 days
• Kill mailbox on X+90
• Remove the account on X+1y (or even: never)

In some cases accounts must be kept for legal reasons or tracking/cybersecurity reasons…

The further you go in the lifecycle, you need to combine more tasks, and tasks or decisions get more complex.

Overall you can distinguish 2 properties of these processes: duration and complexity. Both go up.

Now, when considering security, why is this important?
Instead of discussing the impact of successful processes, it’s easier to find out what happens if it fails.

WHAT IF… (the process fails)??

Let’s run through the cycle again….

What if the “Hire” process fails?

• you can’t access the building
• you do not get an account
• you can’t logon
• you can’t access documents
• …

Basically, on your first (few) day(s) you can’t work. Sorry!
But what’s the balance for security: just great, because the risk is nearly 0, except for a bad start and a bit of reputation damage..
At the end: you can’t do any harm, essentially.

In case of the “change” process, a larger part of the tasks and operations will impact the security posture.

When your “change” process fails,  for example

• you can still access your old documents
• you get more access (eg collecting access of your old and new role)
• you start collection sensitive accesses over time
• managers don’t know
• user profiles get copied from existing colleagues in the same team (no ‘reset’ or the permissions before the new ones are assigned)
• …

So for this second piece of the circle, the impact might be significant, over time.

But for the “end-of-life” the story is completely different, a failing “deprovisioning” scenario has major impact on the business and IT process

• accounts stay active
• accounts not being disabled
• access not removed
• active accounts not detected
• account with highly privileged access still active
• accounts being deleted too soon
• unauthorized users that have access to critical resources
• hackers go undetected for a long time, using sleeping accounts
• hardware not returned,
• data stolen,
• over-use of budgets to software licenses that are not revoked
• access badges allow unauthorized access to your building and environment
• failure to ‘deprovision’ old hard disks properly expose your company data to interested (unauthorized) parties…
• …,

It’s clear that a failing deprovisioning/end-of-life process has major impact on your enterprise security.

And hackers or disgruntled employees like that.

Of course you can imagine the benefits of an efficient and effective end-of-life process. It’s the opposite.

Does that require you implement an automated identity management?
No.

That’s where ISO27001 and eg GDPR surprises a lot of people.

Once you’ve got the basic processes in place you can discuss tooling, not the other way around.

You have
no security without managing your identity.

you want
no identity without security.

Did I mention  that I’ll be presenting more of this fun stuff on TechoRama 2017.
Check it out here: http://sched.co/9M94

I’m very proud to present a session on the ABC of identity: Maximizing security with 10 simple processes.

 

Protecting your #FIM2010/#MIM2016: Core account type differentiators

When handling solutions in the identity & access management area (and practically speaking working with FIM/MIM), a very basic discussion is always coming back: which types of accounts do you need?
It’s seems a trivial question but you can apply it to different areas of the solution, both from a technical as from a logical perspective…

When talking about the technical perspective, I’m looking at securing your technical implementation.

A more practical question would be: what user accounts do I need to prepare before I start implementing my IAM solution? What is needed to implement my solution in a secure, but manageable way, with respect to principles of “segregation of duties” and “least-privilege“, but also “due care”, “due governance”…

With a bit of experience (referring to the installation requirement of a typical FIM/MIM configuration), you can easily list at 5 categories of accounts you need:

1. installer accounts: typically administrator accounts to run the setup, with some privileges on the server and back-end systems to get the server components running
2. service accounts: account that will be configured on applications running continuously in the background (FIM Sync service, FIM Service service, SQL Database services
3. account that are not running full time in the background, but run a technical task now and then, not continuously, but automated without user interaction (eg like the FIM Sync run profile scheduling, …)
4. personal accounts, that logon to the desktop, what every single person is using to do his daily job and IT work (logging on on your laptop, remotely connecting to the server,… )
5. personal administrator accounts: that logon to the desktop, or to the server desktop for highly priviledged IT work (logging on your laptop as admin, connecting to the server as admin, administrative tasks…)

So what are the key differentiators to define and separate these accounts?

One of the primary differentiators is interactive desktop logon (1).
Typically an installation account or an administrator needs to logon…. A service account running the application in the background on the server, … does not.

Also, when securing your environment this is a key parameter to lock down the privileges.

This differentiator is also directly related to password management.

Account logging on in the desktop can change their passwords. Accounts running in the background, without interaction will have major trouble when they are under password change policy.
Unless the application supports managed service accounts, but that’s not wide spread yet, certainly not for the FIM/MIM components…so I’ll skip that track for now.

But an installer account, DOES NEED desktop logon, but SHOULD NOT be deleted when someone leaves the company.
The best example of this difference is the FIM Installer account, that gets local admin access to the Windows server and to the SQL server as SA. This account is also injected in the FIM portal as default (GOD MODE) admin, so you DON’T want to loose this account.

So, another easy differentiator is the link to a physical person (2).
Typically physical persons are ‘managed’ with a lifecycle (eg under contract with your company). You know the typical hire-change-fire processes… (people on-board, people change jobs, people leave the company)

You don’t want to run your background services on a personal account, because… if you are running your identity management the proper way (and you will), they will be deprovisioned one time, right?

In normal (I should rather say normalized) security situations, the principle of least-privilege dictates that normal user accounts should not have extensive administrative rights, these should be attributed to separate administrative accounts.

So, the parameter: “highly privileged rights” (3) is a another key differentiator between the different types of accounts that can logon to a desktop.

The opposite of the ‘physical’ account are accounts that are not (or better, SHOULD not be) used by people, but run in the background, most server and/or Active Directory admins immediately think about the following system / GPO settings

• deny run as a service
• deny logon as a batch job

So, considering “segregation of duties” and “least-privilege” makes them mutually exclusive. (I beg you to disagree and provide me motivated arguments …), which provides me 2 other differentiators

• run as a background service (4)
• run as a batch job (5)

Based on these differentiators, the basic accounts types you can define are

• service accounts
• technical accounts
• functional accounts
• personal accounts
• personal admin accounts

	Account Type
Task type	Service Account	Technical Account	Functional Account	Personal Account	Personal Administrator  Account
Run as a Background Service (continuously)	YES	NO	NO	NO	NO
Running a batch job (Specific Task or script)	NO	YES	NO	NO	NO
Interact with desktop/Physical Logon	NO	NO	YES	YES	YES
Highly Privileged Rights	NO	NO	YES	NO	YES
Direct Link to physical person (link to HR)	NO	NO	NO	YES	YES

I’ve been working with a variety of customers and environments and I challenge this matrix every single time.

So I would like to challenge you to find a better, easier, more solid matrix.
Is there anything in this set of parameters that doesn’t make sense? Too simple, to complex, anything missing?

If yes, let me know and we go for the next version.

Note-to-self: You lost access to your initial Office 365 admin?

Although Microsoft has built in quite some methods to regain access to your 0365 tenant/account, you might have some bad luck one day… (experience talking here)

First of all you should try the default options, meaning : the password reset options.

The direct way to get there is the first link to bookmark: https://passwordreset.microsoftonline.com/

Another way to get there is in the 0365 logon page (also for Azure),

If you forgot your password or can’t access the account, hit the link at the bottom.
You get directed to :

If you know the logon, you can proceed to

You notice that the verification is pointing to your alternative mail address or your mobile number…

But what if you forgot your original logon ID (mail address), eg in case you have setup a test tenant in 0365 with an mail address you don’t use frequently? (yes, that happens)

If that is not working or you need more help, check these options:

• Microsoft Support: A user or an administrator forgot his or her password in Office 365, Azure, or Intune
• Reset my admin password for Office 365

And if you really ran out of luck: you might raise a ticket and ask for help. https://portal.office.com/support/newsignupservicerequest.aspx

Anyway, as shown there are some options when configuring 0365 that should keep you out of trouble in the first place

• make sure to add a mobile number to your user account
• make sure to add a secondary email address to your account (not belonging to your O365 domain)
• Configure and test MFA (multifactor Authentication), eg with the Authenticator app
• add a secondary admin account with sufficient rights (with the same security measures!)

June 2017: @TroyHunt is back in Belgium for his workshop ‘Hack Yourself First’. Wanna join?

ZIONSECURITY will be welcoming Troy Hunt again. The 1st and 2nd of June, he will be leading a ‘Hack Yourself First’ workshop where he will teach professionals how to break into their own applications. Find out the program and register here!

#update: download the flyer with program and details here: Flyer Troy Hunt June.

I have been there the last time, it was great fun, lots of interaction. And I certainly would recommend you to join.

What if you really wanna join, but your boss is not willing to sponsor? (While he SHOULD!).
Or any other silly reason you can’t attend?

Well, you know, if you can provide me a very good, strong, original and unique argument why you MUST be at this workshop, you might be lucky.

You know the channels to reach out to me and test your luck.

Some suggestion, send me a direct message:
1. Comment on this post,

2. mail me, tweet me (direct message!), F@ceBook me, LinkedIn …

Convince me and it could be you sitting at the first row.

Note-to-self: Security Compliance Manager 4.0 now available for download!

Sometime you get some silent signals that you have been way too busy…

Like stumbling into an announcement of a tool you evangelise…

“Security Compliance Manager 4.0 now available for download!”

 

 

 

FIM/MIM Licensing: clarification on the requirement to use CALs

Since the addition of the FIM Service and Portal in FIM 2010, the licensing model changed from a “server only” licensing to “server + CAL” licensing. (NOTE: CAL = Client Access License).

In April 2015 licensing update of FIM/MIM, the server license became virtually free.

The authoritative document that provides you with the full details is the PUR (Products Use Rights) document published by Microsoft.

See my post on the licensing change for all required info: http://aka.ms/LicenseToCAL. It does contain the links to the PUR (in various languages).

You can also check the TechNet Wiki page for the FIM/MIM licensing: http://aka.ms/LicenseToFIM)

 

In short: in general, you do NOT need to buy a FIM/MIM server license anymore, it’s included in the Windows Server license.

Still, keep in mind, some specific situations do require special/additional licenses: check the PUR.

You DO require CALs, which is mentioned by the PUR as:

“A CAL is also required for any person for whom the software issues or manages identity information.”

 

You can acquire FIM CALs via :

• Forefront Identity Manager 2010 R2 User CAL (device CALs are not available), or
• Enterprise Mobility Suite User SL, or
• Microsoft Azure Active Directory Premium

The april 2015 licensing change caused quite some confusion on the CAL requirements (as the FIM/MIM server license became ‘free’…)
One of the important reasons was the following paragraph in the PUR (quote):

“/../

Synchronization Service

A CAL is not required for users only using the Forefront Identity Manager synchronization service. /../”

To rephrase this statement: if you ONLY use the FIM Sync engine, you DO NOT need to buy/acquire any license (you got server license free and CAL not required).

This essentially means that IF you do install the FIM Service (and probably the FIM portal to manage it) and you DO connect the FIM Sync engine to the FIM service via the FIM MA, you DO NEED CALs.

This also applies to BHOLD and FIMCM.

This is how it was phrased by one of the FIM/MIM/AADConnect program managers: “As soon as you have installed the FIM Service MA (or BHOLD or CM) then you have triggered a CAL for everyone in the MV. ” It’s not relevant if the users are in FIM Service or not.

This is also the reason for built-in declarative provisioning (without a need for the FIM Service MA) in Azure AD Connect sync… this puts the FIM/MIM licensing model on the same frequency as the Azure AD connect licensing.

Now, this perfectly answers the question of Henrik on my post on the licensing update.

His question was: “What if you install FIM/MIM Sync and Service, both included in Windows Server licensing but you choose not to add object mappings in FIM/MIM MA for users and groups… This will allow you to import filter based sync rules from FIM/MIM Service.”

The short answer is: you still need to acquire the CAL.

Summary

• FIM/MIM server license is included in the Windows Server License
• you DO NEED CALs for FIM/MIM
  • you can purchase CALS or acquire them via EMS/AAD premium/ECS
  • for EVERY person managed
• 1 EXCEPTION:
  • if you ONLY use the FIM/MIM Sync Engine, you do not need CALs

I hope that this explanation helps you to better understand the FIM/MIM licensing.

Feel free to contact me via any channel if you have any feedback or questions.
Happy licensing!