

What can Diaspora learn about security from Microsoft? - jdp23
http://www.talesfromthe.net/jon/?p=1940

======
tptacek
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
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
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
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.

------
woan
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-...](http://emergentchaos.com/the-security-principles-of-saltzer-and-
schroeder) Looking at open source software designed for security like postfix
can also be quite enlightening.

