Midwest IT Survival

It seems the month of October is the month for giving users more online security options.  Similar to my previous post on Google enhancing authentication to Google Apps, now Facebook has made available more online security options to end users surrounding authentication.  Both Google and Facebook should be commended for investing in making their sites more secure.  Yet, each has addressed a different online authentication challenge.  Additionally, both have left it up to the end user to use or ignore their security enhancements.

In a blog post this month, Facebook has informed users there are now two new online security features they can use to manage the security surrounding their accounts.  Yet, dissimilar to what I captured on Google’s focus, Facebook is addressing two different security challenges:

• Ability to terminate previously logged in but not logged out sessions
• One time logon password for use on “untrusted” computers

Ability to terminate previously logged in but not logged out sessions

For end user convenience, Facebook allows users to stay logged in to Facebook even after closing a web browser and rebooting a PC.  Facebook uses basic web browser functionality to store a disk based “cookie” (named “isfbe” to be exact) to be retrieved the next time that browser accesses Facebook.  Upon return to Facebook, the disk based cookie is provided to Facebook and Facebook automatically logs in the user.  The convenience is great, but the problem it creates: what if you borrow a PC, logon to Facebook and then forget to logout when you are done?  The next user that borrows that same PC and accesses Facebook is automatically logged into Facebook as you.

To help with this security challenge, Facebook has provided additional screens to view your logon history or “Account History”  and next to each logon session that did not explicitly logout, provides an “end activity” link to terminate that open session:

Once a session has had its activity ended, the borrowed PC problem above is solved.  The next user who borrows the PC and accesses Facebook is not automatically logged in as you, but rather, is prompted to login.  Facebook, upon retrieving the “isfbe” cookie, now matches that cookie’s session with the user’s “Account Activity” before automatically logging the user in.  If a user indicated that session should be ended, Facebook ignores the “isfbe” indicated session and provides the browser with the login screen forcing the start of a new session.

Prior to this enhancement, remaining logged in on a borrowed PC could only be corrected by having physical access to the borrowed PC again to logout or wait weeks for Facebook to finally force that session to re-authenticate.  Both of these previous options are not particularly optimal.  This “remote logout” capability allows the user to address this problem remotely.

One time logon password for use on “untrusted” computers

Similar to Google’s addition of one-time passwords sent to account registered mobile phones (explained in more detail in my previous post), Facebook has added the ability to use a one-time temporary password sent to your mobile phone but with a twist.  This twist is to enable the user to request a one-time temporary password to be sent prior to logging on to a PC or device the user feels is “unsecure”.  Thus, instead of the more traditional use of multi-factor authentication:

1.      Website uses a previously stored browser disk based cookie to verify if the computer or device is “trusted” by the user

2.      If trusted, no additional authentication for that user

3.      If not trusted, in addition to the regular password, prompt for additional authentication in the form of a challenge/security question or via a one-time password (sent to mobile phone, email or provided by a token/key fob, etc.)

Facebook has enabled the user to request a one-time temporary password to use on a device they aren’t comfortable with security-wise or isn’t “trusted” before even starting the logon sequence.  The major differentiation is that last phrase “before even starting the logon sequence”.  By sending Facebook a SMS text message from the mobile phone the user has previously registered with their Facebook account, Facebook will return to that mobile phone a one-time temporary password valid for the next 20 minutes.

The user, once receiving the one-time temporary password, can proceed to login with that password.  If there happens to be a keylogger or some other form of user name and password harvesting malware installed on that PC, instead of giving away the user’s real Facebook credentials, the user is only giving away their one-time temporary credentials that are only valid for the next 20 minutes.  Even if someone is shoulder surfing (a person visually watching what a user types in order to observably record their credentials), the surfer is not getting any effectively useful information.

From a pure security perspective, the ability to use a one-time temporary password for logging on significantly reduces the threat vector of your fixed credentials being stolen.  The shoulder surfer, assuming the user surfed types their password and hits enter (rather than types it fully but waits to hit enter for some period of time), even a mentally recorded one-time temporary password is unable to be replayed because of the one-time use.  Any malware that harvests Facebook usernames and passwords is rendered ineffective, again, because of the one-time nature of the password.

Summary

Both of these new security features give the Facebook user more control over their credential use with Facebook.  Both require the user to be aware of the security functionality and when/how to use it.  And finally, both require the user to actually choose to use the enhanced security.  There is no forced security control aspect that protects the user auto-magically.  Again, the user has to be aware of how they are interacting with Facebook and choose to improve their security by engaging these new features per their usage patterns.  It is great to see Facebook providing these more sophisticated security options to users, but users must still be aware of how the features work, what threats they protect against and when to use them to protect themselves.

authentication, facebook, google, keylogger, malware, one-time password, security, shoulder surfing, trusted computer

