Blog

Early hacker history is intrinsically tied to the telephone. Early hacker movies, too. Sneakers, WarGames. Hackers, Matrix, all have phones central to the plot. Yet before there was hacker history, there was phone history.  

The form factor of the telephone, at the dawn of the twentieth century, was the candlestick. That’s where the mouthpiece is on top of the stand, and the earphone is a cup you hold to your ear. This was the way a telephone looked for nearly forty years. The first phone to break free of this form? Came from the Bauhaus.

Richard Schadewell and Marcel Breuer designed the first cradle telephone in the late 1920s. Created for the Fuld Corporation and used in 1929 for the Frankfurt housing program, the phone is often called the Fuld or Frankfurt phone. Regardless of what you call it, Schadewell and Breuer’s design re-imaged the telephone. But it didn’t get much reach beyond Frankfurt.

Johan Christian Bjerknes and Jean Heiberg took the Fuld phone further with Ericsson’s Bakelite telephone. Ericsson began producing the phone in 1932, and it became popular across Europe. But the design did have problems. The handset was heavy, a problem when holding for an entire conversation. As time went on, repair and maintenance also became a growing concern.

Henry Dreyfuss began working the problem for Bell Telephone Laboratories. Dreyfuss studied the Ericsson and Bauhaus phones. He did field research with telephone repairmen. Dreyfuss studied how people used the phone, held the phone, moved with the phone. Dreyfuss then spent over two thousand hours prototyping, testing, and refining for usability and maintainability. The resulting telephone — Western Electric Model 302 — went into production in 1937. Dreyfuss designed the successor, Model 500, a decade later. The form factor of the 302 and 500 was the dominate phone design well into the 1990s.

Arguably, for fifty years after the 302, the only innovation on the American stock telephone was changing from rotary to push-button dialing with the Model 2500. Ask any hacker who was a kid in the 1970s or 1980s, and they’ll have a story about how they messed with the ubiquitous and cheap 2500 phone. Mine involves playing spy as a kid, “wiretapping” the phone. When Windows 95 and 98 arrived on the scene, the icon for telephony? The iconic Western Electric telephone.

Steve Jobs announced the first iPhone in 2007. He did so with an icon which traced back in time to the Bauhaus school. Our collective understanding of how a phone looks runs from Dreyfuss, to Bjerknes and Heiberg, back to Schadewell and Breuer.

The telephone offers many lessons. Adoption can make or break an innovation. Thinking about the end-user can lead to devices better tuned to their needs, even something as simple as the swoop of plastic that makes a handset comfortably rest on the shoulder. The customers are more than the end-users. Considering how the device will be serviced and maintained over its lifetime leads to sustainable designs. The backwards compatibility, too, provided by telephones is admirable. But when it comes to determining security controls, there’s a more powerful lesson.

The choices we make today will shape how the organization thinks for years to come. Ideas have staying power which outlives any given technology. Choose wisely.

This article is part of a series on designing cyber security capabilities. To see other articles in the series, including a full list of design principles, click here.

This article comes with a recommended soundtrack: the soothing sounds of the IBM PC. The article also comes with a suggested color: beige.

If you’re thinking of beige and playing the sounds of yester-year, you’re ready to come with me on a trip of nostalgia. It was the late 1990s and several years into my career. I had spent time wiring up IBM computers to Novell NetWare servers. I had run a systems integrator business, assembling computers for the local market. The turn of the century found me at a value-added reseller who specialized in mixed Microsoft and Apple environments, which was tricky back in the day.

That’s when beige turned to color. That’s when the world grew quiet.  

The Apple iMac had arrived.

The industrial design work was led by Jony Ive. Ive pushed the Most Advanced, Yet Acceptable (MAYA) principle to its limit. The original Macintosh was an all-in-one form-factor. The iMac was, too, but with a Googie spin. It felt like a Jetson’s computer. But Apple was clear it was an Apple. The 1984 Macintosh said “Hello.” The 1998 iMac? “Hello again.”

