1 Raindrop

Remember Your Helmet

"I have three mailboxes in my office : IN, OUT, and TOO HARD. I was joking with the MIT students that I should have a TOO HARD bin" - Warren Buffett

Even for a great investor like Warren Buffett, most investing ideas wind up in the TOO HARD bin. Investing is a great in that way, where you can pick and choose which problems to tackle. There is no penalty for sitting it out when things are too complicated.

Unfortunately, in security we do not have this luxury. Our dev teams need to ship. Preferably sooner rather than later. Oh, and attackers will be looking for holes from minute one.

Like Warren Buffett's mailboxes, virtually EVERYTHING that comes into an Information Security team's inbox is TOO HARD. But unlike investing, we cannot really sit it out and wait for all the planets to align, we have to act. 

There is a lot of evidence that information security is TOO HARD. Over the years, there have been plenty of examples of breaches where the victim companies did not do the basics - they did not have a firewall, they did not hash/salt passwords and so on. But nowawdays the victim companies are increasingly doing many things right and still getting hit. Its not a mystery, the design, deployment and operational challenges are hard. What to do?

This brings me to another of my favorite Buffett quotes- "The sign above the players' entrance to the field at Notre Dame reads 'Play Like a Champion Today.' I sometimes joke that the sign at Nebraska reads 'Remember Your Helmet.' Charlie and I are 'Remember Your Helmet' kind of guys. We like to keep it simple."

Security is too important to be left to development teams. But integrating security is too hard to be done by the security team alone. We talk constantly about threats and vulnerabilities and 0 day and SQL Injection, but our real problem is complexity management. There are ways to improve our security, but we have to choose wisely and make the things we choose simple enough to deploy. 

Keeping it simple starts with ensuring the system has the right structural security pieces in place. For many apps today like Mobile apps this means adding an API security layer. Before getting wound up about the latest and greatest threats, remember your helmet, ensure that your DMZ, Middleware and Data tiers have protection in place, not just at the network layer but at the Application and message data layer too. Its often the case that too much focus on latest and greatest security topics obscures more fundamental issues.

In the Security Gateway Buyer's Guide, I explored some of the important capabilities that security gateways offer. It's up to security architects to identify the right mix of security controls and then simplify the model to something that fits in the operational architecture.  Getting the right structural components in place is important because it sets you to deal with a wide range of challenges. 

We know security architecture is TOO HARD. We know that whatever we do today won't be good enough next year, threats are too adaptable and most sotware assets that we protect are not particularly resilient. We cannot predict what the next threats will be, we cannot predict what will be the right identity standard in 2016 (OAuth? SAML? Something some kid at Caltech is cooking up right now?).  But we can say with confidence, we'll need a place to patch and defend against threats. We'll need a place to deploy new identity protocols.

Engineering is about embracing constraints. For technical complexity and economic reasons, we simply cannot defend everywhere in the whole system. We have to choose where to locate our stronger defenses. 

Boundary crossings are crucial to security, you leave one trust zone and enter a new one. The API layer is a very important boundary, it's the logical place to drive security controls that can effectively handle application, identity and message data threats and countermeasures. When you are deploying Web, Cloud, and Mobile apps, remember this boundary. Remember your API Security.

Lessons Learned on the Mississippi Gulf Coast

Hancock Bank, a small local bank on Mississippi's Gulf coast, gives a master class in survivability. In the days after Katrina they gave out $50M in cash. They used folding table on the sidewalk for branches. The IOUs were handwritten notes on sticky notes. Its a great story - more here.

The story is a case study for how Howard Lipson describes survivability - "the ability of a system to fulfill its mission, in a timely manner, in the presence of attacks, failures, or accidents". 

Howard Lipson's fundamental goal of survivability:

The mission must survive

Not any individual component

Not even the system itself

What's interesting about this story is the ability provide essential services outside of the system itself. This isn't something that can be solved by adding to the existing system. Upgrading access control doesn't solve it, but rather carving out ways to deliver essential services.

