Italian Football

May 21, 2008

(From the archives, first posted in May 2008.)

I spent two weeks in Italy last month and it is truly one of the most beautiful places on earth.  So it was appropriate that I attend a match of the ‘beautiful game’, aka calcio, football, soccer.

The game was Fiorentina (Florence) vs. Sampdoria (Genoa), and it had some importance so a large crowd was expected.  I set out on the number 51 bus from Florence’s historic centre, bound for a suburban stadium near the Tuscan hills north of the town center.  45 minutes before game time the bus was full of purple-shirted — and well-behaved — Fiorentina fans.

Once near the stadium I realized that I had no idea of where to buy a ticket, so in my pitiful Italian I asked assorted gate personnel, coffee shop clerks and fans where the ticket office was.

I found one inside a cafe across the street from the stadium.  But inside there were big signs, in English, saying that English fans could not buy tickets for games here — they had been previously banned from Italian soccer stadiums, presumably due to poor behaviour over the years, and therefore tickets for all foreigners had to be officially dished out by the club.  Nevertheless I enquired at this cafe and was told, no, I had to go to the official ticket office down the street; my pasty Englishman-like complexion and bad Italian quickly (and correctly) labelled me a tourist.

Eventually I found the official ticket office, just down the block.  While waiting in line for the soon-to-be sold out game, I chatted with a Greek national.  He asked me if he needed his passport to buy a ticket.  Uh, yes, you needed some type of identification, and I had my passport on hand.  (I since learned that in 2005, new laws in Italy were enacted requiring teams to sell tickets only to named individuals, hence the need for ID.)  He was passport-less that day so he seemed quite dismayed, but stayed in the line hoping to charm the ticket booth ladies I guess.  In the end, he was turned away…

At the booth, I presented my passport and asked for a seat in the ‘family’ end of the stadium.  The agent looked at my passport photo, looked at me carefully, then entered my name and passport number into the ticketing system.  After a few seconds, the system — perhaps connected to a soccer hooligan database? — confirmed that I was not a troublemaker!  Out came my ticket, personalized with my full name printed on the bottom corner:

I was informed that I had to go to a specific gate in the stadium, and that I would be asked for my passport to prove identity before gaining entry.  I sprinted to the stadium, and showed my ticket to the uniformed gate-keeper.  But he waved me through without asking to see my passport…

The game turned out to be spectacular mostly because of the fans’ behaviour.  My seat was in the family end of the very full stadium.  At the opposite end were 15,000 of the most rabid home fans, and to our right — in a fenced and plexiglass section — stood a mass of rival Sampdorian fans.  Below us were a smaller collection of younger, energetic home fans and between the two were several dozen brightly uniformed crowd enforcement officers.

Throughout the game, the Sampdorians screamed, sang, chanted, raised fists and — when Sampdorian scored — rushed headlong towards the plexiglass.  The surge of 4,000 manic fans was accompanied by wild shirt-tearing off and the noise of 40,000.  In turn, the enraged Fiorentina fans below me rushed towards the security personnel, raised their fists, hoisted middle digits and flung insults toward their guests.  On this day, the surge was just a feint, and there wasn’t much more than some light shoving with security at the perimeter.  But even if they did burst through, a chain link fence stood in their way…

Fiorentina went on to score the next two, and the singing and chanting that filled the stadium was everything one could imagine at an Italian football game.  And as the game wound down, the smug confidence of the home fans could be felt.  The sky was blue, the game was in hand, our rivals quiet and downtrodden…

Then the unbelievable happened — with only a minute left, Sampdoria scored!  The visiting Genoa faithful rushed down the terrace, more shirt-flinging and frothy-mouthed bellowing!  The locals below us surged again, but it was less energetic — they knew as I did that we’d just been tied by these invaders and what good would a bloody clash serve at this point?

It was a fascinating spectacle, even though (thankfully) no true violence took place.  And it became very clear why my identity was confirmed prior to buying a ticket.  What if I was a hooligan looking for trouble?  What if my gang and I decided to bring smoke bombs, darts or other projectiles to lob into the visitor’s section?  Only by checking the thug database prior to entry could such things be minimized.