As pretty as it was, the iMac was no toy.  “The iMac isn’t about candy-coloured computers,” Jony Ive said. “The iMac is about making a computer that is really quiet, that doesn’t need a fan, that wakes up in fifteen seconds, that has the best sound system in a consumer computer, a superfine display. It’s about a complete computer that expresses it on the outside as well.”

The iMac featured:

• Sleek, curved, translucent in a time when all computers were square
• A departure from legacy tech; such as the floppy disk drive, serial port, and the SCSI port
• An embrace of emerging standards; USB, Ethernet, and WiFi
• An integral architecture; say when a CRT mount also reduces heat and increases beauty  

None of this is an easy leap to make in a design. We tend to benchmark and copy the success of others. For example, a wave of translucent colored plastics crashed over all product categories following the iMac’s success. Walk the vendor arena at the next major conference to see the same thing happen in cyber security. Another challenge is in letting go of the past. Dell still offered computers with floppy disk drives in 2006, nearly a decade after Apple moved on. Many security programs have a similarly hard time letting go of processes and technology, long past when they’ve stopped adding value. It’s hard.

When developing the technology architecture for a new security capability, channel Ives by asking the following questions.

• How can we challenge old assumptions about how things are done?
• What are we currently doing that we can simply stop doing?
• What technology do we have today that we can repurpose into something useful?
• How can we make our work attractive to end-users?

I never forgot the first time I saw the iMac, when I heard the iMac. Beautiful. Whisper quiet. The VAR I worked with at the time was an Apple partner. They also sent us a full set of promotional posters. One still hangs in my study today. Think Different. If only it was that simple.

“The thing is, it’s very easy to be different, but very difficult to be better.”
– Jony Ives

Afterward

Ken Segall is an ad man and the author of Insanely Simple: The Obsession that Drives Apple’s Success. Segall is also the man who put the i in iMac. Steve Jobs originally had a different opinion. “He wanted us to come up with a really good name, he called us in one day and said I have a name that I really like, we’re going to go with it, but if you guys can do better we need you to do better within the next two weeks. So his name was, yes it’s true, MacMan.”

Listen to him as Ken Segall tells the story on YouTube. It’s a reminder that, with computer products or security projects, the name tells a story.

This article is part of a series on designing cyber security capabilities. To see other articles in the series, including a full list of design principles, click here.

All maps are wrong. They simplify geography. They obscure detail. All maps are wrong. Some maps, however, are right in the moment.

Take cartograms. These are one of my favorite data visualizations. You’ve likely seen one during an election, abstracting states to show the population. Cartograms relish being wrong about geography. They toss land accuracy to the wind. Instead, they show one key datapoint. Clearly. Convincingly.    

The grandfather of the modern cartogram is Waldo R. Tobler.

Tobler pioneered computer-aided cartograms in the 1960s and provided researchers software into the Internet age. Frustrated with manually drawing maps, he tapped into the computing power of the University of Michigan. The results were the first algorithms for cartograms and one of the first computer movies: A Computer Movie Simulating Urban Growth in the Detroit Region. Take that, Pixar! Anyone who wrote to Tobler would get a reply with a floppy disk of code and research. As technology evolved, that little floppy would become a compact disc (CD), and finally posted online as free software (2003).

In a remembrance of Tobler, Benjamin Hennig wrote: “He made no distinction between the hierarchies in academia and gave young scholars the same respect and attention as senior academics, acting as a mentor and source of inspiration to many of them.”

Tobler was an open source map hacker.

Cyber security is in desperate need of data visualizations. We have numbers about port scans. We measure the easy things, from the number of emails received to the number of phishing emails reported. These roll up into bar charts, trend lines, and pew-pew maps. But do these visualizations actually communicate the data point we need to take action?

We need maps of what matters, not what’s happened. We need to see how data relates to fact.

“Everything is related to everything else, but near things are more related than distant things.” This is Tobler’s first law of geography. It’s applicable to security design. Consider the paths people take to complete work: number of steps, familiarity, and friction of each step. The more steps IT or cyber security places in the way, the longer the path, the greater the friction of distance.