How many times have you participated in this typical IT conversation?

Business: “How long is it going to take to enable that new FlimFlam engage-the-client-better module with those extra customizations we talked about?”

IT: “Last time we looked at that we said it would take a little over three months including changing the custom code in order to be able to use that new module.”

Business: “Well, we need it turned on by the end of next month when the marketing campaign starts.”

IT: “Um, err, change all the custom code, install the new module and enable it with those additional features in two not three months?”

Business: “Yes.”

The theme of this classic IT delivery challenge is the same:

In order to meet a communicated business need within a business defined time-frame, a perceived number of technical tasks need to be accomplished that don’t initially appear feasible in that given time-frame.

The initial reaction by most technically minded people is this is completely impossible.  And yes, Agile or other project delivery methodologies have built in capabilities to handle fixed dates and variable scopes.  But if you are faced with this common theme of questioning, I am going out on a limb and guessing you are not working in a truly Agile shop or else this question isn’t likely to be asked in this manner in the first place.

So, you rush out and grab your FlimFlam experts to communicate the need and the desired end date.  You tell them this is the most important thing to work on and then you go back to your desk to get ready for the next crisis of systems delivery.

Nope.

Consider taking the time to put together a work delivery estimate as your first priority.  Why do this seemingly futile exercise when the business has already stated what they need and when they need it by?

You need to have some estimate data in hand to have a conversation with the business on what is truly feasible within a pre-communicated time-frame.

This conversation serves a few purposes that are critical to you and your team’s ability to deliver a quality solution:

• Establishes what in-flight work will be put on hold/delayed until this higher priority request is completed.
• Durations of time on sub-tasks enable the business to prioritize what features they truly need versus those that are just “nice to have”.
• Establishes a baseline so when other high priority requests come in or new feature requests are added, you can dust off the previous estimate, revise with the new needs, and re-engage in the conversation.

I can’t count the number of times I have chatted with a business sponsor that swore up and down they just had to have every item in their request delivered by an irrational date.  Yet when presented with some work estimate that indicated everything wasn’t realistically possible within the time-frame [based on the cumulative hours/weeks associated with their request broken down into granular tasks], that same business sponsor started cutting “low priority” features left and right to meet their date.

Business: “You mean it is going to take a week just to get that data on the screen within the application?  We can just use that old report that shows the same data on paper.  Scratch that feature.”

Technical/Engineering Challenge

The typical technical/engineer mindset applied to the theme of delivering unfamiliar technology within an aggressive (arbitrary?) time frame is to think it impossible given the number of unknowns.  Get ready for panic and shortness of breath from your less seasoned technical staff.  Giving them coaching and a framework to break down the seemingly huge and complicated requests into a logical sequence of executable tasks is the other side of the estimation challenge.

To help enable the technical resources to break down “the work” into meaningful, estimate able and negotiable chunks, I’ve attached a simple work estimation spreadsheet:

Sample IT Work Estimation Template 10-05-10 [xls]

Sample IT Work Estimation Template 10-05-10 [xlsx]

Below is a brief explanation of how the template works:

There are three tabs:

1.      Template = where one fills in the data to create an IT work estimate.

2.      Calculations = where certain values are used in calculations on the Template sheet.  Changing numbers here causes the whole estimate to change.

3.      Assumptions = certain assumptions, copyright and reference back to this article for explaining how the template works.

Template

The top portion of the template (red arrow below) is designed to capture the basics about the estimate to tell it apart from other estimates: Name, project, dates, etc.  Think of all the fields that would help you and your organization know what you are estimating.

The main section of the template is where the work break down and granular task estimating occurs.  Gray fields throughout are auto-calculated but can be typed over if needed.  The first task heading “1. Architecture Tasks” shown below is a section to capture the non-negotiable tasks that need to be executed in order for any business functionality to be delivered.  This could be getting servers installed or setting up a new project in MS Visual Studio 2039 or creating a new code branch for the required new features which involves an act of Congress in your organization.

The “description” column is for the estimator to describe, in low tech language, what granular task is needed.  Since one may need to sit down and discuss this with a non-technical business person, some effort to use language that is more descriptive and less heads down techie would be beneficial.

The “Low” and “High” are for the estimator to enter the approximate minimum and maximum hours needed to complete the task.  The “Average” column in gray is calculated as simply the average to be used for the roll-up calculations at the end of the template.  If there are a number of unknowns or the tasks could be quick but depending on X, Y or Z, might run long, use a wide range for “low” and “high”.  This also presents the business conversational element of “Well, if this step goes well, it could be as short as 3 hours.  But, if turns out we do need to engage the storage team and get more storage allocated, then this could take as long as 20 hours.”  This is useful in setting the business’s expectations around variability in the estimate so they don’t get too fixed on a single, implicit number when things don’t follow the “happy path”.

