Here is a recent interview I did with IBM Security strategist Diana Kelley on Mobile Wallet security. Diana covers what security issues wallet developers need to be aware of and the risk profile for mobile apps
Any teacher knows that its way more valuable to catch someone doing something right and reinforce good behavior than to nag about mistakes. Why then does infosec take the latter path and often try to blindside developers, project teams and wave the list of vulnerabilities like a bloody shirt parading through the streets?
Kent Beck has a great quote - "I used to think of programs as things, now I think of them as shadows of the communities that build them." What does the shadow of your organization look like? Two silos miles apart occassionally exchanging cannon fire?
Wouldn't we be better off trying to catch developers doing the right thing? Wouldn't it be better to instill a safety first culture?
WSJ on UPS' safety culture:
Chadd Bunker says his friends and relatives tell him he drives like an old man. Roll through a stop sign? He would never do that. Exceed the speed limit? Not on your life. He makes three right turns to avoid a left. He can be annoying.
But Mr. Bunker, who is only 48 years old, is no ordinary driver. He recently became one of the proud, lucky few to reach the delivery driver equivalent of Eagle Scout—the United Parcel Service Inc. UPS's Circle of Honor.
The award goes to those who manage to drive their big brown trucks without having an "avoidable" accident, for years and years. That isn't easy since UPS considers nearly every kind of accident avoidable. A scratch on the truck while backing up, or a tree branch hitting the vehicle and breaking a mirror, they both count as accidents that might have been avoided.
Drivers who make it through 25 years are honored with a little ceremony, a patch on their sleeve documenting the number of accident-free years and the ultimate king-of-the-road status symbol: a bomber jacket.
UPS is driven by its safety culture. New drivers at the 107-year-old company are required to attend intensive, weeklong training courses, informally dubbed "Quaker boot camps" that emphasize ethics and safety.
It isn't the only company to toot its horn for safe drivers. PepsiCo Inc.'s Frito-Lay honors its million-mile safe drivers at an annual awards gala at its headquarters in Plano, Texas. The achievement typically takes 12 years. Con-way Inc., in Ann Arbor, Mich., bestows a class ring on its two-million-milers, who also get an embroidered jacket and business cards. Waste Pro USA Inc., in Longwood, Fla., awards its garbage truck drivers $10,000 for three years of spotless work. Spotless has three components: a positive attitude, good attendance and no accidents. UPS-rival FedEx Corp. gives awards too, recognizing employees after each year of safe driving.
For UPS drivers, the road to glory is very hard. UPS drivers must memorize the company's more than 600 mandatory "methods." These include checking the mirrors every five to eight seconds, leaving precisely one full car length in front when stopping and honking the horn just so: two short friendly taps, no blasting.
There are all sorts of potential hazards. In Ketchikan, Alaska, for instance, Tom Fowler, 53, dodges black bears and deer on a regular basis. In the snow and ice, he parks, then pulls a sled of packages a quarter mile up narrow roads on steep, slick hillsides to avoid the possibility of a vehicle accident. He became the first Alaskan driver to make the circle of honor in January.
"When you're out delivering, it's not unusual to see bears, black bears. People do hit 'em," Mr. Fowler said. It's "a big crash if you hit a bear."
About 1,500 were inducted into the circle in 2013, and a mere 7% of the 102,000 UPS drivers on the road are members.
Drivers agree the most impressive record belongs to Ronnie McKnight, who has driven safely for 46 years in New York City, dodging aggressive taxi drivers and parking precariously on a daily basis. Mr. McKnight, 71, learned to drive slowly on a tractor at age 11. Now, he says, his secret is "patience. Don't be in any rush to do anything."
There is a lot that infosec can do here. For a start, catch developers doing the right thing. That's 180 degrees different from how infosec teams traditionaly function. With the limited success of infosec, its time for a fresh approach. In our IEEE Security & Privacy Journal paper, 10 Quick, Dirty and Cheap Things You Can Do to Improve Enterprise Security", James McGovern and I called this- find diamonds in your back yard:
This might shock some battle-weary, jaded enterprise security people, but good things are probably happening right now in your organization with regard to security. Even amid the myriad challenges enterprises face in developing more secure software, some existing developer behavior will likely meet or exceed security requirements, whether it deals with input validation classes, instance level authorization, audit logging, or secure exception-handling classes. Your job is to find working examples that are proven in your enterprise and “bless them” as good examples of security standards, patterns, and practices.
With the only cost being your time, you can help get wider adoption of secure software that’s proven to work in your enterprise while building goodwill with developers by recognizing good work, not just finding faults. This approach has the convenient byproduct that for the existing good practices, you don’t spend your precious time and political capital lecturing birds on flying.
There's a lot more to say here, but I will close it with one thought: Instead of hording the security budget to spend on gee whiz foo fa ra products sold on the RSA trade show floor, buy pizza for the dev team with the best record each month. You'll fix more broken stuff and more importantly you'll begin to build a real safety culture.
Here is a keynote talk I gave at the Cloud Idenity Summit - I gave the talk awhile back but these topics keep coming up and thought it would be good to share.
A good operating principle for any new technology is "eat what you kill", its been said that when it came out Apple's iPhone did not destroy competitors, it paved over whole segments - portable music players, GPS, PDAs, digital cameras, and more were all thriving multi billion dollar industry segments in their own right until they got subsumed into the iPhone.
If we take the position that identity is the new corporate perimeter, then what is it replacing and how should we proceed?
The perimeter was the DMZ. Good stuff inside the perimeter on the server and outside? Well all bets are off. Unfortunately, over time the quality of protection of the DMZ degraded.
I'd like to begin not by burying the DMZ but to praise it, and ask, what did it, in fact, get right? There is a good list of things the DMZ did well that we can learn from as our security architecture evolves:
The DMZ was a defined zone where in Marcus Ranum's words the normal rules did not apply. In addition, its the one area in the software architecture where things were deliberately taken away rather than added, that's a win for security.
However, while the DMZ gave us a structural perimeter, the boundary that really matter is around data access. The data and users long since diverged from the DMZ structure. That means in turn that our perimeter goes from a structural perimeter to a more behavioral perimeter. The authentication, session management, data protection and other security services have to adhere more to the user, the transactions, and the data. /home is where the data is.
As applications move to mobile how do we process a security architecture that means we are now delivering code, not just data as in the web model? How to account for co-resident malicious applications and lack of control below the stack at the platform level? The DMZ was never designed for these scenarios. I suggest a better model for today's clients is to play by Moscow Rules.
"Normally, everything is split up and problems are solved separately. That makes individual problems easy to solve, but the connections between the problems become very complicated, and something simple ends up in a real mess. If you integrate it in the first place, that turns out to be the most simple solution. You have to think ahead and you must always expect the unexpected.”
- Jan Benthem, Schipol airport chief architect
Protocols should be designed and implemented looking at the whole access control chain and chain of responsibilities. Mobile apps, by themselves, cannot deliver a full solution, consequently the API and server side matters a lot. Applications may in fact be servers since Mobile middle tiers send push notifications, texts and other updates down to the "clients". In short we need to go back and fully refresh the playbook of security protocols not just extend and pretend mobile is just another client, a web browser with cooler hardware. Its a new way of interacting with users, servers and data, new protocols and initiations.
We cannot assume isolation, instead we need to plan for new types of interactions
At the same time, we have to make things simple for users and developers.
Our protocols live inside front end and back end containers. This means that integration is a first class citizen in security protocol design. We have both a First Mile Integration problem on the client side and a Last Mile Integration problem on the server side.
Many of the DMZ guidelines do still apply, attack surface should be reduced, simple, centralized policy enforcement points add value. Normal rules should not apply to perimeters.
Where the biggest distinction lies is the DMZ assumes a separation that no longer exists and that's where security integration patterns need to be worked and fielded to defend mobile apps, assuming not isolation and security but rather usage in actively hostile environments.
Wrote up my notes on John Gapper's excellent eBook "How to Be a Rogue Trader." The FT has a sad story of the aftermath for one. Jerome Kerviel is walking from Rome to Paris before his jail sentence starts.
It was after July 2007, when the financial crisis was starting to rout stock markets, that Kerviel’s initially modest gaming of the system started to get out of control. The economic situation was so bad, he thought, that the markets could only possibly go down from here, so why not bet big? He racked up a €28bn euro exposure in a few months, got the call right, and made the enormous sum of €1.4bn on his trading – although he declared only €55m as profit.
“At this point, no one was complaining,” he says. But hubris struck. At the start of 2008, he suddenly decided that the markets were set to rebound again, that the sell-off (which would last another year) was over. He built up a €50bn position, more than the value of the entire bank, this time betting stocks would rise. “I was confident, even though I was losing money, because I had always been right before,” he says.
In retrospect, he realises that at this point he had lost control. “It was just numbers on a screen. I was not even thinking in terms of money, just numbers of contracts . . . I had thousands, hundreds of thousands,
Giving that kind of leverage to a trader, to be able to build up positions bigger that the value of the bank, wow. Its not hard to see why leverage played a leading role in 2008 crisis.
One of the best books I have read in many years is Thinking, Fast and Slow. At the heart of the book is two systems - System One and System Two. They both play into decision making in different ways. For System One, think catching a ball, for System Two think - doing your taxes.
System 1: Fast, intuitive, frequent, emotional, subconscious
System 2: Slow, effortful, infrequent, logical, calculating, conscious
Both systems represent ways of thinking and they are both important, but besides the fact that they both reside inside the same bag of bones, they have little in common.
Naturally, reading Kahneman's work my thoughts turned to security architecture. Software is a System 1, Thinking Fast world, with Agile processes and its ilk, Software development is a 90% System 1 world at least
Conversely, the history of infosec is littered with (failed) System 2 ideas - data classfication, trustworthy computing, end to end security, and on and on. All these ideas have merit, occassionally they even work in some scenarios. What they do not have is - any sort of currency in a System 1 world. that more than anything is infosec' biggest issue, its not "the businesses" fault, its not developer's fault, its not that people do not care about security, its not that the tools suck. All these things play a role, but the biggest factor is that infosec makes 90% of its recommendations assuming a System 2 world while everyone else is busily living in a System 1 world.
It does not have to be this way, though, this is not to say that security has to be 90% System 1, but its critical that security teams know that any recommendations that they make are going to be given to people that operate in System 1 land. To get adoption on any security improvements, where you are relying on some other teams - your guidance absolutely has to match their system and dollars to donuts that system is going to be a System 1 system.
A good example of System 1 Security is SSO. It solves a very specific problem, mostly there is minimal integration, easy to understand, makes things simpler, doesn't block developers or the business, once installed it just works, project measured in weeks.
A good example of System 2 is Provisioning. Process oriented, data cleansing, data mapping, heavy integration, expensive, tradeoff analysis, continual tweaking, projects measured in quarters.
This isn't to say one is more vital than the other. SSO is more or less always going to generate more enthusiasm from developers and users, but that does not lessen the long term importance of provisioning. In fact, if you are going to have users doing SSO, then that increases the importance of a high quality provisioning system.
Infosec can and should tailor more guidance to System 1 inhabitants. Still its totally acceptable to continue to push for System 2 type capabilities, but, and this is the key - any System 1 guidance can and should be outsourced to other teams while any System 2 guidance must be owned by infosec throughout its lifecycle as there is no one else who is going to operate in that mode.
Another example, Role Based Access Control, like many things in infosec it has a foot in both Systems. The enforcement of RBAC is System 1 - access granted or access denied. Classic System 1, boom, go. But what users go in what roles? What level of granularity is right? Who engineers this? That is all System 2. The RBAC tool can get you to a System 1, but you have to get the System 2 stuff working and that is the hard part.
The issue I see is that when infosec teams say "I wish the devs did data classification or threat models or this or that", what they are really saying is- "I wish software was written with System 2."Whether it should be or shouldn't be is an irrelevant question, its not written in System 2, its written in System 1, and infosec has to cope. Your appsec plan has to factor this in.
Fixes must be addressed in a systematic manner too. You can't slam a playbook of System 2 ideas and processes and simply expect it all to "just work" in a big bang. Have to aim for a balance - find things that work in System 1 and be prepared to own anything yourself that is a System 2 assignment.
Most of the tool industry has figured this out, they are already in System 1 land - WAFs are a great example. What you have to watch for in tools, is that vendors create the illusion that you can have System 2 capabilities in the free and easy System 1 world, its not that simple. The System 2 stuff is very valuable, but there are no quick wins. Tools should be evaluated based on whether they are solving a System 1 or System 2 level problem and judged accordingly.
For System 1 solutions, you have to take a sober look not at what it could do in theory but what it can do in practice. Look at WAFs they can do a gajillion System 2 things, but realizing that value in practice means the long hard slog of data classification, URL inventory, and understanding yoru inputs and outputs at a granular level. So WAFs get bought because the demo shows that they can block SQL Injection, CSRF and a whole laundry list of attacks, then in reality when they get turned on they are used to terminate SSL and maybe catch a particularly poorly written XSS attack. By the way tools, including WAFs, are great, but enterprises have to be aware that tools cannot magically cross the chasm between System 1 and System 2.
There is no sin in solving System 1 problems in fact Infosec should get better at this. A scenario to avoid is paying a System 2 price for System 1 level capabilities. This happens way more often than people think. Another scenario to avoid is running many different System 2 projects. You have to know going in that these are marathons. If your company has never run a marathon do not sign them up to run three triathlons at the same time. Organizations get exhausted. For most companies a small number of System 2 projects at any given time makes more sense.
The good news is that there is no shortage of security problems. And we do have some solutions, what is important is to maximize the value of the solutions that we have, avoid System 1/System 2 mismatch, and chopping up the possible tools, people, and process solutions in System 1 and System 2, greatly aids the adoption of security improvements.
Beyond the accomplishments, how he was able to deliver them is a great story:
As NASA describes on its website, while under pressure during the U.S.-Soviet space race, Houbolt was the catalyst in securing U.S. commitment to the science and engineering theory that eventually carried the Apollo crew to the moon and back safely.
His efforts in the early 1960s are largely credited with convincing NASA to focus on the launch of a module carrying a crew from lunar orbit, rather than a rocket from Earth or a space craft while orbiting the planet.
Houbolt argued that a lunar orbit rendezvous, or lor, would not only be less mechanically and financially onerous than building a huge rocket to take man to the moon or launching a craft while orbiting the Earth, but lor was the only option to meet President John F. Kennedy's challenge before the end of the decade.
NASA describes "the bold step of skipping proper channels" that Houbolt took by pushing the issue in a private letter in 1961 to an incoming administrator.
"Do we want to go to the moon or not?" Houbolt asks. "... why is a much less grandiose scheme involving rendezvous ostracized or put on the defensive? I fully realize that contacting you in this manner is somewhat unorthodox, but the issues at stake are crucial enough to us all that an unusual course is warranted."
And now for something completely different. We have a special guest this time on Security > 140. Ok they are all special,but instead of talking about ABAC or Static Analysis or API economy or identity or software security or Netflix security or security writ large, instead of all that we are going to talk brands.
Bruce Tait is a Founding Partner at Tait Subler, a strategic consultancy specializing in the development of holistic, highly-differentiated brand strategies.
All of us in infosec have heard the term brand bandied about many times, on the receiving end of other's definitions of brand, the meaning can seem a bit, shall we say, fluid. I wanted to hear the straight dope from a leader in the field, and get some thoughts on how to assess and measure risk, and what to prepare for to defend the brand as an asset.
Gunnar Peterson: Information security has to deal with a lot of different kinds of risk, some are technical and some are business. One area that confounds a lot of tech folks is brand. We hear it all the time, but how much does it really matter? Coca Cola can sell sugar water for billions of dollars all over the world, so brand obviously can make a big difference, but all brands are not created equal, right? What qualitative factors should we look for to identify a brand at a company or if the company has one at all?
Bruce Tait: There are a lot of complicated definitions for “brand” and many marketers disagree on the meaning but the most straightforward and useful way to think about a brand is this: brand=reputation. Just as a person’s reputation is based on what they do, more than what they say about themselves, a company's or product’s reputation is based on how it acts and performs — in all ways. Brand is not just a marketing concept that is impacted by advertising or visual identity (logo, etc.). Everything an organization does impacts the brand.
The thing that makes some brands more valuable is that some organizations use the brand as the conceptual center of the their business plan. So the brand (reputation) the company wants becomes the key filter for all decision-making. For example, a shoe manufacturer might ask this question — “Will this manufacturing decision to have children in Bangladesh make our shoes be in keeping with our brand concept of ‘empowerment’?" If the answer is no, then another factory needs to be used that does fit with the brand strategy.
Communication (ads, PR, social media, etc.) can magnify the aspects of an organization’s actions they want people to notice the most and they can create a conceptual framework or expectation that adds value to the experience of a product or service, but they cannot cover up or change the totality of actions that create a brand (reputation).
GP: Are there ways to tell if a brand is getting stronger or weaker over time?
BT: Yes. Most sophisticated companies do brand tracking research that measures brand imagery attributes (both positive and negative) to determine whether their brand imagery is getting closer or further away from the brand image they want (their brand strategy). There are also measures like the Net Promoter Score that can be measured over time. This type of score determines the degree to which people would recommend the brand to friends, associates or family.
GP: What measurements can you use to quantify brand strength? I assume the public customer surveys are not worth much but what about profit margins? Customer retention?
BT: Brands are assets and can be valued like other assets (based on discounted cash flows) — Interbrand does a valuation of the top 100 brands in the world for Bloomberg every summer. We look at measures like this to see if we are increasing the brand’s equity or not with our work. For instance, after we worked with Gucci, they moved up 20 spots on the top 100 list, increasing the valuation of the brand by about $4 billion and making the brand more valuable than Starbucks and Lexus, combined.
But as above, understanding how a brand’s target group looks at the brand and what dimensions of brand imagery are improving or worsening is far more helpful diagnostically than looking at profit margins or customer retention. Profit margins can decrease because raw materials costs spiked — can’t blame that on the brand. Customer retention may be down because the company is trying to shed unprofitable customers or some other strategic and intentional reason. If you want to know about how well the brand is doing, look at the brand’s reputation in the minds of its targeted consumer.
It’s important to remind brand managers that brands live in the minds and hearts of their target group. That’s where you need to look to see how it’s faring.
GP: There have been so many data breaches over the last decade, but the pace and impact keeps going up. These days you cannot pick up the Wall St Journal without reading about "cybersecurity." Target is the most recent major example, what should companies do to protect their brands before and after a breach event?
BT: The best way to protect a brand from an unintended negative event is to create what we call a “values connection” with your customer. This builds the most powerful form of trust (identity-based trust) which is largely irrational. The other kind of trust is called calculus-based trust and it’s completely rational (See the study — Lewicki, Tomlinson. ‘Trust and Trust Building: Beyond Intractability, University of Colorado, 2003). If you do what you say you’ll do consistently, you can build calculus-based trust. But the first time you disappoint me that trust is shattered. It’s not resilient at all.
Now if you create a values connection by communicating to your customers what your values and beliefs are — what your purpose is as an organization (beyond making money) — consumers or customers who agree with your life view (your values) come to think you have their best interests in mind, especially if your actions prove that you mean what you say. This builds identity-based trust. Apple is the best example of this. Ask any Apple devotee about whether the brand lets them down and they will likely say it does all the time, in ways large and small. But they have that Apple logo on their car to tell the world that they are “Apple People.” Apple under Steve Jobs did a great job of explaining that it’s a company dedicated to making “tools for creative minds” (their intended reputation, or brand strategy). People who want to feel they have creative minds say, “I agree with Apple and I value creativity too.” In fact, the Apple logo comes to represent that values system and purpose more than it does computers. Apple has created incredibly powerful identity-based trust.
It will take a lot of egregious mistakes that are counter to their purported purpose to shake that trust. It’s a well-insulated brand for now.
Now Target is an interesting example. As the stories start to emerge that allege they didn’t act quickly when the alarms were sounded, it hurts the brand much more than the original incident. It suggests some kind of insensitivity to many people we’ve talked to and an indifference to the best interests of their customers that cuts right to the quick of any identity-based trust they have. It’s a dangerous time for that brand, especially if the reminders of this incident stay in public view for too long or continue to leak out a little at a time for a long time. In the best case, it will deplete the identity-based trust around the brand, which de-values the asset.
GP: In your view how much brand equity is at risk based on the dependencies on other companies? For example, Netflix runs its service on Amazon's cloud. If Amazon's cloud has a breach then Netflix's customers could be at risk. The consumer does not care about Netflix' internal issues they have a relationship with Netflix not Amazon, but the service provider execution could lead to an issue for Netflix. How should companies think about playing defense here?
BT: People may be angry at Netflix, but if Netflix used a known and respected supplier like Amazon, I think the crap runs downhill here and Amazon is hurt more than Netflix. In this case, the consumer could say, “that could have been me because I deal with Amazon too" (albeit in a different context and business). The key is how the consumer views the intentions of the company that has made the mistake. If they see the intentions as being good, then it can be viewed like a natural disaster and they may be off the hook.
In this case, hypothetical case, Neflix didn’t use some shaky foreign company to try to make a bit more money, they were simply burned by trusting Amazon… If the consumer believes Netflix still had my best interests at heart, he or she will forgive them much more quickly than if the problem was an act of arrogance or indifference on their part. We all hate to feel like “they really don’t care what happens to me.” Back to Target, they need to show that they really, genuinely do care because the latest news seems to indicate otherwise. They need to re-prove the things that made people love them in the first place and they need to take responsibility, plea mea culpa (diminish the perceived arrogance) and visibly fix the issue.
The classic case for addressing a problem like this is Tylenol’s product tampering situation. They did everything right and it’s a case taught in business schools today. You can bet a lot of people at Target have been reviewing it lately.
Want to know what its like to lose a few billion dollars? Why not study Nick Leeson, Jerome Kerviel, John Rusnak, and Kweku Adoboli? John Gapper's eBook "How to Be a Rogue Trader" gives you an inside look at what makes these people tick. For people whose job it is to defend these systems from malicious actors, there is a lot to learn.
I mentioned that in terms of building out a defensive plan, I prefer to start with assets. John Gapper's comments on why rogue trading, not exactly a new issue, continues to happen show why I prefer this approach over threats first:
“Rogue traders exploit the gullibility of their bosses by producing low-volatility returns, which is what every bank craves,” Gapper writes. “They do not appear to be reckless gamblers; they seem to have solved the conundrum of finance, that high rewards involve high risks. It is so enticing that no one realizes it is too good to be true.”
It’s so good, why not leave it alone until the losses mount into the billions and threaten the continued existence of the entire firm?
“The simplest thing you can do is follow the money,” Gapper said in a telephone interview. “It’s a weird thing that banks, after all these years, keep falling into this trap.”
“A lot of this stuff is extraordinarily simple. A lot of times, rogue traders are just putting on fake trades and canceling them. And they are taking advantage of these little gaps in the reconciliation system,” Gapper said.
That's the gap that gets missed in taking a software centric view of threat modeling. Of course, software matters, so do threats. But when its the model that is broken and/or being targeted, it cannot perceive the problem from within its own context. The asset view lets you step outside the system. The key isn't knowing how the system is supposed to work, as the software model tells you, but how the assets can be compromised. Rogue traders know how the system works, better than most of its developers. They are deliberately gaming the automation and clearing. And their techniques are deliberately targeting the system's blindspots. As Jeremy Epstein wrote in IEEE Security & Privacy - low tech attacks are easier.
There is also the banks' role here. How much room to roam are the traders given? Gapper asks in effect are the banks involved, rogue banks?
UBS's executives did not 'behave like gamblers at a casino, constantly taking greater risks as their profits and bonuses increased, until they finally lost everything' concluded Straumann. 'In fact, the contrary was the case. Top management was too complacent, wrongly believing that everything was under control, given that the risk reports, internal audit, and external reviews almost always ended in a positive conclusion.'
UBS was a rogue bank. It just fooled itself that it wasn't.
Known risky assets blow up, this should be "in the plan", but its way more hazardous when assets thought safe do. The illusion of safety causes the real trouble comes, as Mark Twain says - " is not what we don't know. It's what we know for sure that just ain't so."
Of particular interest is that to try and identify a rogue trader, Gapper shows that you do not look for wild spikes and losses, in fact you look for their absence. When a track record is a little too smooth is where someone may be covering their tracks. Think Bernie Madoff and his clockwork returns. Gapper summarizes -"the trader who is doing something wrong is the one who appears to be doing everything right."
Another flag is not taking vacation time, Kerviel was urged to take a holiday four times by the head of the trading desk. Its hard to head to the beach if you need to be on site entering fake trades.
Still detection can be elusive:
Helga Drummond, a professor of management at the University of Liverpool who examined the Barings collapse, says that its executives became blinded to what was going on under their noses. 'Humans tend to walk around with a frame of vision in their heads, their theories and expectations of the world, ' she says. 'They will discount evidence to the contrary unitl it is so obvious that it can't be ignored. The bubble can persist a long time.'
For the last couple of years, Ken van Wyk and I have been teaching a three day mobile appsec class on Android, iOS and Mobile Web services security. Using our keen marketing prowess we dubbed it the Mobile AppSec Triathlon. We've done a number of public classes and on site. We're putting together the calendar for 2014 trainings and we're expanding the training too. If you have ideas on cities for training or are interested in Mobile appsec for your company, drop us a line. You can follow the blog here.
People think management is about timing and tactics, but its really about values and focusing on what matters. We're lucky to have two good options for Dim Sum in the Cities. Both of them require getting there early. We arrrived at Mandarin Kitchen a half hour early this Sunday, and the parking lot was empty, first in line - win! Within 5 minutes there were 20 people. Then the manager drove by, parked in back, and we did not see her again for at least an hour.
By the time the doors opened, there were at least 80 people in line. We got seated and had a great meal.
The room was swirling chaos. Carts clunking and dumpling bowls clattering, people everywhere. Several dozens of more people waiting for table. The aisles jammed so full you had to stand on your tip toes to make it through the mass of humanity.
Then an elderly woman with a walker appeared at the front. The manager who we hadn't seen since before the place opened, appeared out of nowhere, and all of a sudden the chaos turned to order. The aisles that were previously filled about six people per square foot were cleared in an instant, wide enough to drive a Honda Civic through, and continued clearing the way like hacking through a dense, jungle forest all the away across the restaurant.
Its hard to describe how fast this happened. To give an example, our server was in the midst of serving dumplings with the bowl in her hand. She turned back to put down the bowl and in the blink of an eye the manager had whisked away the cart to clear the way.
The woman was seated, the gaps in the aisle filled in in an instant, and the mix of chaos, commerce and delicious meal continued.