We need visualizations that surface work arounds and work hacks. These security policy violations appear in result to friction. Identify these, and we’ll know where to adjust the design of controls.   

All metrics are wrong. They simplify and obscure. A well-designed metric, like a well-designed cartogram, can surface hidden truths about how people navigate the systems we build.

Identify friction with better data visualizations, then reduce the steps and improve the experience. That’s one way to increase compliance and adoption.

This article is part of a series on designing cyber security capabilities. To see other articles in the series, including a full list of design principles, click here.

Good design starts with listening to the user. This is the starting point for good security, too. But if we look at the LEGO playsets my kids grew up with, we can see how simply listening to users only gets us so far. In fact, given some of the outrage LEGO faced, it’s clear listening can even get us into trouble.

After nearly going bankrupt, LEGO turned to design thinking to reimagine its toy line. LEGO partnered with PARK to develop a design process. The process begins with exploring, begins with field research, beings with actually talking with the kids.

Imagine LEGO researchers sitting with ten-year old boys. Imagine it is around 2008 or 2010. Imagine the researchers showing the boys posters of minifigures. Minifig super-heroes fighting aliens. Minifig samurai. Minifig ninjas. Minifig action-heroes fighting mechwarriors. The question was, which stories were most exciting to the kids? What sparked play?

Ninjago was the result. A set of ninja minifigs which battle with skeletons on a spinning or flying disks. This would spawn over 250 playsets and a television series that ran for ten years, and is still being produced as of this writing. 

Fresh off the smash hit of Ninjago, flush with excitement of finding great ideas by actually talking with kids, LEGO replicated the design process with LEGO Friends. This time imagine LEGO researchers sitting with ten-year old girls. Same process. Different results. Girls expressed different play and different preferences. One insight I read, for example, was the minifigs needed fashionable shoes.

When LEGO Friends hit in 2012, it faced almost immediate public backlash. Many felt it reinforced stereotypes with pink bricks and scenes like shopping and childcare. Others felt it reinforced gender segregation, as the minifigs (redesigned for shoes) in the LEGO Friends set weren’t compatible with other minifigs and standard sets.

Seven-year old Charlotte Benjamin wrote a letter that captured the frustration. “Today I went to a store and saw LEGOS in two sections, the pink and the blue. All the girls did was sit at home, go to the beach and shop, and they had no jobs but the boys went on adventures, worked, saved people, and had jobs, even swam with sharks.”

LEGO had learned how to listen carefully to the kids. The problem was they hadn’t listened to the opinions of the parents, educators, and other stakeholders. Both young boys and young girls gave great feedback, feedback which resulted in great toys. Like Ninjago, LEGO Friends currently has over 250 sets, with television and other media. But the tight lens on the end user during exploration meant LEGO didn’t look beyond the playset. By not considering the wider context in which play happens, they fumbled the release.

This is an easy mistake for cyber security architects and designers to make.

We embrace the idea of empathy as the heartbeat of the design process. Flush with early successes, we listen closely and carefully to one segment of our workforce. Let’s suppose it is the finance team. Let’s further suppose we collaborate to reduce some security controls here, tighten others there, reducing friction for the team. Success! Except, six months later when the auditors come in, we realize our changes resulted in audit evidence no longer being collected, leading to a failed audit.

We addressed the needs of our target audience without considering the wider system in which they played. Hypothetically speaking, of course. Right. Back to LEGO.

“We listen very carefully to the opinions and input that people share,” LEGO wrote in the press release in response to the LEGO Friends uproar. “We will continue to do so as we develop the LEGO brand to deliver the best experiences with the strongest appeal, and we will review our communications to ensure that we represent LEGO play for all children.” With sets like the Research Institute (women chemist, paleontologist, astronomer) and with the LEGO movies, we can see LEGO’s design thinking process improves by widening the lens for field research.

Listening to users is the start, not the end.

When designing cyber security capabilities, listen carefully and consider all of the stakeholders. When our work helps people swim with sharks, we better remember the shark.

Afterwards

