This post originated from an RSS feed registered with Web Buzz by Tim Vernum. Original Post: Strengthen the security approach of your team Feed Title: Secure by Design Feed URL: http://www.securearchitecture.net/feed/rss2 Feed Description: A blog about the intersection of security and architecture Latest Web Buzz Posts Latest Web Buzz Posts by Tim Vernum Latest Posts From Secure by Design

When I'm doing security consulting to development teams one of the things we stress is that it's important to start taking the first steps towards improving your security posture. Moving your development team so that it's performing at the highest levels of maturity can take a lot of work (although I still recommend it), but the first step is ... well ... to take the first step.

I've been working on an article on Role Based Authentication, but it's taking more work than I planned to get it right. It looks like it might turn into a series of articles, hopefully I'll get the first one done before the new year.
But in the meantime, I thought I'd head in a different direction.

I thought I'd offer three things you can do to help life the security capability of your team. Not every team will be able to do all 3, but I've intentionally chosen 3 things that attack the problem from different angles, and that have different barriers to entry. I'm pretty confident that every team could do at least one of these. And, I'd even go so far as to say that even if you don't have a great deal of influence over the rest of your team, you can still start to do one of these things.

So, without further ado - 3 things you can starting doing this week to improve the security capability of your team:

1. Code Reviews

Everyone knows you're supposed to perform code reviews. Almost everyone wants to perform code reviews. Lots of places do perform code reviews. But not many people that I talk to are confident about the quality of their code reviews.

OWASP's code review guide says this:

Code review is probably the single-most effective technique for identifying security flaws. When used together with automated tools and manual penetration testing, code review can significantly increase the cost effectiveness of an application security verification effort.

But, if teams aren't confident in their code review process, then how can they be confident that they are effective in contributing to their application security verification?
So, if you want to make an immediate step towards improving your code review process (especially if you don't have one yet) then do 2 things.

1. Work out what your code review process is supposed to achieve. Are you looking for security vulnerabilities (you should be)? Are you checking against an agreed coding style? Are you looking for bugs? Are you checking that it meets the requirements? There's lots of reasons why you might do code reviews, but which reasons are important to your team and your development process? You can pick multiple reasons - in fact you probably should - but be aware that the goals you have for your review process (including how many goals you have) will affect how you do your reviews, and how much time you need to spend on them.
2. Write down a list of things that you need to consider when doing a code review that targets those purposes. For security goals, you might look for the OWASP top 10 (ideally you'll look beyond that, but the top 10 is a good place to start). To check against coding style, you need to have a defined coding style. If you're looking for bugs, what are the common types of bugs that slip through your code and unit test process. You'll want to build this list up over time. You can simply start with a blank list, and every time you do a code review aim to commit to adding something to that list (until it gets built up, you don't really want to have a never-ending list). But starting from nothing every time you do a code review is inefficient and ineffective. You will be quicker and find more problems if you build up a code review guide.

Even if the rest of your team isn't on board with this, if you are ever asked to code reviews, then you can start getting better at them.

2. Threat Modelling

A lot has been written about threat modelling. In particular it has had particular focus at Microsoft in recent years, and they have published a lot of material on their approach using STRIDE and DREAD. My intention here is not to try and explain what is already covered elsewhere. I'm going to explain why I think threat modelling belongs on this list of 3 things to start doing.

From what I see, it seems that most development teams have no experience in threat modelling. That's not particularly surprising, but it's not particularly comforting either. We're designing and building systems without having any structured way to think about what security threats we need those systems to respond to, and what counter-measures and safeguards we need to build to deal with those threats. We're not doing it entirely blind - most team members know something about the threats that are out there, but it's a long way from being a reliable and repeatable process.

Starting down the path of threat modelling is a step towards having system designs that are intentional about they way they have built their security model, and about security measures are incorporated into the relevant aspects of the design. Any step that you take down that path will pay-off in the robustness of your security designs (both at the macro and micro level)

Following a regular, documented threat modelling approach is helpful, but even if you can't do that, following some sort of systematic approach, some of the time, will help to develop your thinking about security threats so that you can make more thoughtful decisions all of the time.

Microsoft's STRIDE/DREAD approach is good, but it's complex enough that it take some effort to get your head around it, and if you're looking for something to start doing now, then it's probably not the right fit.

I recommend starting with Attack Trees. In my experience they're simple enough to get comfortable with quite quickly, and their visual nature is easy to grasp. There's value in working through it as a team, but it's also something that you can do on your own to improve your own secure development practices.

3. Vulnerability Assessments

This one typically requires some budget, so it's not one that an individual developer can introduce on their own, but if you're a manager of a development team, and you want to build a stronger security focus in your team, this one's for you.

At the risk of sounding like a shill for the testing companies, I firmly believe that every development team that places value in their web application should be having a vulnerability scan done on it, ideally by someone outside your team.

It's not just that these scans find problems (although they do), it's also that the discipline of subjecting your application to external review creates a cultural change inside your development team.

With very few exceptions, if you're reluctant to bring someone in to do a scan of your (internet facing) applications then one of the following is probably true:

1. You don't value your application or your reputation
2. You are worried about what you'll find out
3. You've only experience low quality testing vulnerability scanners.

If you don't value your application, then that's fine, but I'd have to question why it even exists, but most companies care about their reputation. A significant vulnerability that exposes your customers' private details, or even simply opens you up to a cross-site scripting attack, will have a reputational impact. The number of cases where an application is worth having on the internet, but not worth having scanned must be extraordinarily small.

If you're worried about getting a difficult result, then you need to get over it. If the application has issues then you need to know about it. A vulnerability gives you information about your application, important information that you need to know. If you're not ready to hear that news, then it's time to suck it up, and take it on the chin.

If you've had a bad experience with a previous vulnerability assessment company, then I can sympathise. While there's a lot of good companies out there, there's some that should be avoided. A good assessment company should:

• Take the time to understand what you're trying to achieve with the assessment process
• Scan for a broad range of potential vulnerabilities (not just the OWASP Top 10, although you definitely want them to be included)
• Provide a comprehensive report that gives you enough information to replicate the issues they found
• Provide follow-up advice about what the vulnerabilities mean, and how you can go about rectifying the problems
• Perform additional scans after you've resolved and issues found.

If you're in Australia, and you're having trouble finding a reliable company, then let get in touch and I'll recommend some.

So those are 3 possible changes you can make in your development team to start to improve your capability with respect to security. I believe they will start to delver benefits almost immediately, if for no other reason than they start to bring a focus on security, and they introduce some structure about it.

If you work in a development team, and you care about security, then pick one, and start to take some steps to being part of a more secure development team.

Shameless plug

The 6 Security Essentials is a training course that I run with Dragonfly Technologies where we cover these topics and a lot more. If you're on the east coast of Australia, and you're looking to build your capabilities in this area, then contact us and we can talk about how we can help.