Kerika is secure against the SSL 3.0 fallback vulnerability

October 15, 2014Kerika, TechnologySecurityArun Kumar

You may have heard of the “Poodle” vulnerability in SSL, which allows the plaintext of secure connections to be calculated by a network attacker.

This vulnerability was discovered recently by Google engineers; here’s how it works:

Secure Internet connections used to be implemented with SSL 3.0, which is actually a pretty old protocol now. (About 18 years old, in fact, which means it dates back to the Netscape era :-)

Over the years, SSL 3.0 was implemented by everyone who produced Web servers: e.g. Microsoft, Netscape, Apache, etc.

SSL 3.0 has since been supplanted with Transport Layer Security (TLS), which also comes in several flavors — TLS v1, v1.1 and v.1.2

And SSL was around for such a long time, everyone knew it worked. With TLS, however, bugs are sometimes found in different Web servers, depending upon who is producing (and maintaining) a particular brand of Web server.

In order to get around potential problems with the way a particular Web server had implemented TLS, browser clients (i.e. software that runs in a browser, like Kerika does) will also, very often, try to connect to the Web server using with SSL 3.0 as a fallback protocol.

Well, the good folks at Google found that SSL has a very fundamental vulnerability in it, that’s inherent in the protocol and cannot be patched: in an example attack called Padding Oracle On Downgraded Legacy Encryption (POODLE), an attacker can steal “secure” HTTP cookies or other bearer tokens such as HTTP Authorization header contents.

This problem is basically unfixable with SSL 3.0 because it uses RC4 ciphers for encryption, and RC4 is pretty darn old: it dates back to 1987!

(And, yet, according to Microsoft, even last year over 40% of Web connections were using RC4.)

The only way to secure against this vulnerability is to not allow SSL 3.0 as a fallback method for connecting to your Web server.

And that’s what Kerika does: we only support TLS connections.

Doing our bit to keep the Internet safe… :-)

Auto-Numbering: a new Kerika feature

October 10, 2014Agile & Scrum, TechnologyKanban, Scrum, UsabilityKerika

We have a new feature in Kerika: a simple way to add numbers to your cards, for both Task Boards and Scrum Boards.

Project Leaders (and, of course, the Account Owner) can access this feature by clicking on the Project Info button, which appears on the top-right area of a Kerika board:

Auto-Numbering can be turned ON or OFF at any time.

It is a simple feature, intended primarily to help manage large numbers of cards on a single board, e.g. a Help Desk team using Kerika as a ticket management system.

In ticket management or asset tracking scenarios, the titles of many cards may be similar, e.g. “User has trouble logging in”.

A more useful way of distinguishing between cards might be through the card’s numbers, e.g. “104 User has trouble logging in” and “242 User has trouble logging in.”

When Auto-Numbering is turned ON, Kerika will automatically insert a number as a prefix to new cards that are added to that board.

Numbers are sequential: for example, the first card would have “1” added as a prefix, the second card would have “2” added as a prefix, etc.

Auto-Numbering can be stopped at any time, and then new cards added to the board won’t have numbers added to the card titles.

Auto-Numbering can be resumed after a pause, the numbering will intelligently figure out how many cards are on the board by excluding the Backlog and the Trash, as well as looking at the last number used.

The numbers are simple text, added as a prefix: they can be edited by any Team Member, and even removed.

Making projects viewable by the public: a new Kerika feature

October 10, 2014Agile & Scrum, Kerika, TechnologyKanban, Our Users, Privacy, Scrum, Search, Whiteboard, WorkflowKerika

Most users work on private projects: i.e. projects that are accessible only to people added to the project team.

But some folks find it useful to have their projects viewable by everyone, typically because they are working on nonprofit causes, like WIKISPEED.

WIKISPEED publicizes its projects because it helps attract new volunteers to their cause, and this is actually a pretty smart way for nonprofits to showcase their work.

Kerika has always had an option for people to have all their projects made viewable by the public, but even nonprofits, for example, may have some Kerika boards that they don’t want to share with the rest of the world.

Well, with our newest release, it is possible for the Project Leader (or Account Owner) to make individual projects open to the public to view.

A project can be easily switched from Private to Public, and back again, using the Project Info button that’s available on the top-right of every Kerika board:

The privacy choices are as follows:

Only the project team can access: this is the default setting, and it means that unless people are added to the project team, they won’t be able to view it — or even find it using the Search function.

Anyone, anywhere can view: this means the project is “public” — it can be found through search, and anyone who knows the URL of the project can view it. (But, they still won’t be able to make changes.)

When a project is made Public, all the documents contained within it — on all the cards and canvases that make up that board — are also made viewable to the public.

This means, for example, that if your Kerika+Google Whiteboard or Task Board is made available to the public, all the documents in that board’s Google Docs folder are also made viewable by the public.

(And Google indexes all public Google Docs, the project could be found in more than one way, depending upon who is searching for it.)

One caveat: users of premium Google Apps, e.g. Google Apps for Business, cannot make their projects open to the public, because of limitations imposed by Google.

Switching a board between Kanban and Scrum: a new Kerika feature

October 10, 2014Agile & Scrum, Kanban & Lean, Technology, UsabilityKanban, Scrum, WorkflowArun Kumar

When we first started working on Kerika, it seemed to us that everyone who wanted to use an online project board fell into one of two camps that didn’t overlap:

Kanban users, who wanted a simple Task Board, perhaps with nothing more than To Do, Doing, and Done columns.

Scrum users, who wanted to share Backlogs across multiple Scrum Boards, with each Scrum Board representing a different Scrum iteration (i.e. “Sprint”).

