1 Raindrop

Find Improvements That Lie Clearly At Hand

There are not that many fields that have to deal in such abstract concepts as infosec. Software is abstract to begin with and layer human's difficulty with risk on top of that, information security has to climb two mountains. 

Believe it or not, Infosec people can learn some things from developers. For better and worse, Agile projects ship code. Developers have clearly embraced Thomas Carlyle: "Our main business is not to see what lies dimly at a distance, but to do what lies clearly at hand."

Security efforts often crash upon the rocky shore of the search for perfection, and cannot deploy until perfection is reached. For sure we have no shortage of security problems.

Here is where the current state of security can be used to our advantage as defenders. There is no perfect solution out there, in fact I will argue that even pursuing perfection is counterproductive, Butler Lampson talked about his review of field grade US Military security and how it is far worse than best commercial practice. The reason he concluded is that military security is determined by the NSA which is the crypto culture, its perfect or its broken. Perfect does not happen and so you just get broken. 

The pursuit of a grand security architecture to rule them all is a fool's errand, but so is doing nothing. And due to the current state of security, we are in a target rich environment. Use that to our advantage - there is a ton that we can do to improve, and its not all 7 figure projects.

A good challenge is to find as many quick, dirty and cheap ways to improve your security. You'll be surprised how many there are. People look at buying all singing, all dancing authentication solutions, but what happens after login? Have you looked at how authorization works post login? Privileged users are in the spotlight, but before leaping to an uber expensive "solution", what about monitoring access? These efforts tend to create a lot more organizational momentum, and has the knock on effect of getting the security team out of isolation and into working with other Dev and Ops teams. 

 

Limitations of Statistics on Measuring Risk

For any security project when we're trying to use risk to inform our software development, operational processes, the current state of available data is not particularly helpful. But even if it was better than it is currently (and we had statistics), its not likely to help much when it comes to risk. Good example from  Nassim Taleb in AntiFragile:

"A turkey is fed for a thousand days by a butcher; every day confirms to its staff of analysts that butchers love turkeys "with increased statistical confidence." The butcher will keep feeding the turkey until a few days before Thanksgiving. Then comes that day when it is really not a very good idea to be a turkey."

What we need is something predictive, but currently we cannot really accurately describe the past or present, so we're a ways away. What to do? One way to think about it from Howard Marks - we can't predict the future, but we can at least prepare for it.

Berkshire Hathaway Annual Meeting 2013 Notes

 

I attended the Berkshire Hathaway annual meeting along with Adrian Lane and 40,000 or so other shareholders. Adrian commented on something that is near and dear to my heart:

I am hooked, but not because I want investment ideas – instead I am fascinated by an incredibly simple investment philosophy, that involves an incredibly complex set of rational models, that forms the foundation of their decision process. Both men are contrarians – they choose to invest in a method that for decades people thought was a fluke. Berkshire has been called a 6-sigma outlier. They have been derided for not investing in tech companies during the tech boom – a profound critique when you consider Apple, Google, and Microsoft are some of the fastest-growing and 3 out of of 5 of the largest companies in the world. They have been mocked in the press as being “out of touch” when the market was going crazy during the whole mortgage/CDO fiasco. But they have stayed the course, despite fickle and fashionable trends, on their way to become the most successful investors in history. Berkshire is now one of the top 5 companies in the world, but ultimately their approach to decisions is what fascinates me.

That captures the essence of what I spoke about last year at the SIRA conference on how related the investing mindset and security mindsets are. People are wired to get excited and rush into things (whether its trying to guess the next Google or cram new features into an app), but a rational decision making process should consider the downside not just the upside. Buffett's teacher, Ben Graham pioneered the approach where you first look at the downside and then only consider the upside potential for those that pass the downside test. This is the exact opposite of how most people invest, or how most people build and deploy software for that matter. But the permutation matters, the discipline of analyzing the downside first leads to a more robust process. 