Howard Lipsons defines the 3 R's of survivability - Resistance, Recognition and Recovery. Where Recovery is the "ability to restore essential services during attack, and recover full services after attack"; most people will focus on the second part - recovering full services. But what's important to focus on to even get to that point is the first part - "ability to restore essential services during attack."  eBay had a similar concept for scalability called "limp mode." This middle state is the essence of survivability to me whether its limp mode or handing out $50M in cash from folding tables. The job is to assume failure, in most cases assume centralized management structures are replaced with decentralized  and figure out a way to survive.

Security Implications from One Year of Mobile Only

Benjamin Robbins (@PaladorBenjamin) just completed 52 solid weeks working solely on mobile. Of course there were some issues, but he did it and the lessons learned are instructive.

A key takeaway:

From a practical perspective I’ve learned that there are certain needs of human ergonomics that you just can’t engineer your way around no matter how cool the technology. I can say with confidence that a monitor and keyboard are not going anywhere anytime soon.

This is a key insight for people in mobile security.  Its not Mobile only that we should be designing for. Its Mobile +. Mobile and something else, on top of that any number of hyrbid models like BYOD and COPE.

Your mobile device is an extension of other things, its not a full replacement. So as someone designing security and identity services for mobile, you have to be able to mesh that identity with the server, the other machines and the directory management systems.

It tempting to think of machines and mobile devices as islands that we need to protect (enterprise archipelago security architect?), but this is to miss the point. The mobile device needs data input from other places (likely by people using keyboards ;-P), need access to documents, and they need server side communications. Users also want something resembling a consistent set of access rights no matter what platform they are using - laptop, webapp, mobile, workstation or tablet. These are unsolved problems in the security and identity industry today.

Still Benjamin Robbins' piece is a great testament to, practical issues aside,  how far things have come in a short while for mobile. I continue to expect that we see more mobile apps not less and that the devices will snowball on top of the servers, browsers, services, and desktop/laptop machines you already have to cope with. Design your security services accordingly.

**
Three days of iOS and Android AppSec training with Gunnar Peterson and Ken van Wyk - Training dates NYC April 29-May 1

Your password is the crappiest identity your kid will ever see

My latest Dark reading column is up. 

 

Your Password Is The Crappiest Identity Your Kid Will Ever See

Ever watch an episode of 'Mad Men' and see everyone smoking? Some kid in 2045 will look at their parent and ask, did you really have to enter a password that many times?

 

read it here

**
Three days of iOS and Android AppSec training with Gunnar Peterson and Ken van Wyk - Training dates NYC April 29-May 1

Schneier Says User Awareness: Tired, Dev Training: Wired

Bruce Schneier tackles security training in Dark Reading. He basically says that training users in classic "security awareness" training is a waste of money. Certainly there is a lot of evidence to back up that claim, users routinely click on certificate warnings, for example.

What I found most interesting is what Bruce Schneier recommended to do instead of security awareness training for users:

we should be spending money on security training for developers. These are people who can be taught expertise in a fast-changing environment, and this is a situation where raising the average behavior increases the security of the overall system.

If we security engineers do our job right, users will get their awareness training informally and organically, from their colleagues and friends. People will learn the correct folk models of security, and be able to make decisions using them. Then maybe an organization can spend an hour a year reminding their employees what good security means at that organization, both on the computer and off. That makes a whole lot more sense.

Of course I wholeheartedly agree with this. Let's say doing a great job on security awareness training for users, best case, maybe takes the rate of users clicking through cert warnings from 90% to 80%.

On the other hand, developers, security people and architects are actually building and running the system. If they know how to avoid mistakes they are in a position to protect across all the app users from a broad range of threats.

This is the essence of what Ken and I focus on in Mobile App Sec Triathlon training. I wrote about it in Why We Train. We want to help developers, security people and architects recognize security problems in design, development and operations; and, crucially, have some concrete ideas on what they can do about them.

