I absolutely enjoyed the insight shown by Thomas Wailgum in his recent article “How TJX Avoided Wall Street’s Wrath“, mostly because I have long been in complete agreement with the premise.

With respect to security professionals, unfortunately, TJX now appears to be “the one that got away.” Let me explain, with tongue planted firmly in cheek.

If you’re in the business of providing discount items and the economy is a little weak, then business will be good. Apparently, it won’t matter that you’ve had a mishap or two with the data entrusted to you. It has always been my contention that only a small minority of people really understand the impact of stolen personal data and, even amongst most the people who do “get it,” the theft of nearly 100 million records of personal data is almost meaningless in its enormity. The victims are worried only about one record — theirs. Either it got stolen or it didn’t. And, if it did, it’ll get abused or it won’t. And, if it does, there is an ingrained belief the credit card company will “take care of it.”

Besides, there’s a huge sale and my niece needs galoshes — the green ones that look like frogs.

Yes, I believe that, as a rule, people care about the persona of the organizations they patronize. On the other hand, I believe we are at a point where the idea that “Stuff happens” because “Hackers did it” has seeped into the public consciousness much more deeply than “It’s the big, bad conglomerate’s fault.”

Virtually everyone can feel outrage at accounting scandals and multi-million dollar salaries and insider trading and so on, especially when you’re clipping coupons to make ends meet. On the other hand, virtually everyone had been impacted by “hackers.” Phishing, spyware, malware, malicious web sites, Internet scams, spam, MySpace worms, fake wireless hotspots, lions, tigers, bears — everyone has felt the sting of “the bad guy.” I claim that for Mr. and Mrs. Average American, it’s almost natural to feel a little sorry for TJX, to feel a camaraderie even, like “Hey, welcome to the club.”

Sure, we all believe they should have done more. On the other hand, I shouldn’t have clicked on that email attachment last year. I’m quite happy with my physical attributes, but it really sounded like a good deal. And that Nigerian gentleman sounded so sincere. And who doesn’t want a few new MySpace friends. We all make mistakes, right?

But what about those of us in the consulting business who have to convince organizations to put their trust in us. They have to believe us when we say that not spending on {data|information|application|software|IT} security can have intolerable business consequences. TJX would’ve made such a great example of just what intolerable really means — a veritable poster child for “See! I wasn’t kidding!” And now it’s ruined.

Okay, I don’t really want their stock to tank and have thousands more people affected. On the other hand, the least TJX could’ve done was fire a wing of executives so they could serve the consulting industry as an example in endless PowerPoint presentations for decades to come. (I still occasionally see technology demos that claim things such as, “And this could’ve even stopped the Morris worm.”) Now, we’ll have to go out of our way to omit TJX. We can’t bring up an example where nothing that bad really happened — for the organization, not the people affected by the thieves, of course. Now, instead of answering the question “How do we prevent this happening to us?”, consultants will have to answer the question “How do they get out of it so easily?”

Yeah, I’m sure it was rough in their executive suites for a while, but I’ll bet everyone is breathing easier now, walking around saying, “Woo-Hoo, we didn’t pull a CardSystems!” TJX has a very respectable 5-year stock climb, including three splits, and the current trade price is solid. Would they prefer to have invested a little more in IT security? Of course. Would they prefer not have unplanned millions in expenses? Of course. Do huge, unplanned expenses happen to large companies with some regularity? Of course. This one is special to us because we have some insight into how relatively easily it could have been avoided or detected, but for many, it really is business as usual.

My previous post sparked comments from Mike Rothman, Alex, Christofer Hoff, Arthur, and perhaps others I haven’t seen. I sincerely appreciate everyone’s considered feedback. In this case, the feedback was to tell me I’m off-base on terminology, and that’s all good. I’m happy to take lumps when I mess something up.

I really meant it when I said, perhaps unclearly, that I was talking about the meaning of information security “risk management” as the activity occurs in most organizations today, not any textbook definition of risk management and certainly not any definition that uses words like “exact” or “right.”

Is that better definition and more precise activity a good North Star? Absolutely. Do you tell an organization that is just learning and applying a subjective skill that if they don’t do it perfectly, they’re doing it wrong? Do you tell an organization that is doing something that works for them that they’re doing it wrong because it doesn’t match the textbook? Not if you actually want to be helpful.

The crux of the following screed is that purist “risk management” and the information security “risk management” that is (not could or should be, but is) practiced in the day-to-day business world are currently distant cousins that may meet in the future. I also feel this is the perfect time to trot out the old Yogiism that, “In theory, theory and practice are the same. In practice, they’re not.”

Many of the fundamental information sources that organizations are turning to today give no prescriptive guidance at all on risk management. The information security drivers don’t help much either. By way of example, the PCI audit procedures recommend that reviewers “Verify that the information security policy includes an annual risk assessment process that identifies threats, vulnerabilities, and results in a formal risk assessment.” FFIEC guidance for financial institutions desires a “multidisciplinary and knowledge-based approach” that identifies “all reasonably foreseeable threats.” This gives organizations no guidance at all and, after they have caused problems, all threats are reasonably foreseeable.

In my opinion, the common definition of information security risk management in the world today is the set of activities that is preventing me from failing compliance and examiner audits, that is streamlining my security operations (for better or worse; I don’t know because I don’t know how to measure it), and that appears to be reason I am not suffering even more security breaches. Again, there are always enlightened organizations that are doing more and better, but they are the minority. There is no common yardstick, no well of enlightenment. If FFIEC, Basel II, SOX, PCI, and assorted other examiners and auditors see a recognizable security program that is producing good results, then by definition whatever these organizations are doing is good “risk management.” Likewise, if I’m not suffering breaches, then I have good “risk management” in the eyes of those whose opinion I really care about (e.g., people who buy my stuff, can fine me, or can put me in jail). Call that “information security” if you want (and so it is), but saying it’s not risk management is just po-tay-to, po-tah-to.