The only flaw was the missed passport check at the gate… The careful identity proofing and personalized ticket wasn’t much use if it the ticket-taker didn’t ask for proper ID on entry.  Perhaps the full checks of potential British-looking trouble-makers only applies to international games…

As for the game, click here for the highlights.

Mike


Words matter

September 23, 2014

I should know better.

I walked into a meeting of business types recently and started talking about their IAM service, how provisioning would be implemented and how SSO was part of the next release. SSO was going to be a good thing. Their users would very much enjoy SSO!

Except that they had no idea what SSO was…

The thing is that the audience — all very capable professionals in their own right — were having a hard enough time with the acronym soup already presented. They were still struggling with the picture of permissions for users being moved from one system to another. They were all still mapping their view of what the application did with what IAM would bring to the table. Their gaze grew distant, shoulders sagged, connection closed.

Why didn’t I just say Login Service? These people login to their computers every day. They login to their online banking, and their Facebook accounts. They login to their phones. They get login.

Words do matter in IAM. Figure out who you are talking to and use the right ones.

Mike


Where you from?

September 14, 2014

Periodically I have a disconnect with a client or a consulting partner. You know, one of those moments when you realize you are on different pages than you thought you were when the conversation started.

I’ve realized that there are typically two types of people working in Identity and Access Management. The first group comes from a security background, while the second has access administration or maybe more general IT on their resume. I’m a graduate from the second school.

This really dawned on me about five years ago. I was talking to a consultant, who was relatively new to IT, about identity management and how my job was to give the right people access to the right resource, yadda, yadda, my normal spiel. He was listening but had a furrowed brow and I realized he was struggling with the ‘allow access’ part of the conversation.

I quickly learned that he was an ex-military police officer with experience in electronic security systems. He was much, much more interested in blocking access and ensuring maximum security. The idea that we could (and should) make access easier was hard for him to understand.

I have learned that there are some in this business that come from a position of wanting to over-secure everything. If that’s who you are working with, it is best to consider that viewpoint because they won’t be able to move forward with an IAM solution until their primary security needs are met.

But there are also those of us that want a really good user experience even if it means managing some additional security risk. We’ll always look for a design that allows access — while still being compliant with security and privacy —  but is more aligned with client business needs.

Where you from?


Reblog: Anil John

September 6, 2014

For your weekend reading, here is a solid post with reference to Identity Assurance standards and guidelines from prolific identity blogger Anil John:

Anil John post on Identity Assurance G&S

 

Enjoy!

Mike


Access Governance Strategy

August 18, 2014

Identity and Access Management (IAM) projects are initiated due to an audit finding or security review. These projects have limited management focus — really, if we’re honest about it, a compliance driven project ends up being launched to fix a specific problem in the business. Projects are expected to be delivered on time and on budget, and then to wrap up after addressing a specific, tactical business need.

An Access Governance program doesn’t lend itself to this type of tactical approach. Access Governance needs a strategy, one that will help drive initiatives over the mid- to long-term. This is true even when (or perhaps especially when) an initial project is launched due to a compliance problem.

Access Governance has a longer life cycle than audit or security reviews, which are typically annual events. This is because access is something that crosses business boundaries, requires complex technical integration, and is dynamically changing as the business changes.

Business or IT strategies can help programs like Access Governance get established and funded. A strategy for access can critically assess business needs, develop roadmaps for addressing those needs, and help management to set performance measures.

When setting out to develop an Access Governance strategy, there are some key activities to be considered:

  • Know the audience — Is the CIO the primary reader of the strategy, or will it be used by multiple executives and managers?  A clear understanding of the business audience is crucial before embarking on the development of a strategy.
  • Identify relevant business goals — What is the organization trying to accomplish? What are the business goals for the next three to five years? Read the business plan and look for ways that access management can support those goals.
  • Link Access Governance to business strategy — This is the key to the process and it has to be done well. Explaining how a program of Access Governance helps move the business forward is critical. But linking Access Governance to business goals needs to be realistic and defendable if the strategy is going to be adopted.
  • Identify champions — The strategy needs to be built with full support of those that will receive the benefits of Access Governance. Make them part of the strategy development process and listen to their input. You’ll be rewarded with loyal supporters of the strategy.
  • Develop a readable strategy — There is nothing worse than a dense, technical document passing itself off as a strategy. Strategies need to be filled with business language. They must use terms that the audience understands, and they need to be structured in a way that encourages reading. Costs need to be identified and provided in both summary and detailed forms. Illustrations and models are key, and a realistic project roadmap diagram is mandatory.

