4 ms·

What can Diaspora learn about security from Microsoft?

6 points by jdp23 16y ago

tptacek 16y ago
Quick hits: 1. Train the developers. This is probably the highest-value thing Microsoft did, but they were starting from zero. 2. Do threat modeling. Startups, as a rule, never do this exercise, which involves plotting the roles of users and attacker objectives and mapping them to inputs to guide development and testing. Not a high return on investment for a small team. 3. Use the tools. The author is oddly fixated on the tools provided by the Ruby/Web environment, especially given the fact that there's one tool they really need --- Burp Suite --- that has little to do with spec testing. 4. Include security in the software lifecycle. This means something at Microsoft (security is a gating step at design, at implementation, and in testing), but doesn't mean something for a team that has gotten a minimum viable social network out the door with little to no testing. You might as well ask them not to be a startup. 5. Be wary of legacy code. What legacy code? 6. Reach out to the security community. If they had just set up a page for security contacts, they probably could avoided most of their recent security drama, so this rings true.
- mahmud 16y ago
  What do you use for threat modeling? Is there some sort of common formal process, even tools? Or is it still pen and paper / spreadsheets?
  - tptacek 16y ago
    We have an internal, formal process. I think it works well if you have an established SDL; if you can point to your team and say "we're in the design phase, and this is the deliverable from that phase, and this is how it will govern development", then threat models are a valuable addition to that process. But unlike training, code review, and testing, threat models are actually closer to a project management tool than they are to a technical safeguard. I wouldn't invest in it until you feel like you've got a groove going with code review and testing.
    - mahmud 16y ago
      I always thought something like that ought to be better integrated with development. Threat modeling should, ultimately, dictate not only input validation, but also application deployment and architecture. However, I am not sure how best to do this without falling into the rabbit-hole of type systems, and semantic consistency of programming languages. Not to mention the arduous task of compiling "semantic signatures" of system libraries, OS facilities, known 3rd party application limitations/bugs, protocols, in addition to "business rules" that dictate how the application is used. Maybe one day, when systems software is generated by an Eclipse plugin, and the stubs, with unit tests and design-by-contract guards sent off to minion coders to fill in the blanks. In the mean time, anybody attempting to formalize this seriously risks becoming a theory-weenie, working in a "perfect formal system." For now, ad-hoc reigns.
  - jdp23 16y ago
    There are some threat modeling tools out there -- Microsoft has one (although I haven't used it) at http://www.microsoft.com/security/sdl/getstarted/threatmodeling.aspx http://www.microsoft.com/security/sdl/getstarted/threatmodel... (there are also soime good links on the right). or it can be less formal, like the EOP game http://www.microsoft.com/security/sdl/eop.aspx http://www.microsoft.com/security/sdl/eop.aspx pencil and paper works well for doing an initial threat model, although not for sharing it and evolving it over time. threat modeling does have some project management and QA aspects (it's a good basis for generating a security testing plan) ... it's also very educational in helping developers learn to think about things from a security perspective.
- jdp23 16y ago
  Thanks for the feedback.... 1. Looking at the code base they've released so far, Diaspora is starting from zero as well 2. I agree that startups don't do that. The result is insecure code. If Diaspora gains a reputation for bad security, people won't trust them. 3. Well, I'm a tools guy. Burp Suite looks great too, I didn't know about it, but it's just naive to say "that's the only tool you need". 4. I agree that Diaspora's made the right tradeoff so far in getting a minimum viable product out -- I had discussed that in my previous post. The question is, what next? 5. Everything they've written so far. 6. Setting up a page for security contacts is certainly a good first step.
  - tptacek 16y ago
    The Microsoft SDL steps you laid out depend, in varying degrees, on an organizational momentum that a 4-person dev team simply can't generate. Training, threat modeling, and serious community outreach are simply bad investments for them. There are 4-person teams out there that have fielded secure web applications. None of them follow the Microsoft SDL security practices. I like Microsoft, but most things that work for them won't work for startups.
    - jdp23 16y ago
      Thanks again, excellent feedback. My network in the security space is somewhat Microsoft-centric and tools-centric so I've probably been thinking too much in that direction. I'd be surprised if people were building highly-secure web apps involving personal information, photos, and friendships without threat modeling ... would love to see counterexamples. anything you can share?
      - tptacek 16y ago
        I can't really share specifics, but, suffice it to say that it is uncommon to find any web app startup doing formal threat modeling.
        jdp23 16y ago
- Locke1689 16y ago
  4. Include security in the software lifecycle. This means something at Microsoft (security is a gating step at design, at implementation, and in testing), but doesn't mean something for a team that has gotten a minimum viable social network out the door with little to no testing. You might as well ask them not to be a startup. I'd agree with this. From my experience, the most effective part of Microsoft's security practice is that we had dedicated developers whose only job is to evaluate the security of proposed changesets. This doesn't really help a startup that doesn't even have a product yet and only a handful of developers.
woan 16y ago
I don't think anyone gets taught security in CS (seems relegated to informatics or computer engineering programs). Outside of a handful of security researchers and those directly working on security products, I don't even know very many senior software engineers that really understand security outside the trivial rules of thumbs. Two books largely on the MS way: "Writing Secure Code: Practical Strategies and Proven Techniques for Building Secure Applications in a Networked World" and "Threat Modeling (Microsoft Professional)" I read both of them years ago when I thought I might take a job in security products at MS, and didn't think much of them. Every developer should have to go back to some of the original IT security papers like Saltzer and Schroeder and think about every way their current framework or design probably compromises a basic principle and whether it is a good thing: http://emergentchaos.com/the-security-principles-of-saltzer-and-schroeder http://emergentchaos.com/the-security-principles-of-saltzer-... Looking at open source software designed for security like postfix can also be quite enlightening.