I have my understanding of the textbook and “perfect world” definitions of risk management. I usually cast risk management as the process that starts with risk assessment. This, of course, is a catch-all term for analyses of business goals, threats, assets, event frequencies, downsides, and so on. We also need information on vulnerability, risk appetite, internal and external mandates, and so on. Some good risk models applicable to the target environment help, too. Risk management as a process then works through decision-making and continues with activities directed at risk avoidance, risk reduction (whether through reduction of loss frequency or loss severity), risk transfer, and explicit risk retention. Lather, rinse, and repeat in an ongoing “it’s a journey, not a destination” sort of way.

“Proper risk analysis,” as Alex put it, “can’t mean unnecessary controls.” I interpret this the same as I would interpret that “proper” medical care can’t produce incorrect diagnoses and “proper” maintenance can’t ever damage a vehicle. In other words, there’s no such thing in any practical sense. Smart people trying to do the right thing with the best of intentions and the best of education mess these things up all the time. Even at Harvard, someone graduates last in each and every class.

“Proper” rarely happens in the field. Proper risk management costs too much and requires to many propeller-heads to make it go. Anyone doing “proper” (full, complete, accurate, perfect) risk management would know enough not to spend the money it takes to do “proper” risk management. While accurate conclusions are crucial, very few, if any, information security decisions require that much effort or that much precision. With all due respect, I’ll wait while that sinks in.

Yes, I suppose I am dealing with some aspect of “issue management,” to throw yet another term at those activities organizations engage in to ensure their networks and applications are appropriately secure. The “issue” is “I don’t want to overspend, but I also don’t want to be the last one to do some security thing because I don’t want to explain to a jury why I’m the only organization not doing something that might have prevented a breach.” Further, the “risk tolerance of the data owner” is often of little consequence since data aggregation that increases sensitivity, public perception, and a variety of other business problems often take “risk” decisions out of the data owner’s hands.

With respect to “If your definition of risk is correct, and if your analysis is good, then all that is left is for the decision maker to figure out how willing they are to lose money,” this doesn’t happen. Even with terabytes of actuarial data, insurance companies can’t make perfect longevity predictions and odds-makers can’t reliably predict the Super Bowl winner in October. And these are really smart people, with really cool technology, with millions of dollars in backing, and the opportunity to make billions off a good decision. In other words, they’re *really* motivated. Does anyone really believe the average CIO and CISO stand a chance of having a “correct” risk definition and “good” analysis?

As to the idea that you can’t overspend because “the data owner expends only the amount of resources they are willing to allocate to reduce possibilities to their acceptable level,” well, again, I’m stymied. There’s no response for such Pollyanna thinking. It’s like a having a doctor from a world-class hospital telling a M*A*S*H surgeon to just “do it clean, quiet environment and it’ll be okay.” For example, what if the data owner postulated above is willing to spend $1B on a $1M problem? Exactly.

Activities correlating to “done correctly” and “can’t overspend” and “perfect data” and so on only happen in textbooks and fabricated business school case studies.

Information security risk management in the field is an ugly business. It’s not a matter of “when done properly” — it isn’t. It uses gut instinct for fuel and eats academics for lunch. Sometimes the process is too ethereal and we get bad decisions and too few controls. Sometimes the process is too grounded in activity and we get bad decisions and too many controls instead of more thoughtful analysis. Sometimes, bad things like public data breaches never happen even to the goofiest organizations and, sometimes, bad things seem to happen over and over even to organizations with thoughtful, resourced, and active risk management processes. It happens.

To address Hoff’s contention, I’m not “making excuses” for it; I’m documenting it. Clearly information security and risk management are not the same thing. And, to a geologist, sculptor, or someone refinishing a kitchen, marble and granite are also very different things. To the average person needing to prop up a wobbly business process, however, they’re both just rocks.

“Risk aware” organizations do spend better, but they still end up buying the same basic information security technologies as everyone else because that’s all there is. Where I see them spending more pragmatically (the perfect word here) is in training and in configuration and use of technology, which is truly a good thing. These are everyday blocking and tackling activities at most organizations. Where risk awareness truly benefits an organization is in creative areas such as software development. Thoughtfully applied security in the SDLC of an application-driven organization (think ISV or large brokerage) will result in much more overall net goodness than another internal firewall or blocking ZIP files at the Internet boundary.

“True risk management” is indeed a wonderful tool and I will always push organizations in that direction. The progression from raw art to even a glimmer of science is still a long road for information security risk management.

As to a “proper” definition of “risk management,” I spent years bemoaning the change in the definition of “hacker.” It was once a really useful word that described a true artist with code and equipment. Now, it describes any many manner of computer-based criminal activity. I wish you better luck preserving a classic definition of “risk management.”

Technorati Tags: risk management

IT controls. Corporate governance. Decision support. Right-sized spending (another phrase I thought I coined, but I see it gets three hits in Google). These are all part of the all-too-nebulous activity often referred to as data security risk management.

Let’s put a stake in the ground on what risk management means. I’m not referring to how it’s defined so much as what it actually means to business. Risk management means there is a thought process that includes ensuring the right people with adequate skills are given useful information and actually decide whether to do this or that to more effectively achieve security goals. Something like, “The available data indicate that path A at price B mitigates problems C, D, and E, but causes problem F, while path Z at price Y, mitigates problems C, E, and X, but causes problem W. What’s your decision?” Or, as happens much, much too often: “Hackers, phishers, and insiders…oh my, what are we going to do?”

Everyone makes dozens, hundreds, or perhaps thousands of risk management decisions every day. These are parents, doctors, lawyers, truck drivers, and everyone else, including CEOs, CIOs, IT security personnel, software architects, developers, and so on. Some people have good gut instincts, shoot from the hip, and end up with decisions that only occasionally burst into flames. For my risk appetite, that’s too little risk management. Others wait for every possible scrap of data, agonize over the possibilities, and end up with decisions that only occasionally aren’t completely overcome by events. That’s too much risk management.

The impact of too little risk management is usually too few security controls and, therefore, too much unpredicted expense in a variety of areas: incident response, litigation, and recovery, to name a few. These are often the result of public things that can have lasting effects on brand. This is easy to understand.