The “Actual” column is useful for the engineer to record the actual time it took them to complete the tasks or the number of hours consumed up to the date the template is revised for some status reporting reason.  This also paves the way for estimators to get better at more evidence based estimating/scheduling.

The “Complete” column is for the task executor to record if they indeed completed the task or if it  still needs work to finish.  Entering a “Y” means the task is complete.  Blank or anything else means the task still needs work to complete.

The “Estimate Remaining” is gray and thus calculated as the remaining hours of the “Estimate Average” minus the “Actual” if the “Complete” column doesn’t have a “Y”.  If the “Actual” turned out to be more than the “Estimate Average” then the column is left blank.

The “Notes” column (not shown here) is for any task notes that help the estimator or anyone reading the estimate to know some additional details about task that is driving the estimated hours.

The next section called “2. Development of Functional Unit 1” represents a block of work that roles up to some business identifiable chunk of work.  Feel free to change the section name to reflect something all project stakeholders would understand.  These sections are designed to be the negotiable features that can serve as that business conversation to determine what are the exact features needed and the corresponding work durations.  Feel free to cut/paste as many new sections as is representative of the work break down requested.

In the above example from the template, Sample Task 2.1 represents a task that was estimated to be 7.5 hours but actually took 4.5 and is compete.

Sample Task 2.2 represents a task with 18.00 hours completed so far, thus calculated is the remaining 5 hours from the 23 hour estimate.

The “Sub Total” represents the min/max of the total work effort (142.25 and 181.25 in this example, which is a full ~40 hour delta) for an average of 161.75 hours of which 65 have been completed and 101 hours remain against the average.  Thus, the business expectations can be set relative to the ~40 hour swing to help the planning for best and worst case delivery.

Below the “Sub Total” section are tasks that are relative to the overall IT work:

In this section, any standard deliverables or work associated with the doing the actual development work can be captured.  In this example section, I added “unit testing” which I calculated as a percentage of the sub total hours of development work above.  The percentage is pulled from the “Calculations” tab.  In this case, I am calculating that unit testing takes 80% of the hours estimated towards development.  You can add/remove entries or adjust calculations on the “Calculations” tab to capture the hours needed to deliver a quality solution that so many developers forget to include in their hard core development work estimating.

The two documentation entries represent either a fixed amount of time, in this case 10 hours, or hours that are a percentage of the total development work, in this case, 20% of the total hours.  Feel free to add and subtract items that come up regularly to make the overall estimate more complete.  Need production turn over documentation?  Add an entry here.  Need some change control document to push a solution into the next environment?  Add an entry here.  Over time, this section will settle into capturing the work that is regularly needed in every project but is easy to forget to estimate for each time.

Lastly, the final section includes the total hours for all the work which is especially useful in answering that initial question: “How long is it going to take to enable that new FlimFlam engage-the-client-better module?”  One additional element that helps beyond the “how many hours” is the “Total Work Days” calculation which is based on a more realistic number of productive hours per day plus any reduction in time to cover other assignments that aren’t specific to project work such as researching a new technology or working on a special assignment of some kind.  The calculations are in the “Calculations” tab.  In this example, the productive work day is 6 hours (not 8 as some might consider) and 80% of those 6 hours should go to projects such as this one.  Hence the “Total Work Days” is greater than simply 348.50 divided by 40.  Again, feel free to adjust these calculations to aide in matching what your resources truly can dedicate to a particular project.  Want to show the “cost” of assigning two concurrent projects to a single resource?  Drop the hours to 3 and add another 20% to cover the cost of “context switching” and see how your estimates come to reflect reality a bit more as an example.

Additional Value

Once established as the “baseline” estimate, as new requests/changes come in, add them to the previous estimation sheet, change the date and quickly be able to predict when the overall solution will now be delivered.  Get ready for another “what is pushing out the date?” discussion armed with your estimating data.

Once established on multiple projects in the “portfolio”, now you can hold these up against competing resources to show “if project X goes first, when would I get project Y next?”  This is extremely handy if your resources effectively cost “zero dollars” in a non-charge back type corporate IT model.

Please give this template a try and let me know feedback on how effective it is with technical resources as well as a conversation tool with project sponsors.

For additional practical estimation articles, consider these I’ve written in the past:

• Is the Gantt Chart Useless in Agile Projects?
• More Pitfalls of Work Estimation
• The Art of IT Work Estimation

Also, for an excellent article on using a similar technique on prioritizing multiple projects, consider this great post by Peter Kretzman, “The Practical CIO: Difficulties in project prioritization & selection, part 2“.

For additional caution in getting too carried away with the accuracy of your estimate, consider Todd Williams’s article “Good Estimates Only Have a 50% Chance of Being Made”.

conversation, duration, estimation, project, project management, project sponsor, work