Once the strategy is approved, a program for Access Governance can be developed. Soon, priority projects will begin to deliver strategic results, and your management will realize the benefits of having a strategy guide this crucial program.

Mike

(Yes, we can help you to develop your strategy. Please contact us for more information.)


Access Anarchy

August 18, 2014

It is no secret that enterprises run on information: records tucked away in databases, procedures retrieved from content management systems and transactions posted by business applications.  These information systems are as varied as the people who access them, ranging from highly-structured data stores to loose collections of images, files and assorted bits.  And cloud computing is flinging corporate information in ever-more places, onto remote servers, accessed by employees and customers whenever and from wherever they like.

access governance entitlements identity managementInformation Security professionals have to deal with questions that probe into information access.  On the surface, management — and their earnest auditors — have a simple question: who has access to what?   After all, access controls have been around for half a century and it is common practice to apply those controls to all types of information.  So what is the problem with these Who Has Access To What (WHAW) questions?

Put simply, security managers fear these questions because they are very difficult to answer.  And these, inevitably, then lead to ‘who gave access to whom’  (WGAW), ‘when was access granted’ (WWAG) and ‘why wasn’t access revoked when Bob left five months ago’ (WWARWBL5MA… okay, enough with the acronyms…)

Auditors know of these challenges but they are obligated to ask the questions.  It is their thing. And they don’t forget they asked — predictably they will return a year later to ask again.

Traditionally security managers would simply work with existing tools and cobble together reports based on information contained within business applications.  Once notice of an audit arrived, the security manager would direct access cleanup, export data from various systems, clean up the data, import data into a reporting tool, create reports, correct reports, format reports and submit them to management.  With anything less than 30 days lead time, this manual, inefficient process puts strain on the team and leads to errors in the reporting.

The main issues here are related to identity and entitlement management.  Let’s look at identity management first.

  • The true ‘source of truth’ for enterprise identity is the company’s human resources system.  No employee gets hired, paid or retired without HR knowing about it.   But what about temporary staff? Or contractors? Or those new employees from the company we just acquired that are in a separate HR system? The source of truth for these individuals — all of whom will have access to information — likely isn’t a single HR system.
  • Digital identities in enterprises are represented as accounts in a directory (typically Microsoft Active Directory or another type of LDAP store).  These accounts are created when employees are hired and removed when they leave.  An account is used to access network resources such as shared folders, content management systems and email. Provisioning of a user’s information directly from HR into Active Directory should be a straight-forward and high-value integration — and, sure enough, many enterprises have solved this problem already. But those relatively high-churn temps and contractors are often left outside this loop, requiring manual processes to create, modify and revoke those accounts.
  • Enterprise applications also require accounts, and these are often unique to each application or application suite.  Increasingly these accounts can be linked to the directory account, but that capability isn’t a given.  Legacy systems may have no support for this type of account linkage let alone any kind of dynamic provisioning.  And even if they are linked once, there’s no guarantee that they’ll be updated as the user progresses through the organization, experiences key life events (e.g. a name change), goes on extended leave, or, ultimately, retires or quits. As a result, gaps result that can be exploited by others who have access to the enterprise network.

Access issues are similarly challenging, and even more complex:

  • Before we get to describing the problem (even amongst ourselves), can we even agree on terms? Quick: what is the difference between an ‘access right’ and a ‘permission’? How about ‘entitlement’, what exactly does that mean?  Do you group users into ‘roles’, or perhaps you prefer ‘groups’?  Each system has its own, often arcane, language for describing what a user can access.  I have no real bias towards any one term but I’ll use ‘entitlement’ for the remainder of this article.  Entitlement is simply any form of application access right granted to a user.
  • ‘What’ is being accessed is similarly a challenge to define.  Some applications give access to all information.  Others have entitlements based on application functions or menu groups.  It is common to only have entitlements created for access to a group of records, or even a single record. Other systems have field level access controls.  And of course we have files and folders… as you can see, ‘what’ is being accessed is difficult to describe.  For now, let’s call all of these ‘information objects’.
  • These objects exist and need to be protected if we are going to keep the auditor happy (or less unhappy). Going back to our access terms, we might control access to one object using group membership entitlement – a common technique with Active Directory and network folders.
  • A business application might also use group-like entitlements that are related to job functions, but instead calls them ‘roles’.  And the roles don’t map to the same AD groups because, well, this application’s information objects aren’t used in the same way as network information objects are used.
  • Another system works from job title entitlements — only users with payroll titles can access the payroll system.  Of course, job titles may have little to do with the application’s groups or roles…and job titles change…

