In terms of how the label “user” is used… and how it cuts both ways, I am in complete agreement. It’s actually the topic of an upcoming column for CSO online later this month. The premise is that while I advocate being mindful of our terms, there is a flip side, and it needs to be taken into account, too. It’s not necessarily fair when someone else gets “offended” at the terms we choose. However, in my experience, there are two sides to each exchange, and while sometimes it’s entirely someone else’s “problem,” we generally have a chance to influence the outcome. Each situation is different, and some people will never be happy.

I like the point about automated decisions. I hope my attempt to shift thinking didn’t suggest the label based on appearance, but instead on function. This point has given me something to think about in terms of “users” when building profiles, roles and the like. At the core, however, I agree the term “user” to define a person engaging with the system is accurate and less loaded a term.

Lastly, no question we’ll always have a generic term, and the list suggested is good. The challenge of language is the emotional baggage that gets attached to words… intentional or otherwise. We’ll continue to have users, serve clients and address individuals.

The purpose of this piece was to push the thinking a bit. I’ll have a few more considerations, too.

1. Issues with the use of the term “user” go both ways. Some people call others, “users” with the tone of “average dumb users” along with a rolling of the eyes. That’s a problem. But others, like your opening example, have this sense of entitlement that they’re not “average users.” This isn’t a problem with security or IT or the persons speaking the term, but with the subject. Entitlement is a dangerous, ugly attitude to have. The point is, disdain over the term goes both ways and is a problem on both ends. These same people might take offense to being “normal customers” or “average people” or “employees.” I actually sometimes steer away from using the term “user,” but I often need something to refer to a collection of people consuming a system or technology of mine, and it’s really annoying when I innocently drop, “users” and someone gets offended, not because of anything I do, but because *they* have some hang-up over it. I don’t consider that to be my problem, but rather theirs. (Not to get politically charged, but it’s a similar sentiment to straight/gay marriage arguments…)

2. When a computer interacts with people and makes decisions on actions and access and communication, it doesn’t much care whether someone looks awful or looks like a million bucks, or whether they are worth that or not. Much of my outlook on such problems doesn’t involve me thinking about Dave Johnson, but rather about this generic “user account” with various properties attached to it. I know, we’re probably moving in two different directions here where I’m facing the technology and you’re turned the other way addressing people, but I hope it does illustrate the point that “users” isn’t all that bad.

3. I have this strange feeling that there will always be a generic term, whether it be consumers, participants, people, employees. I think the disdain for the term “users” doesn’t come from there being a collective term to group people, but rather because dramatic IT nerds (nerds being the less socially adept between nerds and geeks) use it venomously. I also believe part of it is the inevitable frustration almost everyone feels towards their computers and computer use on maybe even a daily basis. They’re not so much annoyed about being called a user than they are at everything surrounding that experience. I’d guess that if we called them people, they’re still be frustrated and annoyed…though maybe directed at something more appropriate like poor performance or junk apps. Maybe we should call them “accounts?” The more we say, “Security is a people problem,” I wonder if people will eventually start hating being lumped into the “people” group being referred to!

All that said, I still actually agree with you. It’s really an attitude change between IT and how they perceive the rest of their stakeholders. If they collectively just act more respectful and better, more good things will get done. (Though I’ll still say, that may not actually directly change anything in regards to poor security, poor technology, or staff talent problems…but at least we’ll all feel better!) Changing the use of the term, “user” may just be a tangible manifestation…or…oh lord…catalyst…for that change. (See what I did there?)

Strangely, that sort of triggers some thoughts about a Securosis (Adrian Lane) piece about friction in business teams.

[WORDPRESS HASHCASH] The comment’s server IP (209.133.56.3) doesn’t match the comment’s URL host IP (209.133.56.114) and so is spam.

One of the many things I love about Michael Santarcangelo is that he will tell you that security is not a product; it’s the relationship between human and technological systems. Office culture, resourcing, awareness, and empowerment all play critical roles in true security. Unfortunately these are often overlooked, because they’re not easy to implement. But these things are what Michael does best.

I once worked for an organization where I demonstrated a simple hack into our company website that would allow any script kiddie full access to 80% of our membership’s data, corporate board minutes, etc. My findings landed with a resounding ‘thud.’

While the directors empathized with a vague moral obligation to protect members’ privacy, the problem was a very low-cost risk which required a large investment to fix. Their unarticulated, but dangerously weak inductive reasoning went something like this: Since our members have never complained about a data breach, a breach has probably never occurred, or if it has, was harmless. And since a data breach has never occurred, it is unlikely to occur in the future. If a breach does occur in the future, it will likely be harmless. And even if a breach occurs in the future, and it causes harm, nobody will be able to prove that the information came from us.

Or in other words- they won’t be able to pin us if something goes wrong.

Despite the logical and circular flaws, the arguments are common, economically efficient arguments one would expect to hear from any reasonable, bottom-line-oriented organization. They also demonstrate why so much work needs to be done to encourage a culture of empowerment and awareness in which true security can flourish.

Anyone else aware of specific tools or utilities for iPhone, Droid, iPad, or even MP3 players?

You raise a great point about communication. I didn’t see anything around the store explaining the decision, and I did not ask (not sure I would have gotten accurate answers).

Intention goes a long way – especially when measured and communicated appropriately. And then, if needed, adjusted.

When it comes to incorporating the concept of a token into awareness programs and risk management projects, we need to focus on “measuring what matters” so we can “communicate what counts.”

Great stuff.

I thought about that too… or perhaps the employees did a sweep of the lot before I got there. What I am going to think about though… is if a token used in the scenario described is artificial compliance, or actual compliance. Admittedly, I want individuals to take the action (and I would expect a large number would — especially if they have kids asking for the quarter). But if the purpose is to ensure carts are put away without staff intervention to protect the cars in the lots, etc…. then a token might have more value.

In a corporate setting, then, we offer a “token” — and while accepted and used by most, if others were to find value and “pick up the slack,” I’m not sure that is necessarily bad. I guess it depends on the situation.

Great stuff!

But in all honesty, I agree with your post. I just wanted to throw another idea in.

Is it because cars were getting dinged from runaway carts?

If it’s the latter, I’ll embrace it and a simple sign would do.

Plus, as long as there’s a spot for me to park my cart safely in the lot, since I don’t care about the quarter when I have two little kids to buckle up.

In the spirit of the post, I hope the store pilot tested and tracks Q sat. Great post.

I was cleaning out some old boxes of “stuff” from days gone by and ran into a hard copy of a presentation that I delivered as part of the interview process at CERT/SEI in Pittsburgh back in 1998. At the……

I’d even agree that this is in part due to ignorance by the users. But there’s 4 things I think work against this…and I’ll avoid the cost of manhours for now.

a. Time. Yeah, we’ve all heard it. Time is a luxury in IT. I’d love if I had time to tinker and get to know the devices in my realm better. Sadly, most IT have their biggest learning spurts only while troubleshooting the latest fire.

b. Desire. Especially in security as opposed to a more general IT role, if someone doesn’t have the desire to learn more about security devices and security in general, no amount of hand-holding or throat-stuffing training will make too much impact. I’d also factor into “desire” the tendency for IT to be risk-averse, especially with systems that may impact operations if you poke them with a stick too much. Poke an IPS with a stick for a while, bring down a highly visible system, and you likely have less desire to do poking in the future.

c. Vendor bloat. Some tools are, to put it nicely, just too chock full of knobs, buttons, menus, variables, and ways to make plugins. This often comes from a vendor who wants to increase their market as much as possible by putting in every feature that any segment may want. At the expense of making a product that any one given customer will only use 20% of. At worse, it overwhelms the customer into just accepting those defaults and moving on. (And it should be relaxed enough that any customer can just plug it in and it works, at the cost of tighter security.)

Acquisitions don’t help in this regard either (yes you McAfee and Symantec; those acquisitions make your products harder to use, more complicated, and more fragile…).

On a related note, security just as a function inside a business (cost, security vs convenience, risk…) is becoming more fascinating to me than just the technical defender vs attacker mode. Before even doing any security work, there is this huge struggle to actually get an organization to start!

Regards,

Dave

This is a fun series. I am looking forward to reading the rest.

Kevin

It was one of those events where I simply responded and put the fire out. But a few hours, and a few days later, I realized it could have been worse (and bad).

But it wasn’t. Everyone is good…

As someone who has had to manage a project with people who had vastly different personal/work styles, I hear your frustration. And as an introvert myself, I’ve also been in situations where my own personal style needed some adjustment to fit that of the team or work environment. It’s not always easy changing the way we interact; and it’s doubly hard to manage other people who are not meshing well with the rest of the group or the company in general. It sounds like your approach – to coach the individual on how he could be more effective in his communications and work style – has had limited success. I’m unclear on whether this person is your direct report, or whether there might be other managers who he works under. One idea that occurred to me was to enlist the help of another manager or supervisor in helping coach this person. It sounds like this person has a lot of enthusiasm for the project, and that he’s highly invested in its success. That’s a good thing – someone who has no investment in the work is not going to be motivated to change.

Thoughts from anyone who’s been in this situation before, and how they handled it?

I’ve worked to educate him on the style differences of the individuals on his team. But it has been slow going. Having been in these situations before – if the environment that individual works in doesn’t improve the introvert will simply leave. As I am considering doing.

For what its worth and from recent experience, Auditors (External & Internal) are moving to a common risk based approach and I am seeing a trend where they are applying CoBIT as their framework for their review. I am not recommending every organization adopt CoBIT or that it is a one size fit all, but if you want to get ahead of the curve, I would recommend you identify the controls/processes that would benefit & fit your organization, implement them, and assess yourself against CoBIT’s assessment guidance.

Nice to see you writing. Keep up the good work!

-Mike
P.S. Got my CISA recently. Welcome me to the dark side.

I just purchased the IAPP Foundation Companion Course Book + DVD (happy to share with you at a later stage).
The IAPP Foundation Companion Course Bookhas three main sections:
1. Introduction to Privacy – Common Principles and approaches
2. Info security – protet and safeguard personal informarion
3. Online Privacy – Common Principles and approaches

To be honest, I am struggling with section 1 (Introduction to Privacy – Common Principles and approaches).
Do we have to memorise all the slides and its boring/dry law theory type content to pass the Foundation Exam?
Its too confusing and all the laws appear to be the same.

Patrick, what would you say would be the EASIEST and less painful way to prepare for the CIPP Foundation Exam
I dont know what else I can do, any suggestions would really help!

Please email me on lavinde@gmail.com your thoughs or opinions or suggestion in helping me pass the Foundation Exam. Thanks!.