To me, the practice of information security can be improved by learning from the defensive, value-oriented approach to investing - investors should first make sure the Balance Sheet is safe and not over leveraged before looking at projected future earnings; security people should review the Threat Model before looking at the benefits of the new features the business wants to roll out.

As to the rest of the meeting, there sure is not much technology. Buffett and Munger are pretty technophobic, neither has a computer on their desk, neither runs a computer screen for stocks, Buffett does not even have a calculator on his desk, he does the math in his head.

There was a question on Twitter, and Munger replied that he is avoiding it like the plague, adding that when he observes his grandkids doing social media they are multi tasking and most jobs done as multi tasks are done poorly. There was a question on bitcoin, Buffett disclosed "Of our $49 billion, we haven't moved any of it to Bitcoin."

This year was the first year (and I assume first shareholder meeting ever) that had a bear who was short the stock asking questions. This was a great idea because it showed Buffett and Munger's willingness to challenge their own ideas rather than talk a PR game which is how most every annual meeting operates. Instead they invited a bear, gave him a seat on the panel and mic and let him poke holes in the company, live in front 40,000 people. 

Berkshire owns Business Wire which is a source for public companies making announcement, there was a question about the future of Business Wire with the SEC now allowing for disclosure via Twitter, Facebook et al, Buffett's response was "The key to disclosure is accuracy and simultaneity. If I'm buying Wells Fargo, for example, I do not want to have to keep hitting their web page and hoping I'm not ten seconds behind somebody else." Personally, I was kind of surprised the SEC acted so quickly in letting social media serve as a place to distribute official releases. It will interesting to see what if any impact this has on Business Wire's business.

Munger was asked to sum up Berkshire's competitive advantage in a way the questioner's 13 year old daughter could understand, he said "We've always tried to stay sane when other people like to go crazy. That's a competitive advantage."

There were some mentions of banking practices, Munger continues to be worried by the derivatives used at some financial institutions "The more bankers want to be more like investment bankers and less like bankers, the worse I like it."

Five years ago, Buffett bet a hedge fund called Protege Partners $1M that a plain vanilla S&P index fund would outperform a group of hedge funds. As of now, the S&P is +8.69% vs the group of hedge funds +0.13%. As Jack Bogle says - hedge fund provide excellent hedge against getting capital gains! You can track through longbets. The other lesson is the seductive details of a hedge fund's complex, proprietary models do not necessarily lead to better returns than anyone else can get through a boring index fund, though they certainly lead to higher fees!

