#46 Barry Dorrans is a curmudgeon telling us it is OK to be wrong
Transcript
⚠ The following transcript was automatically generated.
❤ Help us out, Submit
a pull-request to correct potential mistakes
Tim Bourguignon 0:06
Hello, and welcome to developer's journey. The podcast shining a light on developers lives from all over the world. My name is Tim Bourguignon, and today I received Barry Dorrance. Barry is the dotnet security person at Microsoft. I've even read that you are the security curmudgeon, I, you will have to tell us what that mean. Barry has over 20 years of experience specializing in C sharp ASP. NET, and all aspects of dotnet security. Barry has been involved in major website development, production of numerous security related proof of concepts for Microsoft, and the UK Government. He's also the author of beginning ASP dotnet secure development, and was a frequent Microsoft MVP recipient before joining Microsoft, very welcome to the journey.
Barry Dorrans 0:59
Thank you very much for having me. So you don't know what a curmudgeon is?
Tim Bourguignon 1:04
No, is this a British word?
Barry Dorrans 1:07
It is a very British word. It is a okay. It's a grumpy old man. Someone that is grumpy and angry at pretty much everything. Which is 90 to a tee is the sort of person that shook their fist and thought Brexit was a good idea. It's probably, although I don't, it's probably a curmudgeon people that shouted children playing on the grass, that that's the sort of thing. And you might hear some someone that's unhappy world, and I'm generally unhappy with the world because the world is insecure.
Tim Bourguignon 1:49
So you're shouting at developers? We're playing on the grass?
Barry Dorrans 1:53
Yes, very, very much get off that grass. It's not hashed and salted properly.
Tim Bourguignon 2:00
It's very fitting. I'm right. I'm reading the book blackout from a from an Austrian author. And it's the story of one of people hacked into, into the security services of our electricity infrastructure and basically turned off electricity for Europe and an a bit more. And this is the would make you mad, I would say,
Barry Dorrans 2:29
get the mark Ellsberg one. Absolutely. I've I've heard about it. Would it made me mad because the security is not there. Because the way he discusses it just isn't correct. It's one it's a
Tim Bourguignon 2:40
I know, I think it's pretty correct. But the security is non existent.
Barry Dorrans 2:46
Yeah, that's that's probably pretty correct to.
Tim Bourguignon 2:50
Unfortunately, unfortunately, it's hard to remain stoic while listening to it. So I would understand what you live on a day to day basis being a security expert in our mme Earth. But I guess we have to roll back a little and see how you kink to being there in the first place. Do you want to tell us this story?
Barry Dorrans 3:12
I, I was thinking about this this morning. So I guess what listeners have to realize is that in 2009, teen, in fact, in about a month and a half, I will be 49. So that puts me I'm a lot older than most of the young kids these days that swap JavaScript frameworks every day, to try and keep up with things. So when I started, it was in school, because that's where computers were, my parents were not well off. My dad was a builder. My mom was a secretary. And so the first computer I encountered was this large black and chrome box that sat underneath a black and white television, because that's right kids at the time, television did not have color, let alone high definition. And it used eight inch hard sectored floppy drives. It was published by research machines, I cannot remember the model. And at the age of 12, or 13, our headmaster took an introduction to computers class. And he basically read down the instructions every day. And then got confused when the programs that he wrote did not work. And I sat and I watched because there was not enough hardware for everyone you would perhaps get it turned about once a month. And every time the programs failed, I see more and more. And so I asked if I could read the manual. Probably the last time I ever read a manual, and he gave me the manual and then before each lesson, we'd actually end up going through the code and try and figure out where the code broke. So between our headmaster and myself, we call each other a little bit. And that was my first introduction to computing.
Tim Bourguignon 5:09
How old were you at the time?
Barry Dorrans 5:11
I'm 12, or 13. So 19 8080 to 1983. There were no computers available before that, unlike now, where you're going into school, and there are iPads or Chromebooks absolutely everywhere. This was the first time I had really even seen a computer. And then maybe three, four years later, suddenly, there were BBC micros, the BBC started putting together both a computer A, which was produced by acorn, and a bunch of teaching programs that were shown every week. And schools got these things at a discount that was paid for by the government. And suddenly, there was a computer lab with lots of computers. And you could go in, and you could take no a five and a quarter inch floppy, coming down from the inches. And you could teach yourself and you you started learning yourselves and the manuals were available, and these programs are available. And every week, something would be on TV, showing you something new, and showing you how to code something new. I mean, there were formal lessons as well. But at that point, I was already not particularly paying attention to people who knew more than me, and I just taught myself and
Tim Bourguignon 6:31
what was so interesting to you at the time,
Barry Dorrans 6:34
I think it's the fact that, in theory, I could make the computer do what I wanted it to do. Whereas making people do what you want to do is a lot harder, and generally frowned upon by society.
Tim Bourguignon 6:54
That's very true.
Barry Dorrans 6:57
Yes, I mean, of course, we both know that trying to get a computer to do what you want it to do, has become less and less likely, as computers have become more and more powerful. But when it was a lot simpler when you were coding things in basic, and you had 16 K, in which to program there was less scope for things to go wrong, because it could only do so many things.
Tim Bourguignon 7:21
I guess your expectations were trickle down as well.
Barry Dorrans 7:24
I don't know if that's true. I think my my expectations were the maximum they could be for the technology at the time. And then has technology has improved, obviously your expectations go up with it. But they weren't hampered that. I wanted it to be the best that it could be. I wanted to see, you know, lots of vector graphics, I wanted it to to make the same sorts of noise that the the original Battlestar Galactica made when they're when the fire ships shot down the tube, because that's the sort of technology we were talking about. And you are limited by the technology at the time, but your aspects, your expectations are not limited. Because what you have in front of you is the best that it can be. You're right. That's what makes security. your expectations are that hopefully everyone will get it right. And then every day, you get proved wrong by some newspaper report or another where another company has leaked all your information or your social security number has gone up, or people have reused passwords in a corporate Twitter account has been taken over to hilarious or offensive results. Because now now security isn't just a matter of computing power, it's also a matter of people. And like I say, getting people to do what you want, and forcing them to do what you want is more complicated than it appears. And sometimes not what people want to do.
Tim Bourguignon 9:11
You said you would expect people to to get it right. Do we really expect people to get it right? I mean, the world is getting more complex every day for for developers. How do how do we help them make it right in, for instance, in a security context?
Barry Dorrans 9:29
Yeah, I think expect is probably the wrong word. I think hope my game more be more accurate. It's gonna depend on the person that you target. So for example, I have all my email in my own office 365 subscription, so that has my own Azure AD. connected to it. I also host my parents emails. And whilst I can enforce two factor authentication for my mother To a certain extent, enforcing it for my dad is more difficult because he doesn't understand the need. And he doesn't understand why he's blocked from checking his email. So generally, he gives it to my mother and says, fix this, which is great because she can. But Different people have different expectations, I've set up two factor authentication on my mother's phone with an application. But a couple of years ago, the American Oh, now I have to try and remember the right department, because I still haven't been here long enough to remember these things. The American social security folks, the people that look after the small pension that America gives you or your disability pay, decided to add two factor authentication to their website. So they added it by text message. And most security professionals will tell you that authentication via text message is not secure and should be avoided. But if you think about the vast majority of people who have pensions in the United States, they may not have a computer at all. And they're certainly less likely to have a smartphone. So you can't give them the most secure option. By default, you can't force it on them, because it may lock a bunch of users out. So every user has different expectations and different abilities. And blaming security breaches on the user isn't fair. And I think and I've done it myself, I'm sure I'm sure I have, I'm sure someone will find me blaming users on Twitter and victim blaming. But it's not fair. It's up to us as an industry to help make things easier and safer by default, and to guide people dying a safe line, rather than throw them into a pit of failure. And that goes further, that goes further into things like API design. So, you know, I concern myself with the way that the dotnet framework and dotnet core present API's to users. Now, a lot of times we are constrained in what we can do because of backwards compatibility. But when we write new features, it should be easy. It should be the default, that those features are secure by default, without needing any thought or input from a developer. API design can be a security concern. And that's something a lot of developers unfortunately ignore.
Tim Bourguignon 12:43
Are you involve, early enough in the discussions to to be able to steer this discussion.
Barry Dorrans 12:52
To be honest, it will depend on the API. Some things will slip past me that will get picked up other colleagues who are security focused. And that's where sometimes like when the entire area, certainly a lot of the ASP. NET security stuff ends up in my lap, because I sit in the same room as the ASP. NET people. But they're, you know, I have to rely on developers knowing that something may have security concerns and tagging me. Otherwise, I find out later than I'd like. And then there are interesting discussions of Well, no, this needs to be redesigned. Versus Well, we've committed to it now. Because at the end of the day, you know, you can try and make things secure. But people above you may go, okay, that the cost for that is too great. And we accept the risk. As much as I would like to get my way all the time. It doesn't happen. There are various reasons it doesn't happen back compat cost. It just doesn't make sense. from a business point of view right now. These things happening, you just have to accept it. That's probably the most depressing part of the job where it's like, I want to fix absolutely everything. But I can't
Tim Bourguignon 14:04
I have similar discussions with our company on what's a security person right now, a company used to be very small, we used to be 30 persons. And we grew up over the past few years to almost 100 now, and we are facing these kind of challenges, where now we have somebody that is taking care of our security and stuff like this. And involving this person early enough in every part of the process is is awful. It's really something we have to remember ourselves to do. Not awful from from the perspective of involving the person, but remembering ourselves to involve this person and that he should be involved early enough is really, really hard to get into in our brains. So when understand in them in the security context, developing dotnet code, which will be a framework used by millions of developers. That is kind of a Scary. So I
Barry Dorrans 15:01
think it's a, I trust that I trust everyone here to actually know that what they do impacts others. I mean, there are a bunch of things that never, ever need my input because it doesn't touch security. Everyone knows, you know, if you're going to touch the cryptography stack, they're going to have to come talk to me, if you want to do authentication or authorization, or weird file formats, you come talk to me, but a good example of this is binary format or binary format, or has long been known to be insecure for use with trusted input. We have been saying this for probably 10 years. Now, it's not just a problem with dotnet. Java has the same problem. The Apache struts vulnerabilities that had remote code execution were around this sort of unconstrained serialization D serialization. And in dotnet, core one, we removed it much to the annoyance of an awful lot of customers who were using it and wanted to move to dotnet core. So in dotnet, core 2.0, it came back with a bunch of warnings saying don't use this with untrusted input. And we can't help you beyond that. We've told you, it's bad. We've told you that you can, you know, you can shoot yourself in the foot with this. But if you choose to use it, and you shoot yourself in the foot, we can't be prescriptive enough to say no, we have to empower you to do what you need to do. And sometimes what you need to do is something silly from a security perspective, I can't hold your hand all the way to the end, unfortunately, some responsibility will always lie with the user of an API.
Tim Bourguignon 16:58
But this is part of the framework that you identified being potentially dangerous. How about dealing with the things that you didn't really identify yet? Are there such cases? That must be right?
Barry Dorrans 17:11
I'm pretty sure there are an awful lot of cases otherwise, we wouldn't have Patch Tuesday. Patch Tuesday is yes, Patch Tuesday is the result of us finding preferably, or someone else finding security bugs and us having a patch, I am not going to lie to anyone and say the dotnet framework is 100% secure, and anything you write in, it will never get breached. That's pretty much a lie. Sometimes, in fact, most times, I would probably say now, the breach is down to what you've done with it rather than the framework itself. But there are always going to be bugs in the framework or bugs in our templates, where someone's made a, you know, a spelling mistake or messed up higher forum posts, when it should have been a get or vice versa. These things happen. That's That's why we have patches and it's it's what gives me stomach upsets this this time of month because it's Patch Tuesday tomorrow, as we record that, although there's there's nothing dotnet going out tomorrow, so that this is actually a black month for me. But these things happen, these things happen where I get you know, email sent to me while I'm on honeymoon, I have to answer or emails sent to me at the weekend from VPS where I have to like, tell my wife, okay, we're gonna delay going out for dinner a bit. She's very understanding about this, I think that's probably a good thing. If you want to go into security, find an understanding partner who realizes that security probably will come first more than they will an awful lot of the time how much
Tim Bourguignon 18:52
of your time is spent hunting these vulnerabilities that you don't know yet. So really trying to explore the existing code and try to find new stuff versus trying to to polish the existing the existing flow that you are giving out to the users to make them fall into the pit of success. So make it even easier to not make the the silly, silly, easier mistakes.
Barry Dorrans 19:24
So I think I think in my case, a lot of it is is flow design. But you have to remember that I'm really a PM, rather than developer. So I definitely say make this better, and rely on everyone else to do the real work, which is a wonderful position to be in for feature design. The things that you see on screen in ASP. NET templates, then I'm responsible for looking at the flow. And then the implementation gets written in and I look at the implementation and go that's not what I had expected and there's a bit of a negotiation to try and tighten things up. I don't tend to have For bugs in existing code, that tends to get driven either by one of the developers curiosity, or if we've had a bug report, we go looking for other things that might match that sort of approach. So we do what's called variant analysis where we'll get a bug in one area, and we'll go okay, but that could also apply here, here, here and here. So the developers will go off and do that. And then I generally tend to summarize the results and go beat people up and say, okay, we need the resources to fix this, please allocate these resources and something else, and I'd like to have it done within X amount of weeks.
Tim Bourguignon 20:39
Now make makes sense. Makes sense. Um, I would like to earn to scroll back a little, if you don't mind. How did you end up in security in the first place.
Barry Dorrans 20:49
So after the after the five and a quarter inch floppies, and the BBC Micro, my parents saved up, and I'm sure it must have been ridiculously expensive for them. And they got me a zedeck spectrum, as it was called in Europe. I think it was the Timex Sinclair for us listeners, it had this little rubber keyboard that people described as feeling like dead flash. And that was me at home, and everything was still in basic at that point in time, and you would save things to a tip drive. So from there, I kind of figured that this was where I wanted to be, I don't think I'm sure by the age of 14, I don't think I ever had any other job in mind. But I wasn't particularly disciplined in school. And I never had good luck with exams. So I could study and then as soon as I sat down and saw an exam paper in front of me, everything went out of my head. So my exam results were not. They were not great. I managed to get into a Polytechnic when they still existed. So those were the more vocational, higher education establishments, and I went from Northern Ireland to Liverpool. And during the first year, that Polytechnic, the top Pascal and COBOL. Now this was 1988, COBOL was was not a good language to learn, unless you wanted to go work for an insurance firm. And after that year, I was utterly sick of education. So I am binding debt, which probably was the stupidest thing I've ever done. I abandoned it. And I went home and I started looking for a job. And because Northern Ireland was a region with very high unemployment, there was an awful lot of government money, and in fact, eu money, pumped into it, to give young people jobs in areas that they wanted. So I managed to get onto one of those skiing's. And I joined a local firm, basically, as their computer dog's body. So it was support for people using PCs, who were writing like Word Processing documents, or support for IBM terminals plugged into an IBM mini computer that were driving the manufacturing line, and an opportunity came up to try and print out barcode labels for the products that we were producing. And so I don't even know how it felt to me, I think my ego said, I can do this, why didn't you give me a shot. The only developers in the company were developers for the mainframes. There were no PC developers, but the printer would only plug into a PC. So I had to get this PC to talk to the mainframe, and parse the results of a mainframe and then format them correctly and send it to a printer to print out a barcode. And my ego thought I can do this really quickly. the actuality of it was it took me like three and a half months to figure out, we had an expansion card plugged into the token ring network, where I could see the mainframes hard drive as just another drive on the PC. I had a bunch of quick basic that would then take that comma delimited file and parse through it every night. Because there were like, two or 300 entries, and that's how long it would take to parse because this was an IBM XT, and then send the write commands to a LaserJet printer that had special commands to print out barcodes. And it was done. And that was my first programming job that I fitted around also trying to support a network and lay new network cables and get Novell NetWare light installed. And then basically once that placement was up, I moved to England and I know laid my way into a programming job. I said I had way more experience than I did. It was a programming job for a SIM, a C program, I basically bought Koenig and Ritchie three days beforehand, I read through it. And I completely lied. I lied my way into saying that I knew enough See, to be productive. And it turns out that probably about four or five weeks later, I was lucky enough to have had a patient mentor at that company. Let me learn, and let me get productive on the way it went. Cool. But no fourth edition. And I think that that was my biggest mistake, I probably should have stuck with it and learn a bit more about the basics.
Tim Bourguignon 25:42
Well, you ended up at a pretty decent place, I think. So I'm not sure that that was a mistake in the first place.
Barry Dorrans 25:51
I think it would have been easier for me to get here. If I had some sort of basis in computer science, I had applied to Microsoft seven or eight times in the course of four years. And to get to the first job I had at Microsoft, it was almost pulling strings. I was over for the Microsoft value professional summit. And I knew a couple of people who had jobs that I thought I could do. And I emailed them the first day of the summit saying, Hey, I'm actually over here. Why don't I come sit in your office? And I'll interview for this? And two of them said, Sure. Okay, if you're over and I don't have to pay your flight, fine. And my response was sure, you just have to play the pay the cost to change the flight, and they're like, okay, we can do that. So I yeah, I might have bullied myself in here as well, along with demonstrating some sort of skill, at least this time. I can remember one of the guys interviewing me for the the first job I had. And he said, Okay, so you know, dotnet? And I'm like, Yes, which I did. That wasn't a lie, said, Okay, so we're going to spend this hour talking about intermediate language, the thing that dotnet produces before then compiles all the way down, and I went, that's great. But it'll be a really short conversation. So because I didn't know it, I think maybe that honesty might appreciate it. I know, when I've interviewed people, honesty about what you don't know, is appreciated, probably more than showing what you do. Because if you're at that honesty level, and then you can follow up with but let's see if I can get there and start from some sort of best principles and see how far you can get that sort of thing is, is very interesting, at least to me, on the rare occasions that I interview people,
Tim Bourguignon 27:55
it is indeed. So that was the your first your first time applying for Microsoft, was it?
Barry Dorrans 28:01
No, that would have been probably about number six or number seven, okay, I applied for a bunch of rope stuff to UK. And then I was over in Seattle, and I'm like, Okay, I know you people have jobs open, I find a couple of people when Please let me interview that for this whilst I'm here, but had been turned by turned down by Microsoft UK on numerous occasions. And I think they were probably correct in turning me down for the roles that they turned me down for it was things like what is now considered a developer advocate. So you go out and you talk to customers, and try and show them how to use dotnet correctly or to the, you know, in the best way that they can. And my I think the phrase someone used was I don't suffer fools gladly. So putting me in that sort of role probably would have been a mistake, because people might have been told exactly what I thought of them. Which still happens upon occasion, but normally, it's for internal people or fellow British people on Twitter because we like insulting each other. That just seems to be the right way to go about things. But oh, no, no customer, customer facing.
Barry Dorrans 29:18
good experience.
Tim Bourguignon 29:20
That's the curmudgeon, again,
Barry Dorrans 29:22
that very probably is yes.
Tim Bourguignon 29:26
What attracts attracted or still attracts you that much about Microsoft that you applied that many times.
Barry Dorrans 29:35
For, I think what what what still keeps me going now is that if I can secure if I can keep improving security on dotnet. I am securing not just developers but their users. It's it's very hard outside of say Microsoft, Google or Apple to find a security role that has this much impact that touches this many people that helps this many people, even if they never ever see it. The scope to to help is enormous. Of course, the scope to damage is also enormous, which is the sort of thing that keeps you up at night. But when you get it right, and you know that, you know, this little tweak that we've made to dotnet is probably going to secure every single dotnet program out there. And goodness knows how many of those there are. And then there's the users on top of that, that's an awful lot of people and you can help be secure.
Tim Bourguignon 30:34
That is indeed that is neat. That's a very, very interesting, interesting answer. That's true. That's true. Unfortunately, our time box is running away from us. We don't have that much time left. So when I ask you to so I would like to ask you one, one last question. Um, you already said that, that you would probably advise yourself to, to finish your degree and and get some formal education. So I want to ask you that. If you were hiring today, and or you had a new hire on your site, what would be the the advice you would give this? This new hire?
Barry Dorrans 31:10
Oh, okay. So let's say if the hire was, was a security person, I think no one is ever going to know everything. It's okay to be wrong.
It's not okay to remain wrong.
If, if people can demonstrate to you that you're wrong, you need to learn from that and not just say, Well, no, no, this is the way I was taught. Or this is the way that I learned, or this is the way that it was five years ago, if we look at for example, cryptography 10 years ago, we were told that using the MD five algorithm for hashing was fine. It is demonstrably broken. The same with Sha one, critical security and cryptography move on. You have to keep learning, you can't just do something because that's the way it's always been. And you have to find a way to express that to other people in such a way that they weren't rejected out of hand something that if I'm honest, I'm pretty poor up, because a lot of the time I go, okay, no, you need to do it this way. And then there are times I will forget to follow up with why. And the Why is the important part in convincing people. The nice thing here at Microsoft is people are used to me for gain, and they'll just reply with going but why? And then I went Oh, yeah, okay, I forgotten that. But, but a lot of times people have that patience with you, it's up to you to remember to explain not just that something is wrong, but why it's wrong. And to educate and to teach, and make sure that you're also doing that with yourself. And you're keeping up with the latest trends and the latest standard. And basically what changes because it's just permanently changing.
Tim Bourguignon 33:07
very insightful. Thank you very much for that. You're welcome. If the listeners wanted to, to ask you why in person, where where should they go and and ask that.
Barry Dorrans 33:18
Right now I only have one thing I have
info share in
Gdansk, which for the American listeners is Poland, because I know your geography is awful. I try and ask my wife where places are in Europe. And the answers are usually hilarious. That's but that's on May the May the ninth. And hopefully, I believe I'm going to end up talking about some security bugs that have caused msrc cases and how you might still have them in your own implementations of code. But generally, it's I do developer conferences rather than security conferences, because securing developers is basically where I want to be.
Tim Bourguignon 33:59
So if you're in Poland in May, I think it is yes, may the EU it may the eighth or ninth, okay. So if you're in Poland in me on the eighth or ninth, and I go to this conference, then you can get very in real life. And Gary asked him why and how he ended up with Microsoft, or how the first interviews went? Because we didn't have time to discuss about that. And if and if people want to, to tag along on internet, or would Twitter be the right place to go?
Barry Dorrans 34:30
Yes, I think if you Although if you look at my Twitter feed, it's probably about 10% Information Security 15% dog pictures, and then the rest is basically insulting my friends and talking about pineapple on pizza. But you could certainly lots of swearing, you can certainly feel free to to follow me on Twitter. It's at blow Dart bl o w d a r t.
Tim Bourguignon 34:56
Then I will add that to the show notes. Thank you Very much Barry just been very insightful. You. Thank you for having me. It was my pleasure. And this has been another episode of developer's journey, and we'll see each other in two weeks. Bye.
Dear listener, if you haven't subscribed yet, you can find this podcast on iTunes, Google music, Stitcher, Spotify, and much more, head over to WWE www journey dot info to read the shownotes find all the links mentioned during the episode. And of course, links to the podcast on all these platforms. Don't miss the next developer's journey story by subscribing to the podcast with the app of your choice right now. And if you like what we do, please rate the podcast, write a comment on those platforms, and promote the podcast and social media. This really helps fellow developers discover the podcast and those fantastic journeys. Thank you