The result is that linking a user’s digital identity to an entitlement, then making sure the entitlement is controlling the right information object is a difficult problem to solve.  In practice, security managers delegate this responsibility to the owners of each business application.  They are given processes to follow for requesting access.  Sometimes the processes for access changes involve an email or two. Or a call to the help desk.  Or a full-fledged Access Governance tool. But in many cases it starts with a hallway conversation…

See where all this is going? That’s right – access anarchy. It seems hopelessly complicated to manage WHAW and we accept the next invite to the audit review with dread.

Over the next while, I’ll outline solutions to Access Anarchy: creating an Access Governance Strategy, having a better understanding of risk, developing standards, implementing software tools, and enhancing training. The key is to embracing the importance of Access Governance to quell Access Anarchy in your organization.

Mike


Old job, new job

August 5, 2014

It has been a while since I’ve had a new ‘primary’ contract so I thought a post on the old and new is in order.

Since 2007, I’ve been the IAM Program Manager for the Alberta Government department of Innovation and Advanced Education. We assembled a development team to build a new IAM solution for the department’s growing online services. Web applications for post-secondary students were the main priority but business partner access to online services and SharePoint sites was also required.

The solution was built on top of Active Directory Federation Services (AD FS) and was developed in .Net. The services developed include self-service registration, authentication, authorization, identity proofing, access administration and reporting. We call it the Secure Identity and Access Management System, or SIAMS for short.

Today, that IAM solution has 650,000 identities, processes over 100,000 logins per month and supports 35 business applications. It supports a host of self-service features like password reset via SMS, and can deliver up to LoA 2 identity proofing.

I’m proud of the team that put the system together and very appreciative of the support I received from Innovation and Advanced Education’s management over the years. Code Technology will remain on the job with Dallas Gawryluk taking over the reins in an expanded project management role.

My new position is as a Systems Integration Project Manager with Alberta Health Services. The IAM solution on this project is quite different, and the job I’m being asked to do is already both interesting and challenging.  Working with multiple teams, I am hired to plan and deliver an implementation of an enterprise IAM solution for clinical users and access administrators.

New faces, new issues — and after seven years, a slightly different commute to work. I’m looking forward to the next year!

Mike


Pan-Canadian Identity Assurance Model

September 17, 2013

In October 2008, I wrote a five part review of identity assurance, based on the framework contained in the Pan-Canadian Strategy for Identity Management and Authentication.  At the time these blog posts were the only Canadian resource available for analyzing and planning identity assurance.

Since then a number of changes have occurred that have prompted me to update these posts.  For example, an Assurance, Identity and Trust Working Group was established by the national Identity Management Steering Committee.  This team prepared a report, the Pan-Canadian Assurance Model, that provides more guidance and detail than the original framework.

Having said this, the goal of the model remains unchanged; it strives to standardize identity assurance to allow for provincial and federal systems to interoperate.  It is foundational to the broader Pan-Canadian framework, and is key to implementing citizen services across the country.

The identity assurance model is primarily concerned with establishing agreed-to levels of assurance and defining the concepts and terms each party need to understand.  It has an emphasis on federation and looks to support risk management activities within partnering organizations.

The Pan-Canadian identity assurance model is represented as follows (click/tap to enlarge):

identity_assurance_standard

While this model is an important input into this blog post series, it needs to be supplemented by real-world experience.  For each topic in the series, I will inject examples from my experience implementing IAM solutions over the past ten years, and provide insight into the opportunities and challenges offered by the model.

First in the series, click here for the post on Information Classification.

Mike


Follow

Get every new post delivered to your Inbox.

Join 291 other followers