Welcome to Software Testing Unleashed, the podcast for testers developers and software makers who live quality as an attitude. Get fresh ideas & sharp insights To grow your mindset To learn new methods And drive real change in how we build software. Better software & better teams For a better world. Hi! I'm Ritchie, software-quality coach keynote speaker and author. My guest today is Eoin Woods.
Eoin is a respected software architect, author and conference speaker with deep experience in designing and securing large systems. He's co-authored well known books on Software Architecture And has served as Chief Engineer & CTO In leading tech organizations. Eoin Is Known for his practical insights On secure software engineering And Has been awarded multiple times For His contributions to this field.
In this episode we talked about making security a first-class citizen in software development. Not something just looked on at the end of project! Why do so many teams still treat security as an afterthought, only to scramble when it's nearly too late? And if every software engineer knows security matters why does he feel so overwhelming?
And when the industry is flooded with complicated security advice, how do you choose the right principles that work on real projects without slowing down anything? We will discuss these questions in this episode. So let's go into it and enjoy. Well, thank you. Thank you for the invitation. it's very nice to be here. Yeah It's great. we had a. I think that was the last preparation call ahead for the OP conference and so We get this lot now.
And i'm very happy To have you hear because You Have A Very Interesting Topic in my Opinion Because In Testing We Have Often The Part to Test Security Things and That'S Always A Thing Which Happens Too Late. And you have the speech here, your talk is about security by design. Exactly! A first-class citizen, as opposed to the thing that's always shoved in at the end and nobody wants to touch. That is a whole idea here. Let us start into this topic. What are your ideas for that?
What are you expectations of making security by design? The really interesting things about security? I worked in security engineering. briefly security is very important. This was back many years ago and then when I started working even in large financial organizations, it was quite hard to get people interested in security. So about ten years ago I started giving talks on it and i used to get five people in the audience... And they were all security people!
Well I was just talking to people who knew about security.. And then the amazing thing that's happened is now you get a room full of people Who actually want to know about security. so thats fantastic. something has changed. It´s really great trend But still persists exactly what you talked about a moment ago just security, is it? Security performance resilience availability. There are all things that of course we know they're so important and we will get rent to them eventually you got.
That's what until us never works. as any tester will tell you if you start thinking about security in the last ten percent your project You'll gonna get ten percent security. So you really need to start early. The difficulty with that practically Is most software engineers don't have lots Of background insecurity. changing a little bit some university courses today. And I observe, at least in the UK are starting to have a lot more security right from the first year and that's terrific.
but a lot of people in industry they know about security in abstract terms. They've got authentication authorization and so on. But actually what do you? And then when they try to engage with the security community, meet security engineers. They're very clever people and that's all I do. The problem is... That's what we do! We don't know much about software delivery. They've typically come from an infrastructure background or if not did a bit of development years ago.
now they use security and just speak in different language. all of this complicated stuff the team absolutely has to do now, otherwise there will be a disaster. Whereas we know that nothing is absolute and everything's got to be in balance.".
So one thing I noticed was principles really help people...I'm a big believer in design principles to guide design decisions quite long time ago when I realised if we could identify some principles which were easy That might just get people thinking about security much earlier.
And that's when I came up with this set, the reason being...I didn't really want to invent a set but it went out And there were sets everywhere, from like minimal sets with eight or nine up to I found one that's got hundreds of principles in it. They're all valid but how would you possibly use? So i try and find a middle ground. if distills them down into a set thats pretty accessible But i think covers alot what software teams need to understand about security. Oh very good!
Let us look deeper into these ten principles. so maybe we will look at how much time do have Maybe start top five. Sure, sure. some of the important ones are things like defence in depth. it's very common today that we have very sophisticated attackers. you can't assume one security mechanism say A piece of encryption or an authentication system is going to protect you.
They may well defeat one of your mechanisms, it's really great to have more than one mechanism so that once they're in the haven't got everything. So defense and depth is quite important. The other thing is nearly every security mechanism has flaws Or we make mistakes on how we apply them. It's important not be totally reliant On what kind of security mechanism for your system.
So in really secure systems, those that for example governments defend you'll find every single layer has its own security mechanisms. They're all independent. they are interlocked. You can break into one level and just got the same problem again And what we try to do is make it very expensive to break-in. so That's always remind people don't depend on a thing. The other thing which is unfortunately still quite common don't invent your own security technology.
It's a lot harder than it looks, nearly every relatively inexperienced software engineer I've met thinks that how hard can encryption be? I read a book in it recently and got to create my own password vault."I just go,"Don't!"It sounds fun! It is a lot more harder then it looks". That goes for all kinds of mechanisms. even things look quite straight forward like integration into maybe OAuth, into authentication and authorization systems.
If you can possibly do it find a library that does it for your already? And the reason is because even security technology produced by experts or professionals has got flaws in there. The first thing they produce when they start beating with them All those expert security testers start testing immediately. They always have problems going to have no problems with yours. It's pretty slight, the other thing is just that honestly it's an overhead you don't need on your project.
yeah I know it looks fun but honestly perhaps there are better things you could be spending time in. Do you recommend if we think about libraries doing the encryption stuff? To go to open source because its more transparent? what happens there? or close source from companies do? I think it's quite context-dependent, actually. I don't think either has a monopoly on good security and you're absolutely right. the transparency around open source is quite reassuring.
There's a lot of independent security researchers looking at that stuff all the time. But certain markets for certain applications Actually there are close or solutions which They're really this superior offering And you have to ask the right questions off the vendors but they may be The right choice in your case tend to veer towards the open source ones. It really does depend what you're building. Are there any principles to fit on the process of how I develop software?
So, i can say that don't build your own. Use it but... That's one point at a whiteboard and nobody sees because they are doing their daily business. How do we deal with this? The design principles is aiming for designers. They should be thinking about when they're designing. You'll raise them much bigger. important point is, how does the whole team go about doing secure software delivery together? Really they need a secure software-delivery life cycle.
It's just sort of posh name for saying make sure you do the security work all the way through their lifecycle and there are in number of industry standard models or wasper great organization full of resources that have secured software development lifecycle. It's very well developed, it has been used by lots of people. But there are a number of models for secure software delivery out there and the number of government bodies have them as well.
so I always recommend start from Secure Software Development Life Cycle from experts. Of course you'll tailor it. Everyone tailors software development life cycles but Start form one that is being used already. Yeah thank you. we need to implement into this process A lot clients. for me they're security-one part of non-functional requirements. if they are written in any user stories. It's often too late to think about it, what does that mean? It brings security user stories into the process.
So called abuser stories, how is someone going to attack this system? That's a sort of simplified version of our technique which in all these secure development life cycles call threat modeling and that where it sounds complicated its really not. Its about sitting on team down saying okay what have we got thats valuable? Who would think it was valuable and how are they attackers in order to get that valuable thing? Could be a piece of data, could be a financial transaction.
It can be an operation. They want either enable or disable. but its question going through the process In a structured way And there's number very good books out there. Adam Shostacks is classic one on art modelling But actually quite a number which were all very good. It's as the real experts and threat model like to point out, it's a really simple process. Don't know if we're complicated but just go through the process of thinking what could go wrong? Yeah!
It is little bit like with high availability. you need sit down work at everything can go wrong. What will happen when each piece of this goes wrong once your been in that process are much better place to know how robust your system is. yeah I understand often Securities or the hackers and cyber stuff, they use a lot of day zero ports to get into a system. Is there any part we can address this new up-to-date mechanisms to solve in our design? I think it's really tough, actually.
One thing is defense in depth. we just talked about if you're relying very much on one component to keep your safe If its got a zero day then someone going to exploit that. The other things he was saying do you have strategy for keeping components up-to date? But the days of open source are difficult. Some ecosystems would be great. They have such fine-grained components, you've really got to have automated help. stay on top of that.
One of the principles in my set is trust cautiously and there's a number things that implies... For example network connections don't either make or accept unauthenticated networks. but another one is be careful what you insert into your system. What do bring it could be data. cautious about what data you accept, because there are lots of exploits that involve putting malicious data into a system. But also think And what would you do?
Unfortunately, zero days are a really intractable problem if nothing else because there is a black market in zero-days. So actually even knowing they're there can be difficult. There's only so much we could do. but definitely know what's in our system and probably having automated support particularly for the open source to keep it on top of... If there are vulnerabilities that are components or not is very important. I think there's a big, huge problem.
What you mentioned is which data can i put into my system or will allow to put in my system? A lot of clients have the landscape for applications and driving through their data. all that APIs are very lazy stuff so they're letting it go. And then I think There is a big security issue because Some of these infections can go through all the systems and then making big bang here on every edge.
So I think that's a big point to look how secure are my contracts or my APIs, in order make good interface. Yeah, I think you're absolutely right. It's a bit of a trade-off isn't it? Because the simple thing to do is always lowest common denominator make everything a string because that's going be really straightforward and not gonna reject anything.
Everything will get translated into strings somehow but people can craft very clever malicious attacks that send you malformed strings, your string presses and things are fine. But then when they're translated to something else actually perhaps just cause a failure. so it's actually denial of service attack. or perhaps do something much more subtle than malicious which ends up in for example remote command exploits. So yeah It is something we've got been really careful about.
the trade-off Um, strongly typed interfaces take longer to develop. They're less flexible. they are more difficult to evolve. so yeah I understand why people want um make them very flexible but always bear in mind if you're not validating things really really carefully. as you say As soon as you've got the ability to take large amounts of unformatted data In You've Got Potentially A Huge Security Problem. Yeah, what other principles are in your set? so we can go a little bit deeper there. Sure!
So the ones would be making sure that you use secure defaults and that you fail securely. A classic example of this goes back many, many years. When you used to install relational databases Oracle was a classic example they always enabled three or four very powerful accounts with standard passwords and in most enterprises if you knew about this. You could go up to an Oracle production Oracle system And find at least one of them still have the default password.
it wasn't like It's security cliche for many years. Have you got Oracle? In that case you'll have a Scott Tiger account meaning there is a user called Scott With a Password Tiger, it's a demo user. You can get into almost all the Oracle systems and Oracle did to be fixed that many years ago. an awful lot of open source stuff or cloud demonstration software does come with standard logins. if they're unlocked They've got standard passwords And similarly network hardware.
I'm still amazed how much Enterprise grade Network Hardware comes out default users and passwords installed, because of course it's convenient. Well yeah we know its convenient! It is completely insecure really quite dangerous... And the related thing is a bit like that don't fail to an insecure position.
so um classic example uh is years ago I know if database vendor who was very you know they were very concerned about their performance on their availability and there well known for rock solid databases used by big banks for transaction processing, that kind of thing. And they had this problem and it luckily didn't get beyond the beta stage. but uh... They built an audit into their database to customers. I asked for it. This seemed very sensible because there's a rigorous audit trail.
you know it was tamper resistant banking grade as people like to say. What did engineers do? Well of course the engineers were concerned about performance availability. so if the audits started malfunctioning or filled up then disabled auditing continued processing Because of course focused on performance and availability. Luckily, it got to be done. some customer went now hang on a minute. our audit trail filled up but then you just continued processing without the audit trial.
But You can see how they trade off happen in someone's mind. The other performance and scalability database. therefore we auditing is optional. No no just a minute! No its not similar thing if years ago when Unix systems used to panic They use come-up with them a prompt you could get into root without a password. Suttler things today are things like when you've got message-driven systems, what happens? When we're complicated multi component failure and then bring it all back up again?
does everything authenticate correctly in reduced process until you have end to end security of the system or doesn't just start processing opportunistically? Will something always wait for all the security services to be available? Those kind of questions. We're very interesting parts, I wonder how can we put more awareness in that design phase to mention these principles? because A lot of clients are very feature driven where we have to go. Very much so, yeah So how can we argument that?
We have to do this work. I'm amazed. the testers asking me about question. he answers testers Because test is always think about what can go wrong. Yeah And that's such a valuable service because most people aren't. but i like to think software architects Always thinking about what could go wrong too. But they're only human.
They're often under lots and lots of feature pressure or they may very specific quality attributes that have been a problem up till now, say it's throughput and they're focused on throughput. They know security is important but are very focussed on throughput for the two or three sprints. great job for the tester about this security stuff. We appear to have just like ignored it for a while and I'm quite concerned about, you know? This new feature appears to bypass the security control.
that's exactly what we should be paying testers do but also of course supporting testers so that testers feel they're being encouraged to ask those questions. There's always a danger the tester feels that actually they're quite unpopular for us in The Difficult Question. We should be like embracing them, thank you so much for answering our question. otherwise we'd have made a mistake!
Yeah I think it is good for all this HR and DevOps stuff too So that the testers can get into their team earlier In the process or in the past where the tester was last one who sees the software said oh my god Yes what if your done? involved is your friendly security engineer, ideally one who's got an application security background as well as infrastructure.
And make sure that you're asking them all the right questions and we are inviting them in to do some threat modelling with you be asking you all of these questions then you might not have thought if... If you've a pen test team in-house You may want use it for final tests but they very valuable. earlier on get them pen testing things early. maybe everything will fail.
Probably that's okay right now, but you're suddenly getting everyone thinking about this needs to be secure and currently we are not. So we need put the effort in. maybe even a product owner who knows might finally go. oh yeah actually That is big problem. I need spend some more time on security. Ewin, thank you very much for this inspiration. For these tips.
I think we can use it in our projects and teams to make systems more secure... ...and to think security upfront but not at the last phase of testing. Thank you so much for your insights here! You're welcome. It has been a pleasure any time now. Thank you very much, it's been a pleasure. I always love to talk security! Yeah thank you have a nice conference here.