Identity Management in 13 Easy Steps
by Ioana Justus
If you were asked to throw a few million dollars out the window, would you do it?
If yes, let me know where and when – I’ll happily wait outside with my catcher’s mitt. More likely, the quick answer to this question is a resounding “NO”. Few circumstances would lead someone to literally throw millions of dollars out the window, down the drain, etc. Not a million dollars, not in a million years.
What about companies that, effectively, waste millions of dollars trying to implement identity management?
The sad reality is that many organizations trying to implement identity management do just that – waste big money – on the wrong technology, or even on the right technology that sits idle because it can’t be used as designed. Worse, some organizations look to even more technology to “fix the shortcomings” of their selected product. The end result is the identity management version of Frankenstein’s monster.
If you peruse the latest identity management articles from your favorite research company, you’ll find the same discussions over and over: How do we justify the cost? Why do so many companies stop at “single sign-on”? Why do implementations take so long? Why do implementations get halted mid-effort? What’s the true benefit of identity management? What’s the ROI? You’ll also find the same tired answers – whether in printed form, or at one of the many IAM conferences across the country: IAM saves costs at the help desk. IAM can help with audit. IAM can reduce headcount in your access services department. Companies bite off more than they can chew, ROI takes too long, so they give up.
But what does it all mean?
Are we really doomed to these behemoth infrastructures that sit largely un-used, while we pay off consulting and software bills that often run into the millions (if not tens of millions)?
No, we’re not.
IAM is not a lost cause. It can lead to lower costs, easier audit processes, and a demonstrated postive return on investment (ROI). But it takes time – and discipline. As with many aspects of security, identity management is not about technology – it’s about people and process. The technologies are out there, and getting ever-more mature. But, IAM is NOT a Mac or an iPhone – you don’t just turn it on and it magically works. There is a lot of configuration and even custom development that needs to be done after you install your product suite of choice. Even before that, there is a TON of data cleanup, data modeling, and process design that needs to take place, and that is at the heart of this series:
Identity Management in 13 Easy Steps
Of course, the series title is a bit tongue-in-cheek. There’s nothing particularly easy about identity management. Then again, it’s not rocket science, either. It just takes a little thought and a lot of tedious effort – and did I mention discipline? The focus of this series is all on process and data. In fact, product selection is saved until the very last article. That’s right – if you can keep your instant-gratification urges at bay, I recommend that you don’t even bother buying anything until you’re ready to use it. Why spend all that money on a fancy technology if it’s going to sit there, idle, while you beat your head against the wall trying to clean up the data and processes that it needs to function?
An identity management implementation will only be as good as the data and processes feeding it, and that’s the problem many companies face today – most organizations buy a product and figure out after the fact that they have a ton of work to do to make it function. As a result, there is such a lag between the time of purchase and the time of ROI, most management teams lose patience and halt the effort. If you pave the way to implementation by first cleaning house, when you implement the technology its benefit will be seen quickly, which will encourage management to keep it going and try more.
There’s another critical aspect to this approach: gaining the needed experience to properly document requirements. Identity management is extremely complex. No one can just walk in and “get it” in one sitting. Even if the high-level concepts seem obvious, you have to live with the dirty details for a while to really understand the needs of your particular situation. The better that understanding, the better the requirements. The better the requirements, the better the product selection. Choose the right product, and you avoid tossing millions out the window.
Are you ready for this journey? If so, let’s get started. Here is the series I have planned – one article per month. This may not seem like much, but unless your implementation will have a very small user base, it will take longer than a month to execute most of these steps anyway. Of course, the series may change along the way – I’m already concerned about the volume of information I’m trying to fit into some of the articles. I may find as we go that a few of these topics will require multi-part articles. We’ll deal with that when it arises.
For now, here’s the intended schedule:
December 2009: Identity Management 101 – an overview of the different components of an IAM suite, to make sure we’re all on the same page and speaking the same language.
January 2010: Identifying Systems Integrations – not all systems will integrate (directly or indirectly) with IAM. Determine which ones will feed the priority list for the data cleanups and process work.
February 2010: Data Cleanup Part 1 – before your identity management system can work, it needs to be populated with all userIDs, and those IDs have to be clean. The first cleanup is focused on the primary IDs such as AD/LDAP and other key systems.
March 2010: Data Cleanup Part 2 – a key benefit of identity management is the ability to link userIDs in multiple formats from a variety of systems to the user’s primary record. The second cleanup focuses on identifying which IDs belong to which users in preparation for proper linking.
April 2010: Preparing for Password Self-Service – password self-service is a key cost savings of IAM, but it’s harder than you might think. This article will help you prepare your policies and your users for the technology to come.
May 2010: HR as a Source of Record – the HR system is a primary source of record for employees. It can also be one of the primary sources of errors and limitations for identity management. This article will explain the issues that most companies experience when interfacing with HR technologies (and departments).
June 2010: Role- and Rule-Basing – in order for auto-provisioning and -deprovisioning to work, the roles and rules need to be defined. This article will teach you how to avoid turning this effort into a rat’s nest.
July 2010: Role Hierarchies – workflows cannot be enabled without proper approval processes. But approvers aren’t always line managers. This article describes the various role hierarchies that should be established, and the synergies that can be achieved between identity management and other sources of record (e.g., financial systems).
August 2010: Workflows – workflows are the key to automating many processes. This article discusses the considerations in setting up workflows to ensure that they function effectively.
September 2010: Termination and Transfer Gotchas – terminations and transfers are key control activities that are of great interest to auditors. Getting this right in identity management will save everyone a lot of work. Getting it wrong can be disastrous. Learn the pitfalls in this article.
October 2010: Password Self-Service – whereas the April article deals with the foundational aspects of password self-service, this article deals more with the implementation aspects: how to select challenge questions that make sense, exposing PSS outside of the corporate network, etc.
November 2010: Effective Business Cases – now that your house is in order and you have almost a year’s experience with your organization’s circumstances, it’s time to build a business case to buy a product. This article explores a number of value-added functions of identity management that will intrigue your management and encourage them to allocate budget.
December 2010: Requirements and Product Selection – you’ve cleaned your data, defined your processes, and secured a budget. It’s finally time to pick a product. This article will help you document and prioritize detailed requirements based on a year’s experience in the trenches, so that you can make the best product decision possible.
Firefox Patch Tuesday
by Carl Anctil
Background:
A few months ago, Microsoft released (and silently installed through Windows Update) a .NET Framework Assistant add-on for the Firefox web browser. Microsoft installed this add-on to Firefox without warning the user that the add-on would be installed as part of the .NET Framework 3.5 Service Pack 1. Security professionals, bloggers, users in general all over the Internet were in an uproar over Microsoft’s activities. Propel forward a few months, and Mozilla proactively disables two Microsoft-installed add-ons; one of them is the infamous .NET FA add-on. Following some discussions with Microsoft, Mozilla later selected to unblock the .NET FA, but continued to block the .NET Windows Presentation Foundation add-on.
Situation:
The browser is rapidly becoming the “new” OS, and add-ons are the “new” applications. This is the new computer model. The momentum is moving toward SaaS, IaaS, PaaS and other cloud computing acronyms. The impact this is having is such that our browsers are acting more and more like Operating Systems.
If we look back and remember how networking has evolved over the years, we will notice a pattern. Many years ago, networking emerged from thin clients, then it advanced to thick clients and now we are going back to thin clients. The browser is the new thin client. It’s essentially the new OS. It isn’t a coincidence that Google’s new OS is called Chrome OS. Or is it? Can anyone say: “Firefox patch Tuesday”? I think we may have witnessed the first Firefox patch push.
When Mozilla decided to proactively block two Microsoft add-ons, the result of this action was effectively the same as patching a vulnerability (automatic updates). The reason these two distinct actions are similar is because the results are the same; they both prevent, fix, or block a vulnerability from an exploit. The block imposed by Mozilla impacted every instance of Firefox automatically, without user interaction.
What’s even more disturbing with this model is its ability to completely bypass many perimeter defences. This cloaking behaviour is a huge blow for the security of our networks. It’s giving a transporter to our adversaries to infiltrate our networks. Once inside our browsers, this enemy fundamentally becomes a virtual insider on our networks. It turns our users into allies and uses tactics that are very effective and easy to deploy: Tricks like social engineering, spear phishing, SPAM and emails with various types of specially-crafted attachments, etc.
We must protect and educate our greatest asset, which is coincidentally also our weakest link: The user. Vulnerabilities such as XSS, XSF, drive-by downloads, etc. are almost always triggered by trusted, authenticated and authorized users on the network.
Conclusion:
I just touched on this subject, but I believe a general awareness strategy will have to play an important role in the future. The bad guys will keep winning as long as they are the only ones reaching out to our users. We must positively reach out to users or they will keep getting tricked into doing things against us (and themselves).
FTC Says Bloggers Must Disclose Freebies
by Aaron Titus
The FTC recently announced new guidelines requiring bloggers to disclose when they get freebies in exchange for reviews. Adopted by a vote of 4-0, this is the first update of the FTC’s Guides Concerning the Use of Endorsements and Testimonials in Advertising in 29 years. The rules go into effect on December 1, 2009.
Securing the Toughest Times
by Ron Woerner
Whether you call it lay-offs, downsizing, rightsizing, redundancies, a reduction in force, or whatever, a reduction in staff stinks. Downturns in the economy often translate to a reduced volume of business, resulting in a correlated reduction in staff. One of the hardest jobs in Security is ensuring that those who are asked to leave no longer have access to the organization’s resources. This is especially hard when you know those affected. However it’s critical that this tough job be done.
The last thing you want or need is for an ex-employee to perform a malicious act as part of their departure. The recent case with the Fannie Mae consultant is a great example of how a malcontent could potentially cause your organization grave damage. Luckily, the Fannie Mae sys admin found the malicious script.
You shouldn’t depend on luck to protect your organization’s critical infrastructure during lay-offs. This article contains concrete steps for you to consider before, during, and after the dreaded layoffs. [Note: the critical nature of these steps is, in actuality, job security for those who need to perform them. Maybe you can use them to justify your job and keep it off of the “chopping block.”]
Before the announcement
Just as in any project (and this is a project), planning and coordination are key. Those managing or initiating the lay-offs (e.g., Human Resources) must have Security on-board early in the process. Delays increase risk to the organization. While secrecy is necessary to protect the process, trusted relationships must be established between all involved, including HR, Security, Legal, and Management. Security needs to know who is affected in order to know what needs to be protected. Security can also help properly protect the “list” prior to the official announcement.
Security personnel (both physical and information) need to ensure the protection of personnel and assets during the lay-offs. On the physical side, you need to make sure that those announcing the lay-offs are protected should the employee(s) get upset or abusive. Security officers should be trained and ready to handle potential conflicts and workplace violence.
Information security personnel should identify single points of (security) failure and high risk areas. This includes administrators with expanded ability, authority or access. Security should also determine if there are any single points of failure in the operations that would be affected by the lay-offs. Management should address these critical points well before the announcement to prevent any unexpected denials of service.
Security personnel also need to develop processes to remove both physical and logical access as soon as the notification takes place. This cannot occur too soon before the associate is notified, or else it might alert the associate, resulting in unexpected consequences. (No one likes to find out that their position is eliminated by having their network or badge access disabled.) Also, this cannot occur too long afterward, for obvious security reasons. Ensuring the correct timing requires pre-planning.
As soon as the announcement is made that your organization is considering lay-offs, extend your monitoring efforts. This could be before the actual lay-offs. Rumors can spread, and associates might take these rumors as reason to start their preparation should their name be on “the list.” Your efforts should include Data Leakage Protection (DLP) to ensure associates aren’t shipping critical company information (e.g., customer lists, intellectual property, or company employee data) to themselves or others. This could occur on the network or off. It’s very easy for an associate to sneak a USB drive filled with an encyclopedia of company data out the door. You also need to be cognizant of physical theft.
During the announcement
With your planning complete, it is now time to enact and follow those processes. As soon as the associate is told that he or she is no longer employed by the organization, you need to disable the physical badge, logical network, and phone access. The accounts should not be deleted, only disabled in case you need them in the future (e.g., rehires). It’s important that all access is also disabled for networks or assets that are externally accessible (e.g., VPN). The time required for this activity will multiply if IT hasn’t kept complete documentation of each worker’s individual access rights, passwords, user names, and security cards.
Occasionally, the manager will request that the separated associate’s email, phone, or voicemail remain available. This is to maintain contact with clients or customers. Security needs to have an exception process in place to handle these requests while making sure the separated employee no longer has access. It needs to be reassigned to the responsible manager or his/her delegate. Allowing permanent access is not a good idea. There should be a set timeframe for this access to remain active before it is disabled.
Also, consider any shared accounts used by the separating employees. Do they know the UNIX root or Windows administrator password? Whether it’s that or any other password for a service account, make sure the password is changed ASAP.
Physical security personnel need to be watching and ready in case the affected people become upset. Normally, you don’t need a physical security presence to escort them. That can be accomplished by the manager and/or HR representative. However, Security should be ready in case things turn ugly. Additionally, they should be watching what property is leaving.
Part of your process should include the retrieval of any assets used by or assigned to the separating employee. This includes: Computers (laptops), USB drives, two-factor authentication tokens, cell phones / PDAs / pagers, and paper documents. When the employee is notified, the manager and HR representative should retrieve these items along with any other property of the organization. Of course, the employee should be allowed to pack up personal belongings, but corporate assets should remain.
Lastly, while the separations occur, continue to monitor online access and activities. You never know the mindset or attitude of those who depart. The potential for malicious acts is increased, especially against any resources that can be seen from the outside (external web sites). Your IDS/IPS should be watching those external network assets and you should be ready to take action.
After the separations
While the major threat may have passed when the laid-off employees have left, it is not completely gone. There are specific post-separation activities that need to occur to ensure risks stay low.
One of the most critical activities is the inspection of online and paper files left behind by the employee. Each manager is responsible for making sure this occurs, because he or she is in the best position to know what is and is not needed. This can be time consuming and tedious, but it can’t be ignored. The benefit is the freeing of storage space.
The manager or their delegate needs to inspect each piece to determine its disposition and whether or not it is still needed for the business. This person also needs to determine the retention period for any material that needs to be kept. This may require collaboration with the legal or compliance department as this material can be recalled for legal proceedings.
Another post-separation activity is inspecting online files for potentially malicious content. This is especially important for any systems administrators who were let go. There have been many stories of sysadmins leaving backdoors, Trojan horses, and time or logic bombs behind. Remaining sysadmins need to inspect any scripts created by the associates along with any scheduled jobs. Failure to take this step could be devastating for the firm.
Lastly, use this time to document what went right during the process and where you have room for improvement. Take time to learn from the experience and enhance the process.
Conclusion
Staff reductions are a part of corporate life. As painful as they are, they are often critical to keep the organization functioning at full capacity. Security needs to be an active participant in the lay-off process to ensure the risks are kept low. The removal of access is only one of the many areas requiring the attention of Security. They also need to be actively monitoring both the physical and on-line activities of the separating associates. This isn’t to be intrusive, but to ensure the continual protection of the organization.
Having a positive security model with validation and enforcement provides a deterrent to malicious behavior as well as the tools to quickly indentify and contain threats when needed. A positive security model includes: policies, procedures, detective and preventative technology, and proactive monitoring. The tips in this article will aid you in the development of your security model so you are ready when the time comes.
Checklist of Security Items to Consider with Lay-Offs
Before
Planning / Establish processes
Disabling access
Communications
Establish trusted contacts
HR
Legal
Security
Management
Identify single points of (security) failure
Employees who pose a danger (to themselves or others)
Administrators
Associates with access to sensitive or confidential data
Identify risks
Intellectual property
Confidential data
Property
During
Disable regular individual access
Logical
Physical
Phone
Email
Remove access to shared accounts
Administrator accounts
Service accounts
Other shared passwords
Asset retrieval
Computers (laptops)
USB drives
2 Factor authentication
Cell phones / PDAs / pagers
Paper documents
Enhance monitoring
IDS/IPS
Logs
Physical surveillance
After
Continued vigilance
Review of assets “left behind”
Online documents, files, and shared storage
eMail
Papers
Check for backdoors, Trojan horses, logic bombs
Unix
Windows
Databases
Network devices
Lesson’s learned
What went right?
What could be done better?
Process improvements
Have a workable plan, or else…
by Martin Fisher
As we continue to discuss the Basic Truths of Incident Response Leadership, we’ve briefly gone over the three Basic Truths as well as done a deeper analysis of “Succeeding By Planning to Fail”. This brings us to:
Basic Truth #2: Have A Workable Plan, or Else
As an Incident Response Leader, one of the most valuable parts of your role is to create, test, exercise, and (when called upon) execute Incident Response Plans (IRPs). IRPs run the gamut from a Post-It note on the wall listing contact phone numbers, to plans that take up several 3-ring binders on a shelf somewhere. Plans can be long or short, detailed or vague, paper or electronic, automated or manual…you get the picture. What makes a good plan different from a not-so-good plan can be summed up in a few ways.
First, can you execute the plan using only the resources that you legitimately would have access to during the incident? We’ve all seen plans that call for using network analyzers that aren’t accessible to the organization or that call for numbers of personnel that just don’t exist. You may have written plans that assume that the responding team has skills and experience that your current team just doesn’t have (I have). The key is to map out the current skills and capabilities of your team and employ them as best you can to meet the anticipated incident.
As you identify resources available to you, it pays to be creative. Can other teams identify folks who could temporarily be available during an incident (think of it as an in-house “volunteer fire department”)? Do you have relationships with designated outside incident response consultants? Do you have relationships with local, state, or federal law enforcement? In today’s business environment, Incident Response Leaders need to be creative in identifying resources that can assist during a response cycle.
Second, you have to test the plan. This sounds so intuitive, but many plans never get past the written-down stage before they are needed in an incident, because no leader stepped in to ensure that the plan would work as designed. One of the most effective testing plans for an IRP is also the least expensive – the simple “Talk Through”, where all of the designated players sit at a conference table (pizza is optional, but highly recommended) and talk through the plan, noting any foreseen problems or issues. The team needs to be encouraged to not only point out potential problems, but brainstorm solutions they can implement as-is since (as we talked about in Basic Truth #1) you can only plan on the resources you have, not the resources you want to have.
Plan testing needs to be redone each and every time the plan is modified, or at some regular interval (at least annually). Testing can be announced or (my personal favorite) unannounced. The time spent testing can help the Incident Response Leader assess not only the plan, but the team assigned to execute it. The feedback loop should encompass applications, hardware, processes and procedures, as well as people. Everything is fair game.
Lastly, you need to continually exercise your plan. This, while not as intuitive as testing, is something that many organizations fail to do, claiming “it’s too hard” or “it’s too disruptive” or “it’s already been tested, why should I do an exercise?” Having performed incident response on plans that have been exercised and plans that have not, I can tell you with complete assurance that plans that have been exercised are executed more smoothly, with fewer problems and a better resolution.
Exercises can range from a talk-through (similar to testing but without the constant feedback loop) to a full-on exercise using live equipment. Talk-through exercises can help in quickly familiarizing a team with a new (or newly updated) plan. Talk-through work will also quickly point out assumptions that, while seemingly accurate in testing, don’t fit the way the incident response team works. All other things being equal, I believe that talk-through exercises offer the highest return for time spent in any aspect of prepping for a incident.
Full-on exercises, as powerful and complete as they are, can be very hard to accomplish. Most organizations cannot fully replicate their production systems (even using virtual machines). These exercises, when they can be done at all, are usually done in development or test environments and generate most of their value by allowing teams to actually assess and interpret adversary actions and data. These exercises are an Incident Response Leader’s best chance to simulate the stress and activity of a real incident.
Taking all of this into account, it’s clear that the Incident Response Leader must be able to create, test, and exercise an IRP to be able to effectively respond during the inevitable incident. By creating plans designed around available resources, qualifying the plans with testing, and regularly exercising the plan, you can ensure that you and your organization will be ready when the inevitable incident occurs.
But it’s not over yet. Once you’ve gotten this far you still have one vital task to accomplish. We’ll cover that in the last article on the Basic Truths of Incident Response Leadership.
Getting rid of your best people
by James Costello
A friend of mine recently had a very Dilbertesque experience at work. The company my friend works for has been acquired twice in the last three years and all of the dust seemed to be settling. Sort of…
Locally there were four offices under the corporate umbrella, each a legacy of the acquisitions that had occurred over the last several years. The parent company decided to consolidate three of the offices and scale down the most remote office by moving some of the staff from that office to the new centralized office. This was reasonable, and most of the staff saw this as a good business move. Most of those who did not see it as a good move were from the remote office and would have to drive farther to get to work.
Planning for the move had gone on for a couple of months and was finalized about two weeks before the actual move date. The new seating chart was printed, offices were assigned, and additional requests were made. Here is where we take a turn for the weird:
Treating your people like they are worthless: Elimination of a position announced through the new seating chart.
One of my friend’s coworkers found out by looking at the seating chart that he was not going to have a job in two weeks. Rather than approach this individual before the release of the seating chart, the office manager chose to let things work themselves out a la “Office Space”. Fortunately, the Milton in this case chose not to resolve the issue with fire but by talking with HR, but this left a bad taste in a lot of people’s mouths.
Generate a menial or pointless task.
Actually, this one is a little worse than pointless, it is counterproductive. Time tracking is a part of a lot of people’s workdays. I did it every day when I worked as a consultant, so that we could bill customers for my activities. This is not a diatribe against time tracking; however, my friend was asked not just to start tracking time, but to go back to the beginning of the year and track all of the time since January 1. The company wanted real data for that entire time. Do you remember how you spent your day in fifteen minute increments 6 months ago? 6 weeks ago? 6 days ago? As a group, the team that was asked to do this questioned the logic behind generating data that would contain a lot of errors and inaccuracy that would then be the basis of the next three years of projections. They were told, effectively, not to worry about it and that the data analysis team would take care of it. To me, dear reader, that is like saying, “Create firewall logs for the last 9 months that we can then use as the basis for the upgrade of the existing firewall and Internet connection, even though you only put in the logging system this week.” Yes, you will have a smaller set of data to work off of but it will be more accurate, and your people will feel better about their work.
So what can you do to avoid putting yourself or your coworkers in such a situation – aside from not working where my friend works? Treat your coworkers with respect and dignity. If you know of something that is going to have a direct impact on their lives, they need to be made aware of the upcoming change in as timely a manner as possible. If you are implementing a new system that employees are going to be using, get their feedback and review what they have to say. Don’t make decisions in a vaccum. If it impacts people, get their input. Running a business depends on the people that work there; if they don’t feel valued, then the business won’t be valued.
Shooting ourselves in the foot: Can the bad economy keep us from buying more bullets?
by Ioana Justus
My career has now spanned almost 12 years, and it still amazes me how so many managers and executives consistently make bad decisions and then are surprised by the results. As the economy has gone bad, you’d think that people would be a little more judicious about how they spend the small budget they have remaining, but that’s turning out not to be the case. Surprisingly, I think the vehemence with which we’re shooting ourselves in the foot has increased as the budgets have shrunk. Now that the economy has bottomed out and is (supposedly) on the rebound, is there any chance of changing some of the behaviors before the upswing takes hold?
Let me ask you a different question: If you lived in Chicago and your house needed a new roof, would you just go out and buy the one recommended by your buddy out in San Francisco, because he’s thrilled with his new roof? Hopefully, the answer to this is no. You may take a look at it, but I’d hope that you would confirm that the structural integrity is insufficient for the added wind, cold, and snow weight that Chicago roofs experience. Once selected, would you allow the contractor to cut corners on your roof installation just to make a specific deadline? Is a permanently leaky roof worth a couple of weeks?
If you wouldn’t blindly purchase something for your own home based solely on the recommendation of a friend, why would you purchase a product for your company based on the recommendation from a vendor, a colleague in another industry, or a conversation on the golf course? How can you justify the potential risk? What happens to your reputation when the product in question doesn’t perform as expected? Where does the budget come from if you end up having to replace the entire thing?
When budgets are tight, there are better things to purchase with what little you have than bullets for your foot, and there are three very simple rules that can keep your munitions purchases at bay:
- Don’t ‘ decide’ on a due date, calculate it. Implementations take time and resources. As much as you might want something in production by the end of the quarter, it might not be possible to do in a reasonable way. Before committing to a date that’s just not feasible, spend a little time to determine the effort involved and lead-times for any purchases/installations that may need to be made, and to assess the availability of the resources required. Then calculate a plausible due date based on the reality of the work effort and be sure to document the consequences of cutting corners, should that still be desired. Sure, there will be instances when time is of the essence, but those are not as frequent as most people think. When you consider long-term support costs and the massive adjustments that are usually needed to make a quickly installed product work, the calculated ROI is rarely met, and the costs to reputation and morale are higher than many would like to admit.
- Don’t ‘make up’ budget numbers, calculate them. We all instinctively have assumptions about how much something should cost. Some of us are better than others at guesstimating accurately. Most of us underestimate – significantly! So before publishing a number that just doesn’t make sense, do the math. There’s truly nothing to be gained by setting the expectation that the desired work can be done for half the actual cost. If the true cost is prohibitive, then the negotiations need to start, and the consequences should be documented and accepted for each item cut. But if you’ve dug yourself a hole before the negotiations have even started, you’re in for a world of hurt.
- Don’t fit your problems to a pre-determined solution, pick a solution that fits your problem. No matter how nice the vendor is or how much you value your golf buddy’s opinion, the product they’re pushing may not be the right one for your company. The only way to know for sure is to gather requirements first, based on the actual needs, desires, and roadblocks currently being faced by your company. Then you can assess whether the desired product fits the bill. If it doesn’t, don’t buy it! If nothing fits the bill, pick the best option, or consider waiting for future developments. In any case, be sure to document the trade-offs, and get agreement that they’re acceptable.
Simple, right? 
But if we were all doing this, I wouldn’t be writing about it. The problem is that it has become acceptable to ignore the rules, and anyone who doesn’t follow suit is viewed negatively. The real challenge is for each of us to take the personal responsibility to follow the rules, regardless of our position in the company. Only then will we change the expectation and make it unacceptable to ignore the rules.
Embracing Manjoo’s Madness
by Dennis Kuntz
There was a little bit of a buzz recently regarding an article on Slate called, “Unchain the Office Computers! Why corporate IT should let us browse any way we want”. It’s basically a litany of complaints about how the IT department, “that class of interoffice Brahmans,” decides “ridiculously and capriciously, how people should work”. Very clearly it wasn’t going to win a bunch of fans from the Security Twits lurking around on Twitter’s infosec community.
The author’s rants run the gamut from legitimate beefs to notions that would make the most incompetent infosec employee cough up a hairball. He also seems to be completely unaware of the myriad legal, HR, and compliance bogeymen that serve as drivers of so many security policy restrictions. All of that coupled that with what seems to be a disrespect (or at the very least a disregard) for the skills, responsibilities, and intentions of your friendly IT worker would certainly make him a difficult customer.Who wants to deal with that?
A lot of the reactions to the author’s opinion were expected and understandable. If I recall correctly, “clueless” and “dangerous” were at least two of the words used to describe it. I don’t necessarily disagree with this either. The point of this post is more about what comes next: Do we, as those “interoffice Brahmans” simply thumb our noses at a very rash and simplistic view of the whys and hows of security-and-policy-minded restrictions, and tell the author to get the USB key that he found in the parking lot out of his PC and get back to work so that we can get back to saving the world from the l33t h4×0rs whilst doing the Dew? While not everyone would take that tack, let me suggest a different approach anyway.
The author, Farhad Manjoo, represents reality. He’s a real person who uses real technology in the real world. And he’s frustrated. He also represents a pretty wide view. In a Cisco-commissioned study on leakage prevention (get the papers here, and a decent summary here), it was discovered that:
“The majority of employees in eight of the 10 countries surveyed indicated that they believed their company’s security policy was unfair or impeded their ability to do their job. Employees with more access to collaborative Web 2.0 applications and social networking sites, video and mobile devices, expressed that they increasingly used these technologies in the workplace but were frustrated with rigid or outdated IT security policies that limited their use. “
With that, we need to accept that he and people like him are our customers. Rather than slough off Mr. Manjoo’s opinion as just being one of the uneducated masses, I contend that it’s our job to listen to his opinion and address it appropriately:
- If the reasons for a particular policy are draconian or reactionary, they should at least be reviewed, if not changed/updated or eliminated.
- If the reasons are justified (“justified” here does not mean “because we, the Brahmans, said so”; it means a very real, pragmatic justification for which there is not a reasonable alternative in order to protect the data/assets), then they need at the very least to be explained. Education and continued relationship- and awareness-building would be even better.
- If the policies really cause them to not be able to do their jobs (which does indeed happen), our job – and one of the aspects of it that makes what we do so cool, challenging, and fun – is to think creatively of how to allow them to do their jobs while keeping the data/assets safe.
I say let’s bump things up a notch: Make it a point to seek our your own personal Mr. Manjoos, embrace them, and convert them. Difficult customers, once converted, can become some of your greatest supporters. They might even spring for the Dew.
Use Your Words
by Jeff Kirsch
If you have been around small children for very long, you will probably hear parents utter the phrase, “Use your words.” This is usually in response to a child having a tantrum or resorting to yelling to get attention. Parents are reminding their children that the way to communicate is through using their words so others know what they want.
Brain “Cache”
My oldest son has enjoyed playing online games since he was about four years old. We have always tried to encourage him to play games that have educational value, but we also allow him to play games just for fun. One Saturday afternoon my son was playing a semi-educational game. At the end of the game a certificate would print out congratulating him on his success. Before starting the game he was asked to enter his name. He proceeded to play the game and got his certificate. Then he decided to play the game again; the program asked him for his name just like the first time. This is where I got involved. “Daddy,” he called out; I came in the room thinking he had closed the window he was in and needed me to get him back to his game. Turned out he had a different problem.
“Why doesn’t the game remember who I am?” he asked. After getting filled in on what happened, I offhandedly said, “must be poorly handled cookies”. Like any 5-year old, he asked what cookies where doing in the computer. “These aren’t cookies you eat,” I began, and then explained how websites use small files to keep information about you and your online usage, like your name. This took more than a few minutes to explain, but he finally understood the concept. His next question was, “Why didn’t the website people test this out?”
The most amazing thing about kids isn’t how much information they can take in without being filled up, but their ability to remember what they have learned. The following day my in-laws were over for dinner, and my son was playing some online games again. My father-in-law walked into the den and I overheard him talking to my son. When he returned to the kitchen he said, “The only types of cookies I know about are the kind you eat but, your oldest told me there are cookies in the computer.”
Whose Words?
We spend a lot of time learning our specialties, and as part of that comes a whole set of terms and acronyms. It becomes natural to talk in our own language, even when we deal with people not in our specialty. This is where problems begin, especially when we are called on to be part of a larger team that includes such people. A failure to find a common language can result in a project failing to meet deadlines, or worse. In the long run, you may find yourself being shut out of such cross-team projects, which are your best opportunity to show people you really have an expertise.
Language can become a barrier, even when it is not our intent. It can be frustrating to “outsiders” when we speak our own language; it can even sound like we are talking down to them, when that’s not our intent. Likewise, we may become frustrated when others try to speak our language and fail to understand the nuances of our terms. There are times when the best way to talk about what you know is in your own terminology. In fact, if we take the time to educate others on those terms, we can even expand our status as an expert. Likewise, if we take the time to learn the terminology of others we gain their respect and make it easier to communicate our ideas. In the end, that respect and communication are what lead us to provide the best results for our clients and organizations. We spend our childhood learning to use our words, then our adulthood learning other people’s words.
Coming Out of the “Cave”
by Trish Smith
As recently as five years ago, if you worked for the tech department of most organizations, your job responsibilities were pretty clear-cut. You were expected to fix the hardware when it broke, “fix” the software when someone crashed a program, and install updates and software as necessary. The skills required were cut-and-dry, and the surprises were pretty minimal. As far as information security was concerned, it was usually enough to simply hand down security measures and escape back to the sanctity of the IT “cave”.
We’ve come a long way, baby.
In the past few years, everything about the field has changed. Not only do job descriptions look drastically different, but the environment in which those jobs are taking place has changed. Budgets are smaller, the threats to organizations are greater, and the skills that are required have broadened. People in general are also more tech-savvy, which makes the job both more and less difficult. On one hand, IT is dealing less and less with people who are completely unfamiliar with computers and the internet; on the other, a little bit of knowledge can be a dangerous thing. People sometimes know just enough to create problems, and not enough to be able to fix them on their own.
In addition, we’ve come to the realization that it’s no longer enough to simply possess technical skills; IT workers now need to work with the rest of the organization to make security measures more successful. As I’ll discuss further below, success is much more likely when members of the organization are included in the process, rather than simply having security measures foisted upon them.
However, what this means for infosec employees is that they need a whole new set of skills, including the ability to communicate the value of what they do to fellow employees and to management. Job security is far from guaranteed for any member of the organization. Involving the rest of the organization in the development of security measures ensures buy-in from the organization for the measures and makes the success of these measures far more likely (and by extension, of the IT department as well).
How does involving those being affected by security measures in the process, make those measures more likely to meet with success? First, simply by going to the employees themselves to get information about they do their jobs, security measures become more specific to the people they’re actually supposed to help. A system that is designed around the people who are going to be using it is far more likely to be effective than one that isn’t.
Second, as people become more involved in the experience of creating these security processes, their fear of the measures that are introduced is diminished, making them more likely to comply and to be successful with such measures. They become partners in the security effort, and invested in its success.
True, change can be scary. But the opportunities inherent in such change make this an exciting time for the field. It’s not so bad out here after all.
Engage with Michael
-
Journey Into the Breach