Folks who wanted to work in Kanban-style – typically business users – seemed to have little use for Scrum, and people who wanted to work in Agile-style – typically IT folks – didn’t show much interest in Kanban.

So, we built Kerika with support for Task Boards, for Lean/Kanban users, and Scrum Boards, for Agile users.

What we are seeing more recently, however, is spectrum of usage patterns and styles within organizations:

A project that starts off as a Kanban Board might need to become a Scrum Board in the future: as the team works on the project, it may conclude that a series of Sprints/iterations is a better model than a continuous flow/Kanban model, and they may need to transform their Kanban Board to a series of Scrum Boards.

A team might start off working with Scrum Boards, thinking that Agile is the ideal model for their work, and then find that a Kanban model of continuous flow is better suited for their needs, in which case they may need to change from a Task Board to a Scrum Board.

A Scrum team may need to pull items from multiple Backlogs: there may be items from a Marketing Backlog and from a Product Development Backlog that need to get worked on in the same Sprint, so the team may need to switch from one Backlog to another.

This kind of flexibility wasn’t available in Kerika before — and is certainly not available in Trello, Asana, Basecamp or any other tools that compete with Kerika — and that’s exactly the problem that we have fixed with the new release!

Use the Project Info button, on the top-right of the Kerika menu bar, to switch a board from Kanban to Scrum, or vice versa:

If you check the “Use a shared Backlog” box, you can then select the Backlog you want to use for your board: if you had been working in a Kanban board, it automatically switches over to a Scrum Board.

At any time you can switch between any of the Backlogs that exist in the Account, that you have permission to access.

If you want to go back to working in Kanban-style, just uncheck the “Use a shared Backlog” box and the Backlog will disappear from view.

It’s now that simple to choose between Kanban and Scrum!

Lunch & Learn Agile, for State Government Employees

October 5, 2014Agile & Scrum, Kanban & Lean, Kerika, Team Collaboration, Technology, Týmová spolupráceGovernment, Kanban, Scrum, TeamsArun Kumar

Cayzen Technologies organized a Lunch & Learn Agile event at the Harbor House at Percival Landing in Olympia, Washington, featuring Arun Kumar, CEO of Kerika.

Arun’s topic was Implementing Lean across Distributed Teams, and we would like to specially thank Mayra Pena from Cayzen who organized the event:

The event was attended by folks from Washington State’s Employment Security Department and Department of Health, among others, and there was a lively discussion.

Here are the slides from that presentation:

If you would like to see the sample Kerika board that featured in the demo, go to https://kerika.com/m/H51M

Thanks for attending!

The Post-It Palace at Washington State’s Department of Licensing

October 3, 2014Agile & Scrum, Government, Kanban & Lean, Team Collaboration, Týmová spolupráceGovernment, Kanban, Our Users, Scrum, Usability, WorkflowKerika

Here are some folks who have really embraced sticky notes and Kanban…

(With Cullen Hower from cloudPWR)

Let’s see if we can’t improve on this :-)

Work-In-Progress Limits: a new Kerika feature!

September 29, 2014Agile & Scrum, Kanban & LeanKanban, Scrum, WorkflowArun Kumar

We are thrilled to announce a great new feature: Work-In-Progress (WIP) Limits for Kanban Boards and Scrum Boards.

WIP Limits are a very helpful tool when you are working in a true Kanban style: where work gets “pulled” as people become free, rather than work getting “pushed” onto people before the people ready.

To understand the difference between “push” vs. “pull”, think back to that famous episode of “I Love Lucy” where Lucy and Ethel take up jobs at a chocolate factory, and quickly find themselves unable to keep up with all the work that’s getting pushed onto them:

This is a perfect example of the perils of “push”: as the chocolate gets prepared upstream, the work becomes ready even though the people aren’t ready for the work.

If you push work on to people who aren’t ready to take it on, you will quickly have disastrous results. (It’s funny only when it’s on TV and it involves Lucy.)

At the very least, you will have an imperfect understanding of what each person is actually doing, if people upstream in the project’s workflow simply push work downstream as soon as the upstream folks are done with it.

A pull model is different: people “pull” work and assign it to themselves when they are ready.

Each person typically has a small number of items they are juggling at any time: it may be as few as two items, depending upon the complexity of the work, but it is rarely as few as just one item.

(You nearly always want to have one “background” task ready to be picked up whenever your “foreground” task gets blocked for any reason.)

When a person is able to take on a new task, she can “pull” a card from the column to the left of her on a Kerika board.

Here’s a simple example, reflecting the workflow for a software project:

This project includes people with different roles: designers, developers and QA, and each group has determined it’s own WIP limits, based upon the team’s capacity and velocity.

In this particular example, we can see that the Planning & Design and Deployment columns have currently exceeded their WIP limits (and, in the case of Deployment, by a large margin!)

When this happens, Kerika alerts you to the condition by showing the affected columns with red text in the column headers:

WIP Limits as “soft limits”: Kerika doesn’t stop you from exceeding a column’s WIP Limit, but it does provide a very clear, visible warning to everyone that a bottleneck is about to form.

When bottlenecks start to form, the Project Leader should intervene and help manage the upstream flow so that the WIP Limit can come back to its acceptable amount.

WIP Limits originated in Kanban, but Kerika lets you use them for Scrum Boards as well!

To use WIP Limits, click on the Project Info button that’s at the top-right of the Task Board or Scrum Board:

WIP Limits can be set only by the Project Leader (and, of course, the Account Owner).

WIP Limits can be set for every column on a board except for the Backlog, Done, and Trash.

WIP Limits can be turned ON or OFF at any time: turning WIP Limits OFF doesn’t cause the old values to be forgotten.

Pretty cool, huh?

Get More Done, With Kerika

Task Management for Remote and Distributed Teams