Why everyone in infosec should do SABSA training

Last week I did my SABSA training and certification. I don't know how I went but I wanted to share the results of what I learned.

This post is long and I make no apologies for it. I wish someone had a post like this before I started on the training. I didn't have anyone I could turn to or who could really tell me what it was about until I had done it (which was frustrating). I mean I asked around but I didn't get an answer that really satisfied me. So I wanted to give the best writeup that I could to help explain to any other likeminded folk in the field or least give my thoughts on what I walked away with. So here it is.

For the uninitiated, SABSA stands for 'Sherwood Applied Business Security Architecture' and it is a method for applying an understanding of the business you are securing. By understanding the business, you are able to build in security that is appropriate to the context of that organisation.

My career journey has taken some very bizarre turns. When I took up my last role, I wanted to move into focused pentesting (from a role where I did some pentesting) and instead wound up doing a combination of stuff - security management, security consultant and solution design and architecture. I got to oversee a bunch of pentesters, hire pentesters and be fairly involved but it became a gradual divorce away from the hands on (which I still miss sometimes but other times I don't). But more to the point, I enjoyed what I was doing, although I think it took me a time to really appreciate it because it wasn't what I signed up for.

Anyway as I came from more of a sysadmin/pentester background, I would look at project designs and how to break them (typical 'break' vs 'build' mentality). Reviewing security controls because a question of trying to be as thorough as I could, and an exercise in mentally threat modelling various ways to break the solution design.

I would look at different methodologies for security testing, I would think of solutions in terms of the OSI model and what security services were required (authentication, authorisation, auditing, etc). I looked at OWASP to ensure a stringent design process was followed. We used contractual arrangements to enforce our needs where we could.  I'd spend time talking to the business and trying to spend more time listening than talking. I wanted to find out what their problem was and if I could address it. I also tried to keep up with all the tech (which is impossible once you get to this point doing this work as something has to give).

But the whole thing seemed and felt really adhoc. It was a case of finding what I could think of, springboarding ideas with my team mates and consistently asking myself "is this enough?".

I couldn't put a label on what I did exactly - but whatever it was - I was never aware of a methodology to help people like me doing the work I was doing. I became aware of architecture as a discipline owing to some good solution architects who heavily influenced my thinking and became aware of Enterprise Architecture as a discipline and how good solution design can help drive strategy. However that seemed great as an IT Architecture, or a Business Architecture, but nothing to help me in my discipline. I learned relatively quickly that pentesting was simply a way of measuring security effectiveness but in and by itself, didn't offer me anything beyond some assurance. It was around then I started to drift away a bit from pentesting.

I became aware of SABSA in 2008 through a co-worker. We'd both found the SABSA book by David Lynas, John Sherwood and Andy Clarke but neither of us really did anything with it. I think at a glance we had the same impression as everyone else. It looked great as a method but seriously, how practical was this light and fluffy stuff. We both came from similar backgrounds and I think had very similar thoughts on applying architecture - this all looked really high level theory and not very practical.We were still interested in the book and how it applied but we never got around to reading the book or doing the course.

Well, I finally started on that book earlier this year and got through most of it (3/4 I think). The course is an equally tough slog too. I consider myself pretty passionate on this topic btw, but after day 4 even the most passionate person will be tested I reckon!

As I went through the training I had an epiphany of sorts (actually I spent a good chunk of the weekend at Ruxcon ruminating about it too). Having read the book and seen some videos on architecture, I had some idea of how Architecture, as an IT discipline worked. But this course really highlighted for me why SABSA is THE single most important training I have had in my field to date. I wanted to share what I learned and highlight why I think other infosec professionals - regardless of their role, should do it.

What I learned:
I learned that the often disparate array of compliance standards, ISO standards, architecture frameworks and so on need not be. They can all integrate together. Once you understand the business you can begin to build that picture. The architecture frameworks (TOGAF, SABSA, Zachman, etc) are simply a "method of organised thinking". SABSA is the concrete which enables me to put together all the other building blocks together.

Every thing I know, have learned and will learn (not just security related) I can apply using this framework to build a security model for my clients based on re-usable architecture. The "architecture" however, is never complete. It is a living breathing organism. Each project or each pass is an attempt to iteratively build up your understanding of the business. Each project is an opportunity to build upon those building blocks - re-use what you can or tailor to suit where appropriate. You never have a perfect "target". It just keeps moving. We've often known that security is a journey, not a destination - but seeing this through the eyes of an architecture framework is a very different thing. I think its like trying to describe being a parent to someone who doesn't have kids. There's the difference between knowing the path and walking the path, as Morpheus would say. :)

From a technical viewpoint, I learned how to structure controls so that controls at the various OSI layers are not done in isolation from each other. That you can build concrete controls. You can even forgo certain controls but it is not without an understanding of the potential consequences or the risk.  I also learned to truly build re-usable, extensible security services. Moreover, how they link back to business goals and objectives which enables demonstrable return on investment and develop a realistic form of risk assessment (pretty much the best system for risk assessment I have seen to date).

Incase people reading this think this is all high level fluff, the guys who developed this were the architects for Swiftnet (the system banks use to transfer funds internationally). Anyone who has heard of this or worked with banks will understand the importance of the system and the risks involved. As you go through the training, David Lynas (who is the main instructor globally - if not the only one I am aware of) will make clear his points through illustrated examples throughout his career and using examples from other people's careers. As someone who had done this sort of work before, I found these some of the most educational points of the training as I could relate it back to various situations of my own and either pat myself on the back for getting something right or mentally kick myself for thinking how I should have handled something differently.

I realise this is going on and on - but I really want to stress why I think this is worthwhile. I try to provide some context here based on a person's title/role or aspirantions here:

Security Managers/CISOs/CSOs
The SABSA framework integrates with just about every relevant standard or framework you can think of (ITIL, COBIT, ISO27000 series, etc) and a way for running security programs. It provides a method for delivering business driven security services with mesaurable results and a PRACTICAL form of risk assessment (the most practical I have seen). The risk management framework and how to measure security, will be worth the price of entry alone for you. 

Security Designers/Architects
I think you'll  come away with a similar view to myself and see how this all ties everything in together. Management, penetration testing, security standards, compliance, risk, technical controls and how to integrate them all - in a practical method. You will enjoy the focus of building and creating at a truly enterprise level and your game will be taken to another level.

Penetration Testers/Security Analysts
Pentesters are a funny lot with their training budgets.  Either they want to do Offensive Security course or for the more advanced ones, a top notch Immunity course by Dave Aitel - or they are usually happy to spend their own time with a few books and play around with stuff on their own. Now if you fall into the later category, you should definitely put it towards SABSA.

I mean lets face it - you're not going to put the budget towards anything else, why not learn how to review solution designs using a comprehensive strategy which will enable you to cover all the components? Why not learn how to link it back up to core business objectives? Truth is that will not take away from your technical skills - why not learn how to engage with the business at a higher level.

The short answer is if you haven't done the SABSA training, just get out there and do it. It will not takeaway from anything you have done to date. I can assure you it will only complement anything you do, regardless of what it is. And finally, I think it will really open your eyes in ways you hadn't considered previously. It won't solve world hunger and the "security problem" for good, but I will say that it is a damned good start. If more people had done this training in our field, I can honestly say that the world would be a safer place.

I hope this is useful.

Cheers,

- J.