6 points by jdp23 16y ago

Quick hits: 1. Train the developers. This is probably the highest-value thing Microsoft did, but they were starting from zero. 2. Do threat modeling. Startups, as a rule, never do this exercise, which involves plotting the roles of users and attacker objectives and mapping them to inputs to guide development and testing. Not a high return on investment for a small team. 3. Use the tools. The author is oddly fixated on the tools provided by the Ruby/Web environment, especially given the fact that there's one tool they really need --- Burp Suite --- that has little to do with spec testing. 4. Include security in the software lifecycle. This means something at Microsoft (security is a gating step at design, at implementation, and in testing), but doesn't mean something for a team that has gotten a minimum viable social network out the door with little to no testing. You might as well ask them not to be a startup. 5. Be wary of legacy code. What legacy code? 6. Reach out to the security community. If they had just set up a page for security contacts, they probably could avoided most of their recent security drama, so this rings true.

mahmud 16y ago
What do you use for threat modeling? Is there some sort of common formal process, even tools? Or is it still pen and paper / spreadsheets?
- tptacek 16y ago
  We have an internal, formal process. I think it works well if you have an established SDL; if you can point to your team and say "we're in the design phase, and this is the deliverable from that phase, and this is how it will govern development", then threat models are a valuable addition to that process. But unlike training, code review, and testing, threat models are actually closer to a project management tool than they are to a technical safeguard. I wouldn't invest in it until you feel like you've got a groove going with code review and testing.
  - mahmud 16y ago
    I always thought something like that ought to be better integrated with development. Threat modeling should, ultimately, dictate not only input validation, but also application deployment and architecture. However, I am not sure how best to do this without falling into the rabbit-hole of type systems, and semantic consistency of programming languages. Not to mention the arduous task of compiling "semantic signatures" of system libraries, OS facilities, known 3rd party application limitations/bugs, protocols, in addition to "business rules" that dictate how the application is used. Maybe one day, when systems software is generated by an Eclipse plugin, and the stubs, with unit tests and design-by-contract guards sent off to minion coders to fill in the blanks. In the mean time, anybody attempting to formalize this seriously risks becoming a theory-weenie, working in a "perfect formal system." For now, ad-hoc reigns.
- jdp23 16y ago
  There are some threat modeling tools out there -- Microsoft has one (although I haven't used it) at http://www.microsoft.com/security/sdl/getstarted/threatmodeling.aspx http://www.microsoft.com/security/sdl/getstarted/threatmodel... (there are also soime good links on the right). or it can be less formal, like the EOP game http://www.microsoft.com/security/sdl/eop.aspx http://www.microsoft.com/security/sdl/eop.aspx pencil and paper works well for doing an initial threat model, although not for sharing it and evolving it over time. threat modeling does have some project management and QA aspects (it's a good basis for generating a security testing plan) ... it's also very educational in helping developers learn to think about things from a security perspective.
jdp23 16y ago
Thanks for the feedback.... 1. Looking at the code base they've released so far, Diaspora is starting from zero as well 2. I agree that startups don't do that. The result is insecure code. If Diaspora gains a reputation for bad security, people won't trust them. 3. Well, I'm a tools guy. Burp Suite looks great too, I didn't know about it, but it's just naive to say "that's the only tool you need". 4. I agree that Diaspora's made the right tradeoff so far in getting a minimum viable product out -- I had discussed that in my previous post. The question is, what next? 5. Everything they've written so far. 6. Setting up a page for security contacts is certainly a good first step.
- tptacek 16y ago
  The Microsoft SDL steps you laid out depend, in varying degrees, on an organizational momentum that a 4-person dev team simply can't generate. Training, threat modeling, and serious community outreach are simply bad investments for them. There are 4-person teams out there that have fielded secure web applications. None of them follow the Microsoft SDL security practices. I like Microsoft, but most things that work for them won't work for startups.
  - jdp23 16y ago
    Thanks again, excellent feedback. My network in the security space is somewhat Microsoft-centric and tools-centric so I've probably been thinking too much in that direction. I'd be surprised if people were building highly-secure web apps involving personal information, photos, and friendships without threat modeling ... would love to see counterexamples. anything you can share?
    - tptacek 16y ago
      I can't really share specifics, but, suffice it to say that it is uncommon to find any web app startup doing formal threat modeling.
      - jdp23 16y ago
Locke1689 16y ago
4. Include security in the software lifecycle. This means something at Microsoft (security is a gating step at design, at implementation, and in testing), but doesn't mean something for a team that has gotten a minimum viable social network out the door with little to no testing. You might as well ask them not to be a startup. I'd agree with this. From my experience, the most effective part of Microsoft's security practice is that we had dedicated developers whose only job is to evaluate the security of proposed changesets. This doesn't really help a startup that doesn't even have a product yet and only a handful of developers.

woan 16y ago

I don't think anyone gets taught security in CS (seems relegated to informatics or computer engineering programs). Outside of a handful of security researchers and those directly working on security products, I don't even know very many senior software engineers that really understand security outside the trivial rules of thumbs. Two books largely on the MS way: "Writing Secure Code: Practical Strategies and Proven Techniques for Building Secure Applications in a Networked World" and "Threat Modeling (Microsoft Professional)" I read both of them years ago when I thought I might take a job in security products at MS, and didn't think much of them. Every developer should have to go back to some of the original IT security papers like Saltzer and Schroeder and think about every way their current framework or design probably compromises a basic principle and whether it is a good thing: http://emergentchaos.com/the-security-principles-of-saltzer-and-schroeder http://emergentchaos.com/the-security-principles-of-saltzer-... Looking at open source software designed for security like postfix can also be quite enlightening.