On Sunday, we attended another highlight of the weekend - the Markel annual shareholder breakfast. They are a so-called baby Berkshire, a small insurance company that follows a similar approach: conservatively investing insurance float. Markel writes niche insurance policies. They eschew property, casualty and other areas where big name insurers play, Tom Gayner (Markel's CIO) describes their business this way: 

Cocktail party definition of Markel if someone asks about Markel, its an insurance company that they've never heard of. Well an easy way to think about that is if you have an insurance policy that you can get easily and quickly, well we wouldn't do that. We do the sorts of insurance where people go 'Oh no. We've got a problem or we've got a situation' This isn't to disparage the other insurance companies, we all have a role in life. What GEICO says yes to is not going to be the same thing that Markel says yes to. What Markel says yes to isn't going to be the same thing that GEICO says yes to. Its a different organization and orientation.

We do 100 different forms of insurance - everything from children's summer camps that are out in the middle of nowhere, that have teenagers supervising teenagers and no fire departments nearby, kids jumping on trampolines and being out in canoes, all the sorts of exposures that go with that

An ongoing challenge in these arenas is that unlike life insurance where the statistics are "disturbingly known", Markel has to piece together a hodge podge of sources to make decisions on how to write policies, and coming full circle on the theme of this post when Steve Markel was asked for an example of this challenge of managing risk absent optimal data, the example he gave was one of Markel's products - Cybersecurity and Data breach insurance.

Betwixt and Between - Service Gateway for Enterprise Mobile Applications

Over the next several posts, I will explore some of the core patterns for Service Gateways that provide access to Enterprise Mobile Applications that need to leverage enterprise apps and data. Before I go there - a word about risk. Mobile security is a hot topic. Is Android less secure than iOS? What about rooted devices? How should enterprise deal with BYOD? How do mobile dev teams write secure code for mobile platforms? And the list goes on and on, there are plenty of important questions to ask. 

Amidst all these gnarly big and small questions on technical security for enterprise mobile applications. its vital to remain focused on risk. And where is the risk for enterprise mobile applications? On the apps, identity, and data housed on the numerous mobile devices? Sure. There's risk on individual mobile apps and devices, but the lion's share of data, functionality and identity is on the server side, and that's where the lion's share of the risk is too.

Boundary crossings are a key focus area for security architects. The Enterprise Service Gateway defines the boundary between "external" systems and "internal" systems (note - I am not sold that this is a valid distinction in many instances but its commonly used and holds up for the purposes of this pattern). The transition between external and internal confronts the security architect with a number of design choices. We can divide the message exchanges into two sets

1. Mobile device -> Gateway: asynchronous Web service calls via REST

2. Service Gateway -> Enterprise backend app servers: synchronous and asynchronous calls via REST, JMS, SOAP, and more

The inbound calls to the Service Gateway usually follow a simple message exchange pattern (albeit its asynchronous which is something new to many enterprises but we'll save that for another day), whereas the Gateway -> Enterprise message exchange patterns can run the gamut. In effect, the external services simplify the experience for the user and the internal services- well they just go where the data is.

The implications here shed light on the core utility of the gateway. The gateway is the location to implement three sets of security policies. 

1. External security policy: for the Mobile device -> Service Gateway message exchanges

2. Internal security policy: for the Service Gateway -> Enterprise backend message exchanges

3. External <-> Internal mapper security policy: to facilitate the right security and identity services for each boundary transition 

Security is about reducing vulnerabilities (access control services) and coping with threats (hardening, defensive services).  Service Gateways play a key role in each.

In the case of access control and identity services, the identity protocols and tokens that are used by the mobile device are usually validated and terminated at the gateway. The gateway then maps the relevant user identity, such as username and attributes, and instantiates a second protocol to communicate with the enterprise backend.

In the case of defensive services, enterprise applications are not hardened for external access, after all that's why there is a DMZ. Inbound calls, messages, and data must be inspected for malicious code targeting the enterprise.  In effect the Service Gateway is what enables the internal services to be consumed externally.

To make sure mobile security is effective, from a big picture, strategic perspective its important to keep in mind the vital role of the gateway in managing risk on both the mobile device and the enterprise backend. To execute tactically its important to divide the Gateway's role in to how it works for each separate policy zone, and how it maps between the zones.  So many projects, start out assuming that mobile is just another front end to hook up to existing middle tiers - it isn't. To get an idea on some key differences, I highly recommend this Mobile Middleware White Paper as a solid read for more on the subject.  In the next post we'll look at some policy options for each zone.

 

Physics Envy Redux

Richard Bejtlich's blog on Risk Assessment, Physics Envy and False Precision points out a number of important issues. Overweighting what be counted and underweighting what can't be counted is an easy trap to fall into. The seduction is amplified by the beauty of mathematics, the quest for certainty in an uncertain world. Unfortunately this leads to a number of problems brought on by overconfidence (because hey you counted and you're using math). As Dean WIlliams said: "Confidence in a forecast rises with the amount of information that goes into it. But the accuracy of the forecast stays the same."

Ths applies well beyond simply security and risk assessment, people are generally very uncomfortable with uncertainty and tend to obsess on it. The real value often lies with being comfortable with some level of uncertainty and set about dealing with the residual risk

E.O. WIlson:

Fortunately, exceptional mathematical fluency is required in only a few disciplines, such as particle physics, astrophysics and information theory. Far more important throughout the rest of science is the ability to form concepts, during which the researcher conjures images and processes by intuition.

...Over the years, I have co-written many papers with mathematicians and statisticians, so I can offer the following principle with confidence. Call it Wilson's Principle No. 1: It is far easier for scientists to acquire needed collaboration from mathematicians and statisticians than it is for mathematicians and statisticians to find scientists able to make use of their equations.

This imbalance is especially the case in biology, where factors in a real-life phenomenon are often misunderstood or never noticed in the first place. The annals of theoretical biology are clogged with mathematical models that either can be safely ignored or, when tested, fail. Possibly no more than 10% have any lasting value. Only those linked solidly to knowledge of real living systems have much chance of being used.

Lots of people flock to elegant mathematical models because they are sexy, meanwhile eschewing harder work that's required to fully explore the space, such as a Domain Specific Language for Security. In fact, for the most part the power of mathematics and statisics does not come from the models themselves it comes from its own ignorance or a humble objectivity. Measurement is vital and will remain so, but its useless without context. We have too much focus on the former and not enough on the latter.

People obsess on data breaches, but these need to be seen in a context. A credit card breach has little in common with an IP breach. Yet many models measure them the same way. Measurement sans context can easily lead people in the wrong direciton, by making them think incorrectly they know more about how to protect and what their biggest threats are. Lack of context is a common theme in many breach reports. Moreover, breach reports almost always lack the crucial element - some sliver of sunlight on the "what do I do" question. Don't get me wrong, I am glad people publish this data, but its early days, we are floating in a sea of ignorance, and we need more tools from more disciplines. As much as math and physics are fetishized, I would be that concepts from engineering (margin of safety) and biology (domains, lifecycle) will prove very useful to solving security problems.

Complexity Management with Tokenization

Tokenization is a major trend in application and data security and Gateways are an ideal location to deploy tokenization services. Tokenization replaces sensitive data with benign data. The classic example here is PCI DSS, and the business value of tokenization is summed up here:

Now I am no graphic designer, but let me take advantage of the Chinese saying that 1,001 words is worth more than a picture. As much as I like the graphic above it does not tell the whole story. The 2/3 of the graphic starting from the left is "PCI Scope", the 1/3 on the right is outside PCI scope. In my experience the value of tokenization and gateways is that its more like 10-20% of the system is isolated down to in scope for PCI and the remaining 80-90% is "out of PCI scope" - *this* is the value of tokenization - it abstracts away a ton of complexity. As we discussed in the last post, complexity is the main enemy for security people. Tokenization services are a good way to not eliminate but massively reduce the sprawl of sensitive data and in doing so reduces the burden of complexity across the system because the rest of the system isn't dragged into scope. 

The reality is that most of the system does not need to access sensitive data such as payment information, it only needs to be able to reference authorization codes and the like. There are so many ways to mess up code that simply removing the sensitive data in as many places as possible is frequently the single most effective security mechanism. To quote Ken Thompson, "when in doubt use brute force." What's simpler - A) exhaustive audits, quarterly vulnerability assessments, section 10 level audit logging, and the full compliance check box olympics across your whole systems or B) brute force - isolate sensitive data, audit that island and expose only tokens and authorization codes to the rest? Its not even close.

The counterargument to the above is that a gateway introduces a new layer in the system and so its another middleboxen for the app server to talk to, another system on the critical path. Fair enough, but its there for a reason same as the app server is in the middle tier. The appserver is in the middle tier so that business logic and rules are centralized and reused. This is the same rationale for tokenization on a gateway - centralize the token generation and verification. Do you want all your developers writing code for generating and verifying tokens? Not bloody likely. 

Tokenization is a major trend in security because it allows systems to reduce the sprawl of sensitive data and the attendant vulnerability and audit issues. Gateways are the ideal way to deploy tokenization because 

1) the internal core operations of token generation and verification are too important to be left to individual developers. They are generic enough that they can be reused.

2) the external interfaces to the tokenization servicess- generate token and verify a token - are very simple

This is a mix that solves important security problem in a simple way and in a way that scales. Frankly there are not too many times in security architecture where this is the case and that makes tokenization on gateways is a design pattern for the long haul.

Security > 140 Conversation with John Wilander

John Wilander's perspective on software development and security sheds light on some of the many gray areas that exist between these two related but too often divergent disciplines. We discuss the current state of play, trojanizing dev teams, the different tactics involved in prescription versus proscription, and a lot more.

Gunnar Peterson: We first met a few years back, and I remember this very well, we did a detailed Threat model and discussed a very long set of security protocols that could be used to add in layers of protection around a Web services application to cope with the threats. by the time we were done, the board was covered and it was a set of dozens of capabilities that a poor developer would have to go and somehow implement (and implement correctly).

Do developers get enough support from platforms and tools to do things right? Even if they try to it seems like they are facing some heavy headwinds.

John Wilander: I'm tempted to just answer "No, sir" but that would be too simple, right?

First Answer
To start with, writing software that withstands attacks from skilled adversaries includes both dos and don'ts. This might sound obvious but it's what I consider a key contribution in my upcoming PhD on secure software. It turns out that we do discuss both but rarely at the same time. And the models of secure software we use for code and design analysis typically take one side but not the other.

Two examples of what I mean:

1. Input validation is a typical "do". You need to validate input before you let it control your execution or taint sensitive data. For any given input there is typically a limited amount of ways to do input validation correctly, but an infinite amount of ways to get it wrong, including having no input validation at all. So to be able to support developers on input validation we need models of how to get it right. A positive model if you will. We can then use that model to to static analysis, manual source code review, or to provide training.

2. Double free is a typical "don't". You shall only free up memory once. In a large C program you will find a lot of memory allocation and deallocation. If we would stick with a positive model here -- "This is how you free memory" -- we would not be able to find double free flaws through static analysis or source code review and we would not be able to train developers in secure memory deallocation. Why? Because insecure deallocation is built up of multiple instances of correct deallocation! To analyze for and convey the meaning of double free we need a negative model -- don't do this.

That summarizes my first answer to your question. Developers are not getting enough support in the dos and don'ts of secure software. They need help in not introducing vulnerabilities in the features and functions the systems is required to have. Let's call that non-functional security.

Second Answer
My second answer connects to your recall of all those protocols, layers, and measures we took in securing a web service back in 2008. Let's say we've given developers appropriate support in the dos and don'ts. On top of that we might have security requirements per se, such as authentication, authorization, and audit logging. Let's call it functional security.

The developer support in functional security is much larger. You'll find all sorts of products here. Some open source, some proprietary and expensive. An example is Microsoft's Active Directory which has helped a lot of developers to fulfill the functional security requirement of single sign-on. The problems I see in this space is in terms of configuration. It should be easy to get things right and hard to get things wrong. But look at for instance OAuth. If Facebook's security team can't get OAuth right, how are we expecting the average web app developer to get it right?

Developers have long been requesting comparative tables with security info on frameworks. Which HTML template frameworks does proper character encoding by default? Which framework versions are known to be vulnerable? The security community has yet to produce these tables and support developers in doing the right thing.

Third and Final Answer
My third and final answer to your question goes deeper into the technology stack. Why are programming languages still lacking security primitives and simple ways to "get it right"?

Two examples:

1. Why are programmers encouraged to pass around strings in the year of 2013? There's almost nothing useful in a computer system that can be described as just a "string". Meanwhile strings are killing security. Programmings languages should encourage (demand?) developers to create abstract data types that model what they are passing around. If it's human name there should be a HumanName type. If it's HTML there should be an HTMLString type. If it's a comment there should be a ForumComment type. That's how we can get input validation and semantics right.

2. Why can't developers annotate or type data as "secure" or "sensitive" directly in their source code? That way static analysis could help find information leakage. This whole area is called language-based security and has yet to turn up in any mainstream language.

Conclusion
The security community needs to cut down on the Bug Parade and start delivering useful models, tools, programming languages, and technology comparison tables to developers. Then, if they don't make use of that support we can complain about insecure software again.

GP: One company I find as an aspirational model for Software security is Autoliv. They are a Swedish company that is a world leading maker of safety gear for cars. So Toyota, Ford or whoever makes the cars, but the safety gear they get from Autoliv. Autoliv has the expertise in safety design, development and testing to pioneer advances in things like air bags.

One problem for any component maker whether its industry wide or just within an enterprise is integration. Autoliv has to be able to embed airbags inside steering wheels from many different manufacturers. So to your second answer (and great point on OAuth and Facebook BTW) "Developers have long been requesting comparative tables with security info on frameworks."

What does a useful response from security look like here? What is the right "form factor" to deliver this to development teams and when? Basically what I am asking is - how should these teams collaborate better?

JW: There's a difference between developer teams collaborating with their respective security departments (intra collaboration) and developer teams collaborating with the security community (inter collaboration).

Intra Collaboration
For intra collaboration I'm a strong believer and practitioner of IT security trojanizing development teams (pun intended). Developers need to have access to a security conscious developer daily for security to get built-in.

"Should we send this in a URL?"
"What about this security news I just read – does it apply to us?"
"What was this thing about not setting the location and instead setting the pathname?"

Such questions pop up all the time. If there's a developer with security skills on the team the questions get answered. If you instead rely on a separate security department to review the whole shebang you'd better pray you find that DOM-based XSS where they used window.location instead of window.location.pathname.

There are three problems with IT security trojanizing dev teams:

1. You have to know software development, not only IT security.
2. You have to leave your comfort zone but still maintain a healthy competence exchange with your security peers.
3. It scales poorly. You need one software savvy sec pro per development team.

Inter Collaboration
So how can the security community help developers produce more secure code? Well, I mentioned comparative tables with security info on frameworks. Security pros need to produce those. How should they look? Just steal from other services popularized among developers such as …

Can I Use: http://caniuse.com/
Grid component feature comparison: http://dojofoundation.org/packages/dgrid/#featurecomparison

A similar, security-focused table would tell developers which web frameworks do context-sensitive encoding, handle JSON in a safe way, have safe defaults for text nodes vs inner HTML etc.

Next we need to deliver security-oriented components in small pieces. Developers are very reluctant to download a huge pile of code just to get an encoding function. And rightfully so. Security pros love to build and promote draconian "enterprise security frameworks" whereas the developer world has moved on to so called micro frameworks.

Chris Schmidt's jQuery Encoder is a good example of this. Two years old and a bit buggy but short and sweet!

GP: I very much agree with your thoughts on the benefits and challenges of trojanizing app dev teams. I think anyone who has tried software security realizes pretty quickly that its fundamentally a people problem on multiple levels.

To my way of thinking, an app team should have a security person assigned (though I like your trojanized term better) the same way a DBA is assigned. DBA teams are made up of people who know Oracle, DB2, MySQL what have you and they get pulled in for x percent of time to expedite and improve dev projects. Importantly, DBAs spend their other, non-project time, hardening and streamlining their own Databases and making sure they work well. I think security has a ways to go in both productive engagement and in optimizing their own tools.

I cannot blame security teams themselves for the whole state of affairs. They have been underfunded and undermandated. The security tools are pretty weak as a group. To me the journey to getting a DBA-like level of engagement feels like Deng Xioaping's saying on gradual change "We will cross the river by feeling the stones under our feet, one by one." We can all see what some better version of an end game looks like, but getting there is painful.

In the meantime while we are gradually solving the people problem, it seems the tools and technologies vendors could step up and address at least some of the other challenges. Your comments on the pervasiveness of strings and the lack of security annotations reflect an overall benign neglect for security issues from language, frameworks and tool vendors. Is there any hope for improvement here? Do you see greenshoots? I see some promising signs in that for example iOS as a new OS began its life with a decent mix of security built in. However, one problem is that the security design is more based on protecting the platform and its less about making things easy for developers and security people, it feels like its a pretty hard job until the vendors and platforms meet them halfway. What do you think?

JW: You're right about underfunded security teams. It has gotten to the point where many are bitter and/or feisty. Some carry a backlog of things that "should have been done" and bring those things up in every project.

When it comes to security features and primitives in programming languages and frameworks I feel we're still finding issues quicker than we get generic solutions. The pressure to deliver more and more features drives complexity, for instance in the web stack. And complexity is not good for security. Then complexity increases further when we have to add security on top. Take Content Security Policy (CSP), a new HTTP response header intended to finally take on cross-site scripting (XSS). The shear complexity of getting a good CSP config off the ground is enough. Then there's the complexity CSP adds to testing, deployment, debugging, and maintenance. If we instead never would have mixed data and code and always whitelisted script sources in a header or meta tag we might have dodged the XSS problem all together with just a minor increase in complexity upfront.

A major hurdle is ease of use when it comes to security technologies and features. It's one thing avoiding vulnerabilities and another to correctly add security features. I doubt even 1% of the world's developers are able to generate a CA root, sign an SSL cert with it, and whitelist it on their local machine. Instead some buy official SSL certs for their testing environments and others skip the whole thing. Then there's using OS features for secure storage in so called key rings. Then there's single sign-on with SAML, Kerberos, Active Directory etc. Then there's cryptography and cryptographic hashing. Bring those things up and most developers frown (some smile though :).

I think developers of security APIs and technologies really need to test for developer usability. Can a B-level developer get your stuff working in one day? Will he/she start googling for blog posts and answers on Stackoverflow or will he/she feel confident with your documentation? Do you even provide a step-by-step example?

Apple's so called "walled garden" has proven very successful in keeping iOS malware-free. With Gatekeeper Apple is bringing the same thing to OS X. For the casual user a walled garden is not a problem, rather a feature. But it doesn't make benign apps secure, only avoids malicious apps. Providing usable security APIs and integrated static analysis would help developers do better security-wise. I hope that's where OS and browser vendors are going.

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

Mobile Session Management - Which Session?

Session management vulnerabilities are tricky. They are highly dependent on context. Identifying session fixation, session replay and the like means looking at the end to end session lifecycle from creation to use to termination. 

On normal webapps this is mostly a straightforward affair including - examine the session cookie, ensure proper cookie hygiene, make sure transport is protected, and that timeouts are set correctly. On normal webapps the server sets the timeout for the session cookie (say 20 minutes), sends to the browser and the server validates the session on the return trip. The session lives as a relationship between the browser client and the web server. But what about mobile sessions? They are pretty different, let's count the ways.

First off the user likely authenticates locally to the mobile app itself, let's call this session #1. Then any time the app needs to do something on the network (like synchronize data or replicate) it authenticates from the mobile app to the server, let's call this session #2. Next the server is very likely an API Gateway with no data or business logic, that is on the backend app servers, so the Mobile API Gateway has authenticate to the backend servers, let's call this session #3.

Now just logging into each of these sessions is a decent bit of work in and of itself. Add onto that the fact that very likely these are three fundamentally different protocols - maybe username/password for #1, OAuth for #2 and SAML for #3. Logging in is where it begins, but that's not where it ends.
How do you ensure consistent policy across these different protocols? When do you timeout the session? What happens if session #1 times out but sessions #2 & 3 are still alive? How do you reinstantiate? What happens when your user logs out?

Today these are mainly exercises left to the implementers to figure out, the tools market is pretty nascent. The above scenario is a pretty simple view compared to some Mobile apps. Enterprises still struggle with sessions management for webapps, ensuring session data isn't easily spoofed or stolen requires careful review, but its vastly more complicated for many mobile apps. Until ready made tools are available, enterprise's time spent on end to end design and testing that the sessions mesh appropriately is time well spent.

Update: Paul Madsen added on in Twitter "and the original SAML session from enterprise IdP"  For sure there are many combinations and permutations to consider. What I am seeing though is that a base case Mobile app has at least 3x more compelxity for session management than a base case web app. Considering may webapps still struggle this is food for thought.

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

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

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.