I learned of these stories from David Robertson. He wrote the book on LEGO’s recovery, Brick by Brick: How LEGO Rewrote the Rules of Innovation and Conquered the Global Toy Industry. Robertson also covered the LEGO story in a wider context in his recent book, The Power of Little Ideas: A Low-Risk, High-Reward Approach to Innovation.

This article is part of a series on designing cyber security capabilities. To see other articles in the series, including a full list of design principles, click here.

“The essence of strategy is choosing what not to do.” — Michael Porter

Enzo Mari often repeated “form is everything.” The Italian designer produced thousands of works, staying active until his death in 2020 from Covid-19. Mari’s work has a clarity and cohesiveness which cyber security often lacks.

“Enzo Mari is a total work of art,” said Hans Ulrich Obrist. “Everything went together with him.” Hans Ulrich Obrist, director of the Serpentine Gallery in London, was developing a retrospective on Enzo Mari before the pandemic hit. Mari was the master of individual form, and a master of collective form, unifying them a cohesive whole. One could spend a lifetime as CISO and still not build a security program as unified as Mari’s 16 animali puzzle.

“There is only one right form, not several,” Enzo Mari insisted. To get to the essence of the form, the designer must strip away everything. Everything. The designer must explicitly decide what the design is not, in order to make the design what it is. Take the Timor calendar. Compare it to your calendar. There’s no writing in the margins. There’s no tabs or colors, no holidays or birthdays, no reminders, and certainly no notifications. There is no excess. Timor is a calendar. Nothing else.

It is bold to say no. It takes courage to say what we will not do.

Suppose we are designing a software security program. For the purposes of this example, suppose we are lining it up to OWASP’s Software Assurance Maturity Model. SAMM has fifteen practices and forty-five objectives. Most security professionals would focus on getting a handful right. Most would speak loudly about what’s being done, and mumble about the objectives that are being ignored. Instead, we should channel Enzo Mari. Banging a fist on the table, we should declare which practices we will not do. By saying no, we create space and commitment. Only then can we build the committed practices, working towards something that fits like one of Mari’s puzzles.

Good security is clear about what it doesn’t do.

Obrist’s exhibition is currently on display at the Triennale Milano (Enzo Mari curated by Hans Ulrich Obrist with Francesca Giacomelli). It may be the last public showing. If Enzo Mari’s work can be defined by his declaration of what his work isn’t, then Mari’s last act is a defining one. Mari bequeathed his collection to the city under the condition that none of it be displayed for 40-years.

This article is part of a series on designing cyber security capabilities. To see other articles in the series, including a full list of design principles, click here.

The city is a book of poetry writ large across buildings. Santiago, Chile.

During the mid-1990s, Santiago went through building boom. The game was simple. A development investment project would be conceived and pitched. If the enough investors were interested, the project was funded, and the building was built. An apartment building here, an office building there. And key to the success of getting funding? The name.

Rodrigo Rojas, a poet and professor, played a key role in naming these buildings. “Rodrigo was a kind of interpreter of dreams — he tapped into the psyche of what the people of Santiago wanted to become, and tried to give that a name.”

Every project needs a name. Unfunded real estate projects and security projects, doubly so. Here are a few things I’ve learned from naming projects.

Be playful and fun. In my consulting days, to protect confidentiality, we wrote a name generator. We dedicated a portion of the project kick-off to laughing over possibilities. With names like Iron Taco and Gubbins Dance, you can’t go wrong. Security needs a spirit of play.

Share the vision. “One system, one team” was what I called my DevOps and IT modernization project. The clarity of the name simplified sharing the vision and making downstream decisions.

Address concerns. When I received feedback that my approach to managing several consulting practices was too complex, I came up with a three year roadmap in three words. Simplify, optimize, expand. One word per year. We executed on this from 2017-2019, with quarterly goals reinforcing the overall journey.

We need to find the spirit of a poet when naming security projects and initiatives. Tell a story with the name. Make it fun, while communicating the vision and addressing any concerns. We can use the name to drive action.

This article is part of a series on designing cyber security capabilities. To see other articles in the series, including a full list of design principles, click here.