1raindrop.typepad.com1 Raindrop - Gunnar Peterson's insights on security and distributed systems

Gunnar Peterson’s loosely coupled thoughts on distributed systems, security, and software that runs on them. Recent Posts Security Champions Guide to Web Application Security Security140 Conversation with Pamela Dingle on Identity 6 Things I Learned from Robert Garigue The Curious Case of API Security Security Capability Engineering Ought implies can Security140 Chat with T. Rob Wyatt on MQ and Middleware Security Privilege User Management Bubble? The part where security products solve the problem Four Often Overlooked Factors to Give Your Security Team a Fighting Chance Blogroll Adding Simplicity - An Engineering Mantra Adventures of an Eternal Optimist Andy Steingruebl Andy Thurai Anton Chuvakin Beyond the Beyond cat slave diary Ceci n’est pas un Bob ConnectID Cryptosmith Emergent Chaos: Musings from Adam Shostack on security, privacy, and economics Enterprise Integration Patterns: Gregor’s Ramblings Financial Cryptography infosec daily: blogs Jack Daniel James Kobielus James McGovern John Hagel Justice League [Cigital] Kim Cameron’s Identity Weblog Krypted - Charles Edge’s Notes from the Field Lenny Zeltser Light Blue Touchpaper Mark O’Neill Off by On ongoing Patrick Harding Perilocity Pushing String Rational Survivability rdist: setuid just for you RedMonk RiskAnalys.is Rudy Rucker Software For All Seasons Spire Security Viewpoint TaoSecurity The New School of Information Security Windley’s Technometria zenpundit Blog powered by Typepad Security Champions Guide to Web Application Security I have a new eBook available at Akamai, its called Security Champions Guide to Web Application Security . Why Security Champion? Well, AppSec is an area that often falls betwixt and between different groups, it blurs traditional lines. Basically it comes down to who cares enough to dig and try to solve the company’s WebApp security problems, they may come from Dev team or Security team or Network team or any number of places. There is usually not a role called security champion, but there is a need for someone to champion the cause of WebAppSec to craft the security plan, to get designs right, to implement the code, and to deploy. To do all of this is a broad mix of skills. The book is broken down into the following chapters- Chapter 1. Behavioral Perimeter - explores how the traditional structural perimeter needs to factor in a behavioral component, to deliver security where its needed Chapter 2 Security at Scale - simply put scale is tablestakes. If your security doesn’t scale then you do not even get invited to the party Chapter 3 Intelligent Security - security cannot just be passive and static, co-evolution is required now. Chapter 4 Integration - an effective boundary requires thinking through From-To Integration layers at both Tech and Process integration level Chapter 5 SecDevOps - security test instrumentation Chapter 6 Security Architecture Process - fostering a living, breathing boundary November 17, 2015 | Permalink | Comments (0) Security140 Conversation with Pamela Dingle on Identity For this Security140 , I discuss identity with Pam Dingle ( @pamelarosiedee ). Pam is Principal Technical Architect at Ping Identity , a veteran of building, innovating and riding the many waves of the identity ecosystem. We discuss an appropriately wide range of topics from how developers should approach identity to unempowered frogs: Gunnar Peterson: Consultants always talk about people, process and technology. However there is an old consulting truism - its never a process problem, its never a tech problem Its always a people problem. So when I go to a security conference and I talk about SAML or OAuth, I frequently get the thousand yard stare, and when I go to an Identity conference and talk about CSRF or DOR I also get blank looks. Thinking back, there are very smart and capable people at these conferences, and yet, in the main, the security people know little about identity and vice versa, It struck me that I do not even see the same people from one place to the next, about the only people I see at both types of conferences are Bob Blakley and you. These two domains, identity and security, are totally intertwined - so how do we get better cross-pollination? Pam Dingle: I see a number of things we can do to get that cross-pollination going. I think proximity breeds curiosity, and the best thing that can happen is for conferences to start creating cross-discipline tracks. A lot of professionals have limited travel budgets - so it needs to be possible for identity folks to be introduced to security concepts (and vice versa) without the barrier of cost. I also think that there are some interesting thought experiments that we could curate to merge what often feels like extremely separate paradigms. CSRF is in fact a really good example, because it has a direct bearing on the identity world (receiving a form submission and making assumptions about where it came from is not materially different from receiving an authentication or authorization response and making assumptions about where it came from). Putting security concepts into identity framing and vice versa could be a good way to start to entice people into common conversations, pulling us each out of our respective echo chambers. GP: It seems like companies’ approaches to mobile identity really cover a wide range. For better and worse, there is not a lot of consistency with how people try to solve mobile identity. You see all manner or different home grown solutions and a hodge podge of different standards (password, certs, SAML, FIDO, OAuth, MDM). Are there different challenges driving people to different architectures? Or is this just normal early days of a new technology? PD: A hodge podge is exactly the right way to characterize it. The use cases are distinct and sometimes only tangentially related, and yet somehow they all still fall under this useless umbrella classification of "mobile identity". I would say that the three most common mobile challenges we see today in Enterprises are: 1) How to secure native mobile applications that rely on REST APIs without caching user credentials on the device, 2) How to use the unique location, hardware, and proximity of a device to a user to enrich the security of an authentication ceremony, and 3) Is the device involved in either Challenge #1 or Challenge #2 a known and/or trusted and/or uncompromised device? Standards like OAuth and OpenID Connect are primarily centered on challenge #1. Standards like FIDO are centered on challenge #2, and can play a fascinating role in combining device-local authenticators with central systems in a standardized way. Product sets like MDM and EMM are centered on challenge #3. Passwords and certs could be part of the implementation of any of those challenges, although the question of securing a private key or other secret on a mobile device tends to push back into challenge #3 territory. I do think this is early days for mobile identity, and I have to say, it’s fascinating to watch the space evolve. If you are developing consumer-facing mobile apps for example, your risk assessment is radically different than an Enterprise use case - you don’t necessarily have the luxury that many Enterprises have, of refusing to run on a poorly secured device. As such, the last thing you might choose to do is put a big heavy trusted credential like a private key or a password on the device. Your best bet there might be to create a lightweight, short-lived, very tightly scoped token there, so that the attacker you assume is living on the device with your app can only steal limited stuff for a little while. Compare that to the way Enterprises think of devices, where they want to *believe* that their corporate devices are trustworthy, and are willing to pay for the promise of a safe space, so that they can build a solid foundation for a chain of trust. Is it real? Well that takes us back to identity-security...