The impact of too much risk management is usually too many security controls and, therefore, too much predicted expense in a variety of areas: hardware, software, tools, people, processes, and so on. These are all internal things that can setiously impair agility, efficiency, and overhead, and this is usually much harder to understand.

Which is worse?

Let me clarify that I’m being a little fast and loose with “too much risk management” above. In my experience, the problem is almost never too much “risk management,” it’s almost always too much security fabric resulting from a fixation on or over-thinking of each and every security issue, whether applicable or not, combined with a natural tendency to equate activity with progress. As a consultant, I’ve heard some form of the following dialog hundreds of times: “What are we doing about the security problem I’ve heard about?” followed by a confident “We have people choosing A as we speak.” More security controls, especially generic plug-n-play things, does not automatically mean less risk, but it sure is highly demonstrable activity (to managers, to auditors, to examiners).

I think we’ve seen the impact of too few controls all too vividly recently. Just type “data breaches” into your favorite search engine and you’ll be inundated with examples. And that’s just one example of one kind of bad outcome associated with too few security controls.

But, too many controls can also have a direct impact on the very core of an organization. To illustrate, let’s turn to the great triad of operational excellence, product leadership, and customer intimacy.

A company whose success is based on operational excellence requires quality goods at reasonable prices. This requires very efficient operations, excellent supply chain management, and practically flawless execution. Superfluous security controls, whether in people, process, technology or embedded in software, may not prevent flawless execution, but it certainly seems like a good way to slow down a just-in-time supply chain (e.g., we quarantine all email attachments for 12 hours) and disrupt operations (e.g., by implementing ultra-fine-grained entitlements where it just isn’t necessary).

When your success is based on product leadership, you are probably innovating constantly and spending like mad to build brand. Staying ahead of everyone else requires great design and development, a fantastic knowledge of your customers, and quick time to market. Security controls that have no material relationship to any practical attack can easily derail any product process that relies on agility (e.g., SDLC security tools and processes that check for things that have no matching threat slowing down product cycles).

If customer intimacy is your key to success, then you are likely to be extraordinarily focused on customer service, with lots of choices that can be tailored to customer desires. Here you will have to excel in customer management, have product and service delivery that exceeds expectations, and engender client trust. Too few security controls (”Hey, I’m this person you’ve never met, please reset my password.” “Sure thing!”) can certainly end a client relationship, but so can unnecessary security controls (e.g., three personal questions, identify an image, and last four of your SSN just to activate the Forgot My Password page) as it also clearly indicates that you just don’t know what you’re doing. Where it’s obvious that you don’t understand the appropriate intersection between your risk management, your customer’s risk appetite, and the actual risk, a trusted partnership is pretty much out of the question.

All in all, too few security controls is probably the greater of the two evils. On the other hand, it’s probably the easiest to remedy. Even if you do no risk management at all, if you have the money to purchase and correctly install most of the major security technologies out there, the shotgun approach will in fact reduce security risk. You’ll never know if you’ve done enough or if you’ve overspent, but you’ll have a story to tell to the masses. On the other hand, a thoughtful security approach based on sound risk management will give you a story to tell to savvy customers and increasingly well-educated auditors and examiners.

Technorati Tags: risk management

As I get back into the risk management arena after a sojourn in knowledge management (mainly designing knowledge-driven offerings and monetizing the associated intellectual property), I find yet another example of “the more things change, the more they stay the same.” I think the executive view of information security risk management techniques as viable decision support tools has come a long way, but the complaint I hear from most executives is that even the simplest risk modeling appears to take a very long time.

I find that information security risk management still has the unfortunate combination of being a lightning rod for snake oil in the marketplace, being a real polarizing and dogmatic topic that often defies reasoned discourse, and being something that the average person handles by gut and not by numbers. Practitioners, academics, and managers alike bemoan the scarcity of actuarial data on which to base decisions. And, just to round out the issues list, any given group of people will quickly fall into its own set of terms and meanings, making it very difficult for any two groups to have short, interesting arguments that actually advance the knowledge base.

In my recent reviews of what’s going on in the world, risk modeling exercises related to application security seem to stretch on for two primary reasons:

1. An obsession with knowing every “threat”
2. Not having a good rule for deciding when a threat-vulnerability-control coupling deserves no more scrutiny

What I’ve evolved over the past couple of decades to reduce this work is something I’ve called “Looking for zeros” and “Looking for ones.”

In my experience, knowing the exact threat (i.e., combination of attacker, attack, attack path, resources, and some intangible things such as motive) is often irrelevant. I call this “Looking for ones.” For example, if a particular attack always works (e.g., cross-site scripting in a particular web form), then it likely matters not whether the attacker is a national government, a terrorist, a criminal, a script kiddie, or someone who accidentally pastes HTML into the field — the “success value” for this attack-vulnerability tuple will always be ‘1′. Knowledge of the attacker might give us a bit more information about what he or she might be ultimately trying to accomplish, but the decision to fix the problem should already have been made.

Similarly, this is why we decompose threat, vulnerability, assets, and other things into constituent components. I call this part “Looking for zeros” and it works really well. As soon we find a ‘0′ for a material aspect of attacker, attack, attack path, resources, motivation, threat frequency, feasibility, accessibility, susceptibility, vulnerability prevalence, asset value, event cost, downside, caring, and so on for the various dimensions of “bad stuff happens,” then that scenario is over and we can move on. Again, even given a national government with lots of resources and a zero-day electronic attack that really works, we just don’t care if the attack works only on WebServerA and we’ve deployed WebServerB, or if the attack path required (e.g., site must be using JSessionID), or whatever else, simply doesn’t apply to us.

When we bring into the mix controls (for which we reason about preventive, detective, corrective, and deterrent values), then we try to kill off entire attacks (e.g., timeouts that prevents script kiddies doing half-open TCP stuff), attack paths (e.g., Internet routers that allow incoming packets with RFC 1918 addresses), motivations (e.g., dye packs that render stolen cash unspendable), and so on all at once; seldom should the IT or software development world try to work off “threats,” and specifically threat agents (attackers), one at a time. That just takes too long.