Companies are scrambling to get "something" up and running for Mobile, either enterprise side or customer/external facing or both. It really reminds me of the early days of the web. A lot of this is vert fragmented inside of companies. A lot is outsourced, too. Ken and I put a lot of thought into the three day class so that its focused on what companies want and need.

Choose Your Own Adventure
Day one is about  mobile threats that apply to all platforms, architecture, and design considerations. We look at threat modeling for Mobile. We drill down on the identity issues for mobile, server side and what makes a Mobile DMZ. The class is setup so that architects and dev managers may choose to just attend day one.

Days two and three are hands on iOS and Android. Depending on what your company is building and/or outsourcing. You come out of these days knowing how to avoid security pitfalls in coding for mobile. Whether you are doing the dev in house or working with a provider, developers and security people will have a deeper understanding of the core security design and development options for building more secure code.

We recently announced scholarship program for students and interns. Based on past trainings, this has proven to be a great way to get fresh perspective on mobile trends. Finally since many companies are launching new mobile projects, we often see whole teams that need to get up to speed on issues rather quickly (before deployment0, so to serve this need we offer a group discount, send three people and the fourth comes free.

Overall our approach is geared towards adapting to the things that are most useful to companies trying to build more secure mobile apps. Training developers on secure coding is not yet a sina qua non, but for those that invest in building up skills and expertise it pays dividends in protecting your users, data, and organization.

**
Three days of iOS and Android AppSec training with Gunnar Peterson and Ken van Wyk - Training dates NYC April 29-May 1

Battling Expertise with the Power of Ignorance

“We are all, in my view, condemned to float endlessly in a vast sea of unanswered questions and unknown reference points. A sea of ignorance if you will. The example that I like to use is a chessboard. How many moves ahead can you see on a chessboard? I can see about one move ahead in a chess game. If you can see three or four moves ahead in a chess game you can beat 99% of chess players. And if you can see seven or eight moves ahead you would be a world class chess champion.

 

Well suppose a chess board was not eight squares wide and eight squares long, but a hundred squares wide and a hundred squares long with a thousand moving pieces rather than thirty two. How far ahead could you see on the chessboard then?

 

The world is like a chessboard that is a million squares wide and a million squares long with hundreds of thousands of moving pieces and hundreds of thousands of different people moving them. In my view, anyone who imagines that he can anticipate what will happen next in any area of life is delusional, and people who think that “experts” should be able to do this are children and fools. If the world was 10 percent more complicated than the human mind, ... then the difference between an intelligent person’s ability to understand the word and a less intelligent person’s ability to understand the world would be very meaningful.

 

But since the world is billions and billions of times more complicated than the human mind, individual intelligence is almost entirely irrelevant to the understanding of the world.What is critical to understanding is humility and cooperation. What is critical to gaining more understanding of the world is to learn to accept and appreciate the vastness of our own ignorance; and to understand that one can only survive in a sea of ignorance by working with others to make our small lifeboat a little bit stronger. Only by embracing the fact of our limitless ignorance can one position oneself to increase the store of knowledge.”
-Bill James
Battling Expertise with the Power of Ignorance

Related idea: The I don't know school of security architecture

You Say: Cyber. I Say: Unsubscribe

Stop the presses! Sensitive IP has been stolen! Not only that, its some of the world's most advanced technology - robotic surgery! How will the Pentagon respond? Scrambling jets? Carriers on high alert?!?

Oh, one clarification, the headline Mako Sues over stolen trade secrets was not from CNN or NYT, it was from an almost as big a name media player -- the South Florida Business Journal. Not to be confused with the North Florida Business Journal one supposes.

Mako Surgical Corp. filed a lawsuit against rival Blue Belt Technologies and former sales manager Jeffrey Gellman over allegations that he violated his non-compete agreement and gave its competitor client data and trade secrets.

Gellman allegedly used his work email to send confidential information about Mako Surgical’s business to his personal email to help his new employer.

The Davie-based manufacturer of a hip and knee replacement surgical robot (NASDAQ: MAKO) has been under the gun to meet sales expectations, and had to revise its 2012 sales guidance lower last year. Mako Surgical projected sales would be flat or up slightly in 2013, but the emerging Blue Belt is trying to eat into its market share in this emerging field.

Why are we bombarded with IP copying stories as lead stories in all major media when the threat is otuside the US and told this is now our top priority when another story on the same issue (on very likely way more advanced technology) relegated to footnote in a comparatiely tiny media outlet?

Certainly just as much "cyber" was involved, after all the robotic surgery secrets were allegedly sent over email! Were told that "cyber" stealing of IP is the biggest threat of all, why is this Mako Surgical vs Blue Belt dispute of surgical robots not being handled by the White Hosue or at least the Secretary of Defense?

Well, you say, its because they are both in the same market. My answer to that is I can't hear you my ears are full of bullshit. Unfortunately the current international debate on "cyber" has precisely zero sense as to how markets operate. Ask your CEO where growth is coming from? Where are your products actually made? Mature developed nations or emerging Asia? Don't talk to me about "cyber" if you don't know how markets and supply chains work.

But hey maybe economics are not your thing, you serve the higher ideals of the American dream not the crass laws of supply demand. Well let's leave aside economics and do a historical tour of a wonderful country that built  itself from a frontier economy to a world leader through piracy, that country is America.

Its difficult to describe just how fundamental piracy was to building the US economy, the story is told very well in a must read book for any infosec pro - Smuggler Nation some examples:

• "Adam Smith was was such an admirer of smugglers - they were at the forefront of breaking down rigid trade barriers. He viewed a smuggler as 'a person who, though no doubt highly blamable for violating the laws of his country, is frequently incapable of violating those of natural justice, and would have been, in every respect, an excellent citizen, had not the laws of his country made that a crime which nature never meant to be so.'"  
• "a mere 384 hogsheads of molasses per year officially arrived in Boston in 1754-55, but 40,000 hogsheads per year were required to run the region's sixty-three distilleries...Colonial merchants predictably balked when Britain suddenly stopped turning a blind eye to such smuggling in the 1760s. In a revealing line, John Adams would later write, "I know not why we should blush to confess that molasses was an essential ingredient in American independence."
• "Edward Randolph, the appointed head of customs in New England, brought thirty-six seizures to trial -- and all but two were acquitted."
• "Smuggling was so institutionalized that merchants were able to buy insurance policies to cover them in the event of seizure"
• Newport, Rhode Island was the epicenter of the Rum trade in colonial America. Today we tend to associate Newport with yacht racing and gilded-age mansions, but the origins of this northern port's fortunes were less glamorous...By the mid-1760s, twenty-two of the thirty Rhode Islan distilleries were based in Newport. As one historian has remarked, "If merchants from all the American seaports evaded the navigation laws to some extent, those from Newport stood alone as the greatest offenders." No wonder then that the inhabitants of the town - and the rest of the colony for that matter - were denounced by British Admiral John Montagu as "a set of lawless piratical people...whose sole business is that of smuggling and defrauding the King of his duties."
• "The port of New York was even more active than Rhode Island in trading with the enemy. Far from being a business of the socially marginal, such commerce involved not only the city's merchant elite but also the political class - including the mayor and Supreme Court justices"
• Benjamin Franklin described the navy's new anti-smuggling job in especially harsh terms with a heavy dose of sarcasm: "Convert the brave, honest officers of your navy into pimping tide-waters and colony officers of the customs. Let those who in the time of war fought gallantly in defense of their countrymen, in peace be taught to prey upon it. Let them learn to be corrupted by great and real smugglers; but (to show their diligence) scour with armed boats every bay, harbor, river, creek, cove, or nook throughout your coloines; stop and detain every coatser, every wood-boat, every fisherman; tumble their cargoes and even their ballast inside out and upside down; and, if a penn'orth of [dressmakers'] pins is found untethered [on the cargo manifest], let the whole be seized and confiscated. Thus shall the trade of your colonsts suffer more from their friends in time of peace, than it did from their enemies in war... O, this will work admirably.
• "Boston merchants became increasinly outspoken in their defiance. John Hancock, one of Boston's wealthiest shippers, even publicly declared that he would not permit customs officers to inspect his vessels
• "Alexander Hamilton's Report on Manufactures, 1791:"'To procure all such machines as are known in any part of Europe can only require a proper provision and due pains. The knowledge of several of the most important of them here is already possessed. The preparation of them here is, in most cases, practicable on nearly equal terms' Notice that Hamilton was not urging development of indigenous inventions to compete with Europe but rather direct procurement of European technologies through 'proper provision and due pains' - meaning breaking the laws of other countries"
• "Only after it had become a mature industrial power did the country vigorously campaign for intellectual property protection - conveniently overlooking its own illicit path to industrialization"
• "Historians credit Slater as being "the father of the American industrial revolution." But the Boston businessman Francis Cabot Lowell is credited with truly transforming New England textile manufacturing into a mass-production and internationally competitive factory system. Doing so involved pulling off the most remarkable case of industrial espionage in American history. Lowell travelled to Britain in 1810 for an extended stay allegedly for health reasons. The wealthy Boston merchant was not considered a rival manufacturer and therefore not treated with suspicion in local business circles. Lowell toured the Glasgow factories in the spring of 1811. Soon after he visited other factories to obtain "all possible information" on cotton manufracturing "with a view to the introduction of the improved manufacture in the United States" as his business partner later recounted.
• [back in the US in 1813] "Lowell's was the first mill in the country to combine all aspects of the textile production process...The integrated cotton mill was a transformative development in the history of textile manufacturing

The echoes of history are so strong here you need a Richter scale to measure them. Its how emerging economies grow, and get up to scale.  What did England do or not do? What might have worked better? I do not have all the answers here but I can clearly see that amidst what passes for international dialog on "cyber" both economics and history are decidedly absent and yet they very likely contain the seeds of the most important lessons and guideposts for forward looking strategy.

What Comprises a Mobile DMZ?

The DMZ is a Web app security architecture workhorse. The DMZ operates under a different ruleset both in terms of what is allowed and in terms of the level scrutiny design, deployment and operations get. To the extent Web security works at all, its due in no small part to the isolation the DMZ provides.

The DMZ concept has lived on in the Web services world primarily through Web services gateways which limit Web Services attack surface, help developers navigate byzantine security protocols, and facilitates inbound and outbound app monitoring. 

Here we are in the first or second inning of Mobile apps, will the DMZ still play a role? I think the answer is a resounding yes. The DMZ will continue to serve an important role but the nature of the role and the capabilities will adapt for Mobile apps. I think the DMZ still plays a role and is supported by the Web Service Gateway, but in addition expect to see increased deployments of API Security & Management layers to handle some front facing tasks

 

Capability	What Stays the Same	What Adapts
Identity & Access Mgmt	Authenticaiton Authorization Audit	Support for OAuth, OpenID Connect Key mgmt (developer, user) Mobile Session management
Defensive  services	Limit Attack Surface Malicious content Monitoring access	Support client encryption Lost, Stolen Use case support
Enablement	Publish apps and content Centralized Policy enforcement	API Curation Facilitate new roles

For Mobile Secuirty architetcure I expect each layer in the DMZ to handle similar responsbilities as they have to this point but to take on additional responsibilties with a mobile flavor.

Identity is the new perimeter, and so Identity and Access Management is a core problem at the DMZ. There is a clear need to support different token types and different protocols for mobile apps. OAuth and OpenID Connect are two of the most important here, but importantly its not just session cookies, the type ot identity token and protocol will change and so will how they are used. The session length is longer and there are local client based access control decisions to be made. The Mobile DMZ must have a way to enforce security policy for apps and data over asynchronous protocols.

In addition the access control protocol is often not just a client --> server, the security architect must account for the app developer who gets access via an API. The Mobile DMZ must have a way to issue, validate and refresh developer keys. 

The Mobile DMZ serves an important function in providing defensive service, limiting what the app has access to and monitoring that access.Two additonal responsbilities include dealing with Lost/Stolen aka Remote Wipe. Many enterprises look to MDM here and that plays a role but does not help much on consumer facing applications. Client side data is often encrypted and here the Mobile DMZ is very likely involved to provision keys.

The DMZ is really about managing enterprise risk - publishing some data and functionality, while limiting the downside. This delicate balance is a result of the tension of push by development organzations and security's job to ensure prudent measures are taken to manage the risks. API Curation is an important step ring fencing the scope of the enterprise mobile interface.

To support these activities new organizational roles must be fostered including the Service Admin and API Developer role. The Service admin readies the backend enterprise services to be published. The API Developer builds content on top of them. In addition security architects and app developers must factor in how to collaborate with these folks to ensure a clear chain of responsibility - who does what. For example, the Service Admin can instrument policies for security, measurement and monitoring, but the API developer is responsible to develop the front end. Understanding what is published and how to safely use the services is key.

So I think the DMZ is here to stay, I expect the some changes, some structural, some subtle. The structural change is the decoupling of the front facing part of the DMZ to API Security and management systems with the back end enterprise gateway served up by Service Gateways. Its still early days in mobile in general and mobile secuirty in particular but I think this shift already under way.

Heartland 2012

Heartland reported its full 2012 results. They had the best year since the breach and the best year in the last ten years (length of history of data I have for them). They knocked the cover off the ball in every value metric - cash flow, margins, return on equity, and paid down debt.

This is the sixth in a series of posts tracking Heartland's post breach business performance. 

Just to review our valuation metrics, we are going to take Heartland to the value investor's Mayo Clinic and examine the following data:

• Operating Margins, Free Cash Fow: how much the company earned after taxes
• Balance Sheet: Current Ratio & Long term debt/equity
• Return on Equity: as a proxy for how well the company is run - are they good stewards of capital?

Before we dive into that though, let's take a look at top line

Revenue (figures in millions). 

	2007	2008	2009	2010	2011	2012
Revenue	1,314	1,545	1,652	1,864	1,997	2,013

Top ine revenue continued to grow each year.

Of course, businesses need profit, top line Revenue is of little importance if the profits don't flow. So let's look at this area and Operating Margins.

	2007	2008	2009	2010	2011	2012
Operating margins	4.5%	4.6	3.0	2.5	3.9	5.5

This is our first indicator of a robust return to health. Operating margins dipped in 2009-10, but they recovered to better than pre breach levels. 

If you were running a candy store Free Cash Flow is the metric you would use to show much money came into your cash register and how much was left.

In 2011, I wrote that HPY had negative $46M FCF - "This is one area where see the breach effect lingering into 2010, likely the result of paying the fines out of cash flow, and its one to watch to see if the recovery is complete." What we saw last year was that 2011 put it in the rearview mirror

	2007	2008	2009	2010	2011	2012
Free Cash Flow	38M	52	20	-46	71	137

For me this is the most significant indicator of recovery strength, the 2012 FCF held the gains in 2011 and more than doubles their bets pre Breach performance. Its a tailwind going into 2013.

The Current Ratio shows the liquidity in total current assets divided by the total current liabilities. The higher the number the better because this calculation divides Total Current Assets by Total Current Liabilities. As such its an important defensive calculation to check if the business is playing Balance Sheet games to achieve revenues. Revenue gains at the expense of balance sheet health is a poor tradeoff (looking at you Hewlett Packard).

	2007	2008	2009	2010	2011	2012
Current ratio	1.46	0.94	0.80	1.19	1.12	0.83

 

Long term Debt to equity ratio looks at the company's solvency, here is another area where we saw an effect from the breach. The Long term debt jumped from $8M in 2009 to $85M in 2010. The effect is moderating in 2011, where Heartland paid down $15M debt to $70M

	2007	2008	2009	2010	2011	2012
Debt/Equity ratio	-	0.09	0.06	0.48	0.32	0.24

From a balance sheet perspective the debt number peaked in 2010 but did not reach danger zone, and it has been steadily paid down. Overall, the performance in growing revenues and margins has been achieved without permanently impairing the balance sheet. 

Many investors consider Return on equity as the leading indicator of a well run business, it shows how well the company does at deploying capital.

	2007	2008	2009	2010	2011	2012
ROE	24%	24	-34	23	22	30

This metric shows a Return on Equity that beats pre Breach measurements. Note that 30% Return on Equity places Heartland in the company of elite companies like Coca Cola which had a 28% ROE in 2012. Companies that deliver ROE around 20% generally do quite well over the long haul. Given what we can assume that Heartland has worked to do to secure the systems post breach it also appears that improving security is not at odds with a successful business.

One final note, HPY's dividend yield is small at 0.84% but it has been growing from $0.04/share in 2010 to $0.24/share in 2012.

In sum, we can see with four full years of data since the breach was reported, there was a hole in the balance sheet courtesy of fines, but those are in the rear view mirror. The overall stock and business metrics show a robust business that recovered and improved upon its pre Breach economics.

What do the numbers say?

I had a number of questions going in to this analysis. Heartland is a good example because its one line of business (not a conglomerate like say Sony), its public so there is data, its in an indsutry where security matters, and customers can switch if they want. So in looking at the questions, what would the numbers tell us? Each of the numbers tells its own story

Did customers leave en masse? No

Customers did not leave en masse, they were at $1.5B revenue in 2008 and over $2B today

Was there a short term impact? Yes

-$42M cap spending in 2008. Negative ROE in 2009.

Was there a long term impact? No

Free cash flow at record levels $137M today versus best year pre breach year of $52M.

Did presumably increased security blow up their cost structure so their profit margins went down? No.

Operating margins are 5.5% which is also better than pre-Breach levels (best pre Breach year 4.6)

Is the quality of the business impaired? No

They can still grow quite profitably, the Return on Equity today is 30% better than any year since 05 (33%)

Did they take on excessive debt to cover fines, lost customers, etc? No

Long term debt did increase to $85M in 2010, but its been paid down to 50M

An important point is that going into the breach, Heartland was a successful company with a good balance sheet. If they were run poorly and highly levered then this may be a different story since there was a short term impact, but the numbers show they were able to weather the storm. 

The income statement, balance sheet and cash flows give clear answers to the questions I had going in. One question that I have after seeing how robust the recovery has turned out to be - is improved security a value add allowing Heartland to win business or retain customers? I do not expect to be able to answer that question but its interesting to ponder.

Disclosure: No position in HPY. I thought about buying some after the breach but thought the margins were too low (that was ~500% ago).

**
Three days of iOS and Android AppSec geekery with Gunnar Peterson and Ken van Wyk - Training dates for  NYC April 29-May 1

My favorite part of the Berkshire Hathaway Annual Letter

Well it was a quiet year in Omaha. The annual letter is out. Buffett called it a subpar year despite a $24B gain. The part I liked best was this part on the annual meeting:

"Finally – to spice things up – we would like to add to the panel a credentialed bear on Berkshire, preferably one who is short the stock. Not yet having a bear identified, we would like to hear from applicants. The only requirement is that you be an investment professional and negative on Berkshire. The three analysts will bring their own Berkshire-specific questions and alternate with the journalists and the audience in asking them."

So no one else takes random questions from all comers for 6 straight hours and sure as hell no one else invites bears and gives them a seat up front with a mic. Challenging your own ideas is something Darwin would approve of.

Not getting sucked into confirmation bias and overly enamored of your own ideas is critical to keep focus. Of course, we face this every day in security, having to act mainly as QA for often ignored non functional requirements that support (or inhibt) functional features. And its easy to see how rare the quality of raising the bar by testing your system and challenging your own preconceived ideas is.