A comprehensive and holistic view of what makes “risk” happen will always make risk management much more efficient and make the results of risk management much more usable in day-to-day decision support.

Technorati Tags: risk management, threat modeling

(This is part three of a three part series. Part one is here and part two is here.)

G.I. Joe and his friends (e.g., http://en.wikipedia.org/wiki/G.I._Joe) gave cartoon addicts in the mid-1980s United States a series of television public service announcements. The cartoon kids being given the lesson invariably responded with “Now we know!??? to which the G.I. response was always “And knowing is half the battle.??? Unfortunately, we often forget that knowing is, in fact, only half the battle.

So, let’s you say have some awesome training materials (slides, eLearning module, video, or whatever) and training day goes beautifully. Everyone now knows exactly what they’re supposed to do. How are you going to get them to do it? Periodic and direct reinforcement are key to real behavior modification.

Start by ensuring that reinforcement messages are pitched at the right level. If you want people to learn the theme, then repeat the theme, act out the theme, and make sure the theme is in their words. Don’t start with “It was the best of times, it was the worst of times??? to explain the quarterly software bug report trends to executives (although that would be pretty cool) and don’t tell testers to ensure that the “trend in bug reports must have a positive impact on EBITDA.??? For example, tell people who work with software bugs about bugs, and their bosses about trends in bugs, and their bosses about trends in application quality, and their bosses about trends in the application portfolio, and so on.

Don’t start from nowhere with your students. I believe it will be somewhat uncommon for you to be teaching people something entirely new (imagine the blank stares in the first calculus class sometime around 1704 or the first Fortran class in 1954!). Even after training, continue to work diligently to identify the gap between what the students are doing and what you need them to do. Then, use that as a stepping stone to build upon your audience’s existing knowledge and skill. Continue to remind them of what they already know and explain to them what you want them to do that’s extra or different. If you make it sound like they must start from scratch, or make them cover old ground, or if you omit some key knowledge, you’re unlikely to get any positive behavior change at all.

Make sure your learners continue to be motivated to learn and change. Make it part of their objectives. If you took the time to train someone on how to do something, you should check to see that it’s getting done. If the students know you’re going to check, they’ll be a little more motivated to learn it and do it. There are few activities more frustrating than standing in front of a class all day, teaching important stuff that the students really need to know, and having them stare vacantly ahead (remember, you can make them put away their PDAs, but you can’t make them like it). A little positive motivation goes a long way.

Unfortunately, so does a little negative motivation. Just as organizations get peeved when some new law generates an unfunded mandate that’s all stick and no carrot, employees get a little perturbed when any kind of “do it or else??? message is sent their way. While this kind of motivation may work in the short term, it’s just not worth it. In many organizations, the employees are the company. For consultancies, independent software vendors, application houses, and so on, the biggest corporate asset—the employees—go home every night. In a job market that offers some easy mobility, don’t give them an unnecessary reason to go somewhere else.

The best way I’ve found to ensure ongoing performance is to institutionalize the activity as the way things are done. Don’t make people have to go out of their way to do the right thing. If you’re training software architects to do threat models and architecture risk assessments, then account for that time in development projects, give them the tools they need, and make it’s part of the software development lifecycle. Ensure there’s not only prescriptive guidance for doing it, but that the results of these activities are part of someone’s metrics and the software governance dashboard. It’s the same for teaching developers to improve their development patterns, teaching testers to perform non-functional security tests, or teaching executives how to institute software governance.

Let me mention metrics once again. If you took the time to train someone how to do it, then “it??? should probably be part of the metrics that someone tracks. If you taught a roomful of testers how to do some inside?out white-box security testing, then you should probably keep track of how many software flaws they catch as part of this process, along with some trends. You might even want to, for example, track which code bases are exhibiting the most problems and track that back to the composition, training, and automation support for the various development teams. If you can discover which teams are routinely making similar errors due to, say, having a broken unit testing process, everyone wins.

And, by all means, find and encourage the stars. The people who really get it should be groomed appropriately. They may be the next crop of team leaders or managers. If nothing else, get one of those individuals to improve the course material or even to teach the next class.

I certainly don’t mean that you should ignore the stragglers. If some folks have attended training and have received some follow-up attention and still don’t get it, they may simply be in the wrong profession. That’s always a tough decision, but I find it’s usually best for everyone. If someone has arrived at a position where they are failing, even with training and attention, kindly help them find a place where they can be effective. And I do mean kindly; that person may be your boss someday.

Someone must follow up with the instructors as well. Do post mortems after each class and give constructive feedback. Ensure each student completes a feedback form. And don’t ask those silly questions on the form like “Did you enjoy this class????; that’s just useless. Ask things like “Did you understand why you were here and the problem we’re addressing???? and something like “Will the information given to you today actually improve your day-to-day performance????. Of course, you also want to ask things such as “Did the instructor communicate in a clear manner???? and “Do you feel this instructor truly understands the material???? and stuff like that.

As some parting advice, keep in mind that it’s not just the individual student that must get something out of the class. For every course you give, someone is paying a hefty bill. Whether you’re a consultant charging by the hour or an internal expert delivering some training to your friends, someone’s paying the price for you and for those students to not be working. That economic buyer needs to get something for spending that money (real money, opportunity cost, or whatever) if you expect it to happen again. Ensure someone comes up with a way to measure training success, that they actually measure it, and that they let the stakeholders know how it went.

“Now we know!???

(This is part two of a three part series. Part one is here and part three will be posted on Friday.)

“Keep away from people who try to belittle your ambitions. Small people always do that, but the really great make you feel that you, too, can become great.” - Mark Twain

My guess is that, on any given day, thousands in the world-wide work force attend some form of corporate training. It could be software governance training for the pointy-haired bosses, how to use a juicer for department store workers, or keeping fingers away from the business end of a chainsaw for lumberjacks, but it’s training nonetheless.

The training might be delivered in the form of a short video, some eLearning module, or a class led by an instructor. It may have an integrated quiz, or require you to go do some additional exercises, or be taught one day per week for some period of time, or whatever. The possibilities aren’t endless, but there are a fair number of them.

Beyond the training requirements discussed previously, you also need to figure out what training styles works for your people in your environment. Having said that, I think there are a few rules that are fairly universal:

• Be as formal in your presentation method as you need to and then just a touch more. I find that too little formality in training is far worse than too much. Too little formality is often perceived by students as “We had to do this training to check the box, so let’s get through it.???
• Stick to your schedule. If it says “Start at 9am,??? then start at 9am. If you’re breaking for 10 minutes, get started in 10 minutes. To some degree, we all want to wait for that last straggler. Don’t do it; you’re just penalizing everyone else who had the professionalism to be punctual. Class management is always hard. You may in fact be the tech dweeb presenting to a room full of executives. On that day and at that time, however, you are in charge of that class; act like it. Professionally. Doing it unprofessionally is definitely a career-limiting move.
• Use eLearning (or computer-based training or whatever you call it) for awareness and to give basic skills to the masses. It’s very important, however, to use instructor-led training (ILT) for teaching important execution skills to your practitioners. It doesn’t matter how many times you watch the video of the expert performing the trick, even in slow motion with arrows and explanations, most people still won’t learn a new skill that way.
• Make sure you can actually teach the material in the time allotted. That usually means you must ban the typical distractions. That includes Blackberries, laptops, various PDAs, and so on. Yes, even for the executives. Stop the side conversations, keep everyone on topic, and tell people who have long, rambling, just-don’t-get-it questions that you’ll get back to them after class. When you rush through the last 20% of the material to stay on schedule, students feel cheated. On the other hand, if you scheduled two hours for a thirty minute class, that’s a completely different screw up and your students will likely be just as irritated.
• Give people sufficient breaks so that they don’t have to violate your other rules. I find that most people, including the instructor, can concentrate only for about 90 minutes at a time. For really dense stuff, that time might be reduced significantly so partition your material appropriately. Also, ensure you provide what people typically want during breaks: snacks, beverages, easy access to a restroom, and a network connection. I imagine millions of person-minutes of training are lost every year just because someone didn’t think of spending $20 to set out some mid-morning and mid-afternoon snacks.

I argue with myself, sometimes successfully and sometimes not, over whether the material or the instructor is the most important part of technical training. Today, I believe that it’s far more likely that a good instructor can save truly awful material than it is likely that a bad instructor will successfully deliver even the best of material. If you’re good at getting a class excited about a topic and you can talk about the topic authoritatively, you’ll rise above the material.

Let me emphasize that more. If you’re the instructor, you must know more than what’s in the training materials. If you can’t go off-script even a little, you’re the wrong person for the job. Excuse yourself graciously rather than wasting everyone’s time. The amount by which you need to go off-script will depend on the skill level of your students, but you certainly should be able to answer questions about rationale, goals, why another way isn’t the right answer, and how it would be done in a scenario somewhat different from the one presented.

When going off-script, it would be great if you can do so in three ways:

• Visual stuff, for the people who learn from what they see. For these people, you must be able to provide visual aids. Draw a picture on a white board, or make a hand-out, or have an exercise where people draw out the process, or whatever. Always give the visual people something to imprint on.
• Auditory stuff, for the people who learn from what they hear. For these people, it’s not just what you say, but it’s also how you say it. They’ll pick up on subtle clues in your delivery that can sabotage your purpose. In other words, be able to be excited about digging deeper. If you think Section 4 is boring, you’ll present it that way, and they’ll believe it. Be interested, not just interesting, and give the auditory people something to pick up on.
• Kinesthetic stuff, for the people who learn from what they feel, physically or emotionally. For these people, you have to get them involved in the problem and the solution. For some, that will be an emotional connection and for others that will be some manner of hands-on demo. Whenever possible, let the kinesthetic folks touch something.

Good speakers always have good notes from which to speak. Don’t be afraid to have a cheat sheet of important points. And don’t be afraid to lecture. Just don’t do it the whole time. Give people the motive, the rationale, the philosophy, or whatever it takes to get them involved in the problem. Then switch to some practical visual, auditory, or kinesthetic stuff to show them how to execute the solution.

Now, I’m not talking about any of those group hug things, because there are also introverts and extroverts in the world. Making an introverted, visually-oriented person do role playing as part of training is just torture. They’ll hate you forever. On the other hand, not only are the extroverted kinesthetic folks excited at the prospect, they’ll show up with streamers and brownies and hold annual reunions. Sigh.

When you’re presenting technical training material, whether as part of ILT or an eLearning quiz, make sure you ask some open-ended questions. This is a great opportunity to let the students use their own words to tell you what they’re thinking. By listening carefully, you’ll be able to tell who really gets it and who struggling to keep up. That will help out a lot in an ILT setting when you’re making teams for group exercises. (Hint: Don’t let all those struggling students end up in one group.)

Training creators and instructors must remember that there will be students with whom you have no shared experiences. They don’t know Babe Ruth, don’t get your Simpson’s references, and are quite alarmed at your claims that sometimes you just need to “kick some ass,??? “gore some oxen,??? or “kill some sacred cows??? to get what you want. This is not my soapbox for political correctness; this is just my experience telling you that teaching via analogy, colloquialism, and local cultural reference often results in a lot of blank stares (like with my upcoming G.I. Joe reference). Life may be like “a box of chocolates??? for millions of people, but there may be billions who’ve never even seen a box of chocolates, much less a Tom Hanks movie.

Take the time to tell students what you want them to do when they leave the class. Don’t just talk around it. Really lay out the activities they should undertake and the changes that should occur when they do. Think of it like writing a software requirement. You can write “The system shall…??? all day long, but until you actually show the person who has to do it a use case or a scenario or a drawing or something, there’s virtually no chance of getting the behavior (or code or process or whatever) you intended.

Remember, our brain is likely to simply reject any message that it can’t process. Why might that processing not happen? In my experience, the top causes are:

• For new skills, you’ve provided no frame of reference for the student. There no place to latch onto and say “Oh, this is like that other thing I know how to do, only different.???
• For extensions to existing skills, there’s too big a gap between the student’s skill and what you’re teaching, and you’re not providing enough framework for the student to make it over. Either you jumped right into the guts of the material without adequate preamble or someone did a poor job of choosing the students.
• One or more of the material, the presentation method, or the instructor is simply lousy. If the materials seem good and the method is well thought-out and constructed, then it’s probably the instructor. It’s impossible to describe all the ways training material can be lousy, but one of the most prevalent is that it’s just stale. Teaching the same old stuff year after year without ever updating it is just silly. As for the instructor, not everyone is cut out for teaching. I’ve seen some real world-class technical experts do indescribably horrible jobs in front of a class, just as I’ve seen non-practitioners (never actually did this work for money in their lives, but truly understand the topic) teach wonderful classes.

By the way, don’t send the wrong subliminal message with your training. If you’re having a session on the importance of corporate intellectual property, ethics, and how file sharing is wrong, you probably shouldn’t sprinkle some “borrowed??? Dilbert, Calvin and Hobbes, and Far Side cartoons in your presentation, while playing a downloaded Van Halen soundtrack in the background. Duh.

Trust me, if you really care about the training you’re giving, as well as the behavior you’re trying to encourage, it will show in the material and in your delivery. This energy is contagious. Chances are that you want these students to stretch themselves in ways that are new and possibly even undesired. Give them every opportunity to succeed. If the training appeals to their senses, they’ll be more engaged and they’ll retain more. If the training appeals to their sensibilities, they’ll be more engaged and they’ll actually follow through.

(This is part one of a three part series. Parts two and three will appear on Wednesday and Friday.)

The beautiful thing about learning is that no one can take it away from you. -B. B. King

We’ve all been to training. More specifically, we’ve all been in training where we were bored to tears, not because we were already experts, but because there was just no connection between our individual learning style, base knowledge, interest level, or job goals and whatever it was the instructor was doing. Invariably, however, there will be a few people in the same class who feel this training was the best they’ve ever attended. Two days later, you can’t even remember what the course was about and two months later others are still quoting the instructor. Why does this seem to happen so often? In my experience, that it was effective even for those few people was probably just luck.

When you’re thinking of making or commissioning some technical training, stop. Completely. Not one of those rolling stops you do at a stop sign in the middle of nowhere. Sit down and take a deep breath. Now, write three complete sentences:

• “This training is appropriate for people who…???
• “In this training, you will learn how to…???
• “After this training, you will be able to…???

If you cannot specifically and succinctly define your audience, tell them what they will learn, and describe how their new ability will benefit the organization, you’re definitely not ready to start building training. This would be just like writing code without requirements and you’re likely to achieve the same spectacular lack of success.

If you need to do a formal performance needs assessment to get requirements because you’re teaching someone a life-or-death skill (e.g., how to disarm landmines in the field), then do it. On the other hand, if you’re teaching employees the basics of physical security for the average office building, you can probably just survey the existing literature to get your main points.

I understand that there is some training that must be given to everyone regardless of their interest, skill level, learning style, or anything else. Examples might include employee orientation training, sexual harassment training, security procedures training, and so on. I feel it’s easy to show how poorly the average one-size-fits-all training approach has worked in these areas, especially when reduced to a poorly-scripted eLearning module or abysmally-acted short film.

Even after you get a good course description and, presumably, the right audience, tell people right up front what they’re going to learn in your course. Don’t make it something cheesy like “Today we’re going to learn about software security.??? That’s just silly, even if it’s for a general software security course. Tell them something useful like “Today, I’m going to show you how to generate crypto seed values correctly in various languages and technology stacks. By doing this correctly, you will help the company meet ongoing regulatory compliance requirements.??? If it is the general course, tell them something like “Today, I’m going to give 10 reasons to care about software security and help save millions of dollars.???

Well, that’s different. Now I know why I’m here and how what I’m going to learn will really help; it’s not just some flavor-of-the-month exercise because it’s “time to shake things up around here.??? Continually reinforcing why this training is important, both during the class and afterwards, means you’ll end up not only with increased competence in the target audience, but, in this case, you’ll also end up with practitioners who are more business-risk aware. That’s a good thing. Why? Because now, they’ll ask themselves questions about “How does this affect the business???? and, when they don’t know the answer, they’ll go ask someone rather than just putting some code together. Give them the chance to do the right thing.

Remember, it is a significant task to get a diverse group of people to leave a room with the basics of a new skill (e.g., developers using certificates for mutual application authentication), with necessary knowledge (rand() is not cryptographically secure), or even with just a common awareness of a given problem (e.g., web application input validation is tricky). This is compounded when we let training creation wait until the last minute and then “throw something together??? or we “just use last year’s slides.???

The biggest evidence of such procrastination and lack of planning is ending up with training materials (e.g., PowerPoint slides) that are simply about the topic, not on how to do the topic. How often have you gone to a class guaranteeing to turn you into a practitioner, only to spend the majority of the time on vocabulary and concepts and fluffy cloud process diagrams! What a waste of time. Training about test process automation, for example, is something that you give to people making budgeting and resourcing decisions. Training detailing a method for doing test process automation is what you deliver to practitioners.

Speaking of planning, in my experience you have to budget about 100 minutes per technical information slide to create useful material that focuses on imparting a single important idea in a memorable fashion. This includes sufficient time for instructor and student notes. The instructor notes should be what the instructor says while the slide is being projected, along with any prompts for what to do, what to hand out, and so on. The student notes should include specific reinforcements, references, and related materials applicable to the information on the slide. This 100-minute block also includes internal review, discussion, and bootstrapping the first instructor.

I know 100 minutes per slide sounds like a lot, but if you’re spending less than three days to plan, draft, and complete one hour (about 15-20 information slides) of technical training (or any training that is telling someone how to do something), you’re probably messing it up. In particular, take the time to look for every group of words, bullets, or slides that you can turn into a real, accurate picture. Decorate the picture appropriately, but don’t make it so busy that it becomes an eye chart. Animate it whenever necessary to show how and when things actually happen. People will remember and refer to these pictures (because they can cut and paste them), but they probably won’t ever reuse some random set of bullet points.

This reuse habit, by the way, is also why it is universally idiotic to include on-the-fly sample code that someone just banged out for the slide; it’s almost certainly wrong, not secure, and against some policy and someone will be embedding it in some critical code module tomorrow. If they do that, it’s just as much your fault as it is theirs.

Another word of advice: Don’t have technical experts create the final training product. No, really. Even if you’re the technical expert and you think you know better. Trust me. The only exception to this might be when a technical expert is creating slides for very similar technical experts. Even then, run the slides by someone a level or two below and a level or two above “technical expert,??? as well as someone more skilled in training presentation, and heed their feedback. It’ll be a valuable experience and you’ll end up with better material that is less bogged down with jargon, with incomplete thoughts that presume too much historical knowledge, with acronyms that are never explained, and with words that apparently have a different definition on the author’s home planet. One hopes you’ll also end up with something that isn’t 100 slides of wall-to-wall words.

The long-term benefits derived from putting the required time and skill into building good training will far exceed the initial investment. Spend a little extra time on it and make your students happy to be there. Everyone will benefit.

Technorati Tags: training

I’d like to give a slightly different perspective on a topic John Steven talked about a few weeks ago (“Keeping up with the Jones’ Security Initiatives???).

Be a goose; don’t spend “10%??? just because it’s a popular number.

I spent the first four years of my career, in the early 1980s, in the Air Force. I worked as a systems programmer in the Pentagon and had direct responsibility for system security (Go Multics!). This was a timesharing mainframe with directly connected VT100 terminals in secure locations, so threat was fairly well understood. It was all about availability then, even though security was paramount. If the system was down, heads rolled. On the other hand, if some MLS control prevented the general from doing something he thought would be cool, well that was just tough. No one ever asked me, “Do we have the right level of security?”; it was always some question about specific vulnerabilities and how to remediate each one on a case-by-case basis. These were ducks.

As a defense contractor employee, I worked with dozens of classified and unclassified systems, some on the burgeoning Internet and some not. I performed virtually every kind of security review, pen test, IV&V, and tiger team you can imagine. No one ever asked me, “Do we have the right level of security?”; it was always some question about specific vulnerabilities and how to remediate each one on a case-by-case basis. These were ducks, too.

After 12 years in the commercial world, I’ve seen or worked with virtually every information security technology. And, although I gave up software development a long time ago and pen testing more recently, I still try to keep current. I’ve worked with hundred of organizations on thousands of security issues. In my experience, only in the last few years have some organizations begun to look past the individual assessment results and ask about their level of security and its overall appropriateness (first in financial services and later in other public companies). At last, a goose or two.

However, the vast majority are asking about it solely in relation to their peers. These organizations are not asking, “Do we have the right level of security????, they’re asking “Do we have about the same amount of security as everyone else, good or bad????

This is wrong thinking and here are two reasons why it bothers me.

The first is the large number of organizations that are insulted at the mere insinuation that I can “know them” even if I have years of experience and I’ve worked with other firms in their vertical, or even with other business units in the same company!

The second is that they’re right. You can’t really know a given organization just because you’ve worked with its competitors. I can understand implicitly the risk associated with their transaction processing systems, with their SOA framework, with their Internet-facing systems, with their overall approach to security, and so on. On the other hand, I really have to work with them to understand what drives them, what is the tone at the top, what decision will they make when push comes to shove, their risk appetite, where they will cut IT dollars first, whether they really are trying to act strategically as opposed to simply having a 3-year plan of tactical initiatives, and so on.

So, why would these organizations think that I can’t know them by working with their competitors, think they can know something about themselves by comparing furlongs per fortnight of security spending with their competitors?

Here’s are two admittedly loosely related stories:

I did my taxes a few weeks ago and was told by the application the percentage of tax-paying Americans who were “like me” in income and tax burden, with no real additional information. Were these families or single filers? Did we have similar kinds of deductions? Did we have the same cost of living? What did these comparisons mean? Duck or goose?

I went to my doctor recently and was told the percentage of Americans whose weight, cholesterol, and related items were similar to mine. Here, however, I was also told how each of these items factored into overall health. In gruesome detail, I was told about various mortality rates, stroke rates, heart attack rates, cancer rates, and so on until I simply wanted to nibble lettuce for lunch and stay out of the sun forever. But, still, did these other people have my heritage, my work and exercise habits, my eating habits, or anything else that made them like me? Again, duck or goose?

In the information security space, we’ve had (mostly by the analysts and the press) huge discussions about whether 10% of the total IT budget was the right amount to be spending on security. According to Forrester, that number has hovered in the 7.5%-9% range for the past few years. That’s good to know because it gives us a general guideline (which is all we can have in the absence of any real actuarial security failure data, but that’s a rant for another time). However, in multi-billion dollar corporations where a 1% difference in IT security spending could equal the annual revenue of many of small security firms, what does this percentage really mean? If one organization consistently spends significantly more than it’s competitors on hardware, data centers, and related IT items, should it necessarily also be spending more on IT security?

I realize these percentages are just guidelines, but they’re the kind of guideline a sharp litigator will latch on to. Remember that no one wants to be the odd man out. No organization wants to have to explain to some regulatory or law enforcement organization the possibly coincidental facts that it suffered a security breach and was also spending somewhat less on IT security than the average for their industry, or country, or whatever.

So, much like I am, I’m sure you’re wondering whether I have a point or whether I’m simply writing this at 4am because my allergies are kicking Claritin’s butt. My long-winded point is simple: We’re all the goose. Every single organization has its idiosyncrasies that make the 10% rule of thumb somewhat less than useful for anything other than selling research reports.

Organizations should spend as required to adjust risk to acceptable levels and realize that not all of that spending will be in IT security dollars. By and large, IT security doesn’t pay for governance, it doesn’t pay for attitude, it doesn’t pay for commitment for excellence. With these things being paid for elsewhere, the IT security budget may be lower and likely result in lower risk (i.e., improved “security???).

We shouldn’t dwell on the size of this ratio; we should worry about the environment in which it exists. A spend of 10% in an immature, ad hoc, no-vision company, probably means they’ve spent the entire 10% on point security solutions ranging from desktop AV to firewalls to IDS and so on. Which means they spent little or nothing on policy, training, proper tools for developers and testers, and so on. Which means they are an accident waiting to happen - 10% not withstanding.

On the other hand, a lower percentage spent within a mature organization that also spends to foster and reward good thinking will almost certainly produce lower risk. Sure, mistakes will still make it into production and there will be problems, but there will be much fewer of them, they will likely be of reduced consequence because the organization knew to look for the big problems and also had effective response capabilities, and the organization will learn and not make those mistakes again. They will make new mistakes, but everyone does.

Be a proud goose. Organizations must not be afraid to use good governance, good training, and good process to their corporate and competitive advantage. If you do good strategic things, you will achieve better security with a smaller capital outlay that doesn’t all come from IT security. Organizations must be comfortable with their risk management story, and their efficient spending, and be able to tell it to the market, to customers, to regulators, and, if necessary, to juries.

Technorati Tags: governance

(with apologies for complete lack of artistic merit)

feng shui governance
plan, influence, and conduct
policy for all

from boardroom to bits
everyone get on board
a single train forward

a balanced approach
harmonious existence
with stakeholders all

set tone at the top
the key of transparency
all must understand

solving all problems
a terrible goal to bear
just cut barriers

how to change things now
like escape from klein bottle
reverse of trip in

business objectives
publicly painted for all
now all can align

our key resources
named, owned, prioritized, staffed
requirements sketched

cooperation
embrace management’s vision
collaboration

internal control
believable proof for all
this is a good thing

need innovation
old way causes much sadness
delightful change now

who must get what done
true responsibility
good authority

what must get done when
relate business to people
and goal them quite well

when must it get done
everything can’t be first
true order defined

where does it happen
are all things prepared for it
measure twice, cut once

how to accomplish
training, coaching, mentoring
lead by example

why is it crucial
all must recite the drivers
to you and to me

it’s about people
enable them to succeed
show you care about them

expect and inspect
balanced scorecard works for most
dashboards are fun, too

you are not there yet
a continuous journey
goals ever-changing

quite learned you are
required knowledge deep inside
express yourself now

P.S. Although I though I was the first to use “feng shui governance” as a term, I noticed that there was a single hit in Google (a three-word GoogleWhack!) used by a Mr. Foldvary back in 1999 in a somewhat different context.

Technorati Tags: governance, doggerel

“We have long had death and taxes as the two standards of inevitability. But there are those who believe that death is the preferable of the two. ‘At least,’ as one man said, ‘there’s one advantage about death; it doesn’t get worse every time Congress meets.’”

~Erwin N. Griswold

Just look at them grow… they’re like weeds. Unfortunately, in this case it’s not a compliment for your sibling’s kids. This particular growth is in the data breach lists at Privacy Rights Clearinghouse, Attrition, PogoWasRight, and others. (And please accept my thanks for the time you all put into this public service; I apologize for not including you all by name.)

I have no doubt these disclosures represent the tip of the proverbial iceberg of data that have actually left the control of those to which it has been entrusted. I also have no doubt that we’ve been given this glimpse into the shoddy treatment afforded many of our most intimate personal details solely through some forward-looking state legislation (thanks, California, for helping to start a good thing in the U.S.).

Let’s just jump ahead of all this piecemeal personal information loss for a minute. (Did the WABAC machine have a “forward??? lever?) Let’s declare it not only inevitable, but also unavoidable, that, for each and every adult American, their name, social security number, top one or two credit card numbers, street address, date of birth, brief genealogy, and a few other interesting data items are known, collated, and cross-referenced.

But, not by legitimate companies like Experian, TRW, and Equifax. Let’s assume that individuals and groups who do not have our best interests at heart have all of these bits of information correctly assembled into mini-virtual-self-referentially-consistent identities, even if they have no “real life” information on the actual person (e.g., photo, current job, salary, type of vehicle, where your kids go to school, etc.). And, let’s assume they have the ability to keep this information current enough to meet their goals of acceptable cash flow for acceptable risk.

[Aside: Is this feasible? How many databases would I have to subvert in order to get most of this information? One at the IRS, one at a credit agency, one each at a few major banks, and maybe a few others? Remember, I don’t actually have to hack in, I can use social engineering, pay someone, coerce someone, steal the back-up tapes, and so on, and on, and on.]

What then? Is it the collapse of American civilization? I doubt it, but I think it would certainly accelerate some good things and some bad things.

The good things might include something like two-factor credit card use at all times (e.g., you have to show a [new government issue?] driver’s license for all card present credit/debit card transactions). But, what would have to change to allow card-not-present credit card transactions to continue to happen (e.g., most Internet orders, catalog phone orders, Chinese food orders, etc.)? What would it take for Americans to embrace single-use credit card numbers, for example? What parts of the infrastructure would have to change? How would we get and carry around these numbers? And so on.

The bad things might include a new state or national ID that would be required by the credit card companies in order to get a “secure” (whatever that would mean) credit card and a lot of high-end establishments that would start accepting only “VMCAMEXD Secure” for transactions over certain dollar limits or that meet certain risk profiles (e.g., buying for delivery to another country). A treaty with foreign countries could require that “secure” credit cards are the only ones accepted in some situations (e.g., buying a one-way plane ticket to the U.S.).

Beyond that, what would have to change at the IRS now that all SSNs are “public”? What about elsewhere in the Federal government? What would this mean to the Privacy Act? And so on. The mind reels, but it still feels like a good thought exercise.

For me, the question is not “What happens if someone else knows all the data associated with me?” The question is “What financially and socially acceptable capability will make it such that I can unequivocally prove that I’m the only me that goes along with my (now public) mini-identity data (e.g., credit card numbers, social security number, address, genealogy, etc.)?” And, in terms of requirements creep, I’d also like to be able to prove it without giving away my actual identity.

Thoughts? I hate to take you this far and not have something to offer, but I feel qualified only in asking the question, not in postulating an answer. And, of course, my follow-up question is “How are we going to make that software better than the software we have now????

Technorati Tags: data security, privacy