Enterprise Architects don't exist in every organisation. You'll typically only find them within enterprise scale environments. Even then, not every enterprise has one. Kinda sad but in an ideal world, an EA or an EA team are basically the true interface between the business and IT. I am a big believer that EA is a true enabler of good IT practise but more than that, good business practise too. I believe that security architects, security analysts, security managers, should all be working with their EAs in their business.
I will attempt to explain why - but firstly I will state this article makes a lot of assumptions. So most of this is based on theoretical best practise EA. Bad EAs or bad enterprise environments can easily screw this up but then again, same applies for security too.
Without further ado:
1) EAs have access to the C-level executives
Typically they deal with the CIO (at least they should be). This means they understand what is happening at that level. If they have the CIO's ear then they know what their concerns are, what their future goals are or possibly future direction. All useful intel to any security professional.
2) EAs understand the business
One of the earliest activities an EA does is deconstruct the business down to a series of key business processes. They also map out what infrastructure, applications and environments these processes use. This is critical information to any security professional looking to deconstruct the business and map out the security architecture. It can also be useful for determining high risk business processes, disaster recovery, business continuity planning, etc. The value of these artefacts cannot be overstated.
3) EAs have oversight of a lot (if not all projects)
A lot of the time, they are members of an Architecture Review Board - which can often mean they have access to any project going through a Project Management Office. Alternatively because of their acess to the C-level, they might be privy to rumors on the horizon for projects with rather scary security implications (e.g. transformation projects, outsourcing projects, etc). If you can, Security should have representation on such a board. Even at an informal level, they might just let you know what changes or projects are on the horizon - and why you should be concerned.
4) EAs recognise the value of security
Most EAs recognise that security is simply another architecture domain that requires specialist skills and knowledge. They should be engaging you and likewise you should be engaging them. A security architect that is a member of a EA team is able to see the business at a higher level, see the same things the EA team does and better able to align security with business need.
5) EAs can champion security
Closely related to point four, even if security is not adequately represented within an EA team your input can influence their decisions. You might be able to sit on an Architecture Review Board. They might be able to raise your concerns to the CIO. They might be able to incorporate your requirements and feedback into their designs.
6) EAs set (or at least influence) the technical direction
As EAs review the technical landscape within the business, they will often seek to consolidate around a series of applications, infrastructure components, etc. They will define technology stacks, roadmaps, etc. This can be invaluable to an savvy security analyst looking where to focus training (not just for themselves but other staff in key areas) but also investigate security solutions, guides, documentation, etc - utilising those same technology choices.
-----
In summary, the forward thinking that EAs do every day can be invaluable service and value add to any time strapped, operationally focused security analyst. Even if you are the most strategic minded security architect, you should still be aware of the value Enterprise Architecture brings to the business. And when I say 'business' I mean information security too.
Sunday, June 20, 2010
Monday, June 14, 2010
Presentations for Dummies: 7 Tips for professional speaking
The original intent of this blog was to discuss my lessons learned along the way in my career and share wisdom where I think I have something to offer. It is in this vein I write up this post and I feel it would be remiss for me not to talk about some recent lessons I've learned on public speaking. Now I love to talk (I think anyone with a blog does really) but I put my hand up to do some presenting because:
a) I think I'm terrible at public speaking but I want to get better at it.
b) I think fear or nerves is no reason to not attempt something.
Sure I get a bit nervous, but its the same nerves I used to get before going into a tournament. Jittery. Adrenalin. A bit of excitement. I want to get it on and get it on now (or in this case, over and done with!).
Now, I've done some public speaking stuff before - mostly small forums and groups but this past week saw me do three presentations on the same topic in the same number of days, across different states. So in the spirit of this blog, I had to share what I've learned - the things I did right to the things I did wrong. This post is as much a reminder for myself next time as it is to anyone reading.
1. Drink plenty of water
Now I've done a lot of weight lifting and martial arts training over the years, sometimes 2-3 hours or more of hard training back to back. You'd think I'd be aware of the importance of hydration. Apparently I'd forgotten. :(
Talking for 60min or more gets you dehydrated MIGHTY fast. That one glass of water on the table next to the podium isn't going to cut the mustard. That's there incase you get parched (or need to slow down your talk to buy time). Loading up on the caffeine before hand to wake you up may sound like a great idea to give you some GO power if you're running on vapour, but it is a bad idea if it isn't followed up with at least a two glasses of water for each cup of coffee you consume. If you're presenting during a breakfast slot, start your day with a litre of water before you hit the caffeine. Then follow it up with water. That way you can still have your go juice without stalling.
2. Consider The Logistics
One of the places I presented in was a very, very narrow hall. I was positioned at a podium that had about two feet of clearance from the projector screen and I barely had the room to stand in the one spot - certainly not enough to pace around (I would have had to cut infront or behind the screen). To make matters worse, I was stuck directly under a heating duct where the temperature rose by 10 degrees relative to the rest of the room (I imagine being under a headlight would have a similar impact).
I had never even considered this aspect while presenting. My prior prep focused on timings, content, rehearsals, dry runs, etc. Not this. As a result of this (and #1), I choked during one of these presentation at least two, perhaps on three occasions. Not due to nerves but I couldn't think! I was dehydrated, hot and my tongue getting tied. This had never happened to me before. I wasn't prepared for it. I got through my content but the feedback afterwards reflected the performance (although the content seemed to be valuable to everyone).
So, the takeaway lessons there - get to your presentation venue early. Assess your speaking area. Ensure you do not have an uncomfortable presentation area, that you have room to walk around, that you have a clicker for moving through slides as well. Don't be afraid to change the environment to better suit you (as much as you can). If you can, provide feedback to the organisers afterwards what you didn't like about the presentation environment.
3. Preparation
This is something I think I do well (and according to some, I overbake). But of course it is pretty bloody obvious to anyone that you need to prepare. But I don't think there is such a thing as overbaking when it comes to presenting. Know your content - inside and out so you can then justify sweeping statements or otherwise be clear on the exceptions. Be familiar with your timing and delivery of your content.
This time round was the longest presentation I have ever done. Due to specific circumstances relating to my content, I had to produce additional content that wound up with me effectively doubling the number of slides. After cutting this down by 25%, I still had a LOT of content to hammer through. Being thorough with my timing was all that kept it on track.
Takeaway lesson - know the content, rehearse it, rehearse it, rehearse it. On your own or with others. If you don't like it, change it.
4. Content & Flow
For this presentation I produced the content originally for a technical audience. I then had to re-engineer it for a business audience as well and then try to find a middle ground between the two. This is not a good way to prepare a presentation.
As a result of this activity, I had too much content. I also felt it missed the mark for both audiences (but again the feedback here was positive so I have to take that onboard). But during the initial prep, it got to a point I had so much content I had to ask myself "what the hell am I trying to say??".
I literally went back to the drawing board. I put up on a whiteboard all my key points and how I would like to structure them. I then moved slides around, moving some content to my presenter notes and then with despair in my heart, gutting slides that weren't consistent with the messages I was trying to convey. Even then, the final product was much clunkier than other presentations I've done in the past. I didn't like the flow and again, this was reflected in some of the feedback.
To be fair , I would never deliver a presentation in this manner normally. Typically I would START with the message I am trying to convey, distill that message down into several key pointers and build a presentation around those pointers. Next time I will stay true to this and start from scratch.
Key lesson here - start with the message first, less slides doesn't mean you have less to talk about.
5. Pacing
Closely related to the last two point, I feel I learned a lot on the importance of pacing. My original presentation was around 114 slides with approximately 70min speaking time. That works out to 1 slide every 45 seconds. That works great when some slides are intended to be rapidly flicked through - but what about those slides that aren't?
This is where presenter view becomes critical for note taking, marking in your timings as a reminder as well as dry runs to ensure you're familiarity with the delivery of the content AND the timings.
In the end I got it to a sum total of 80 slides, only 77 of which I had to present. This, with my 'skim through' slides, worked out to roughly 1 minute of talking per slide, which flowed much, much better. I still had too much content in retrospect, but hey, at least the flow was greatly improved.
If you are building your presentations from scratch for one intended purpose and do not have to retrofit it as I did, I suspect you won't have the same problems I did.
Lesson - do your rehearsals. They help identify pacing issues. Also, mind your talking speed. Don't talk too fast!
6. If You're Travelling, Check-In Where You Are Presenting
On the advice of my manager, I actually wound up checking myself in at the various hotels where I was due to present. This was a brilliant idea and I was so grateful for doing this. I flew to my destinations during the day, arriving at my hotel around dinner time, leaving me plenty of time to eat, rest up and rehearse.
This meant the next morning I didn't have to wake up extra early, book a cab and race to where I was going to present and dodge traffic. I wound up having breakfast with my co-presenter and we had ample time to not just discuss the approach but relax.
If travelling, always stay where you are presenting (if you can).
7. Be Prepared
If you're travelling, fly a day in advance and give yourself time to adjust to any new timezones. Bring business cards. Anticipate the sorts of questions you're going to be asked. Bring your customers. Be able to cite your references (audiences LOVE supplementary reading material). Ensure your content is made available online afterwards (e.g. PDF on a website). Bring your own clicker.
I did all this except the last one. Well, I brought one with me but I didn't test it before hand, it was busted and I couldn't get it to work (fail). I've decided now that they are worth their weight in gold. I will always have one from now on.
--
Anyway, I hope this helps you all as much as it has helped me. If anyone has any tips of their own, throw them up here. Next time I'll refer back to this post just to remind myself.
- J.
a) I think I'm terrible at public speaking but I want to get better at it.
b) I think fear or nerves is no reason to not attempt something.
Sure I get a bit nervous, but its the same nerves I used to get before going into a tournament. Jittery. Adrenalin. A bit of excitement. I want to get it on and get it on now (or in this case, over and done with!).
Now, I've done some public speaking stuff before - mostly small forums and groups but this past week saw me do three presentations on the same topic in the same number of days, across different states. So in the spirit of this blog, I had to share what I've learned - the things I did right to the things I did wrong. This post is as much a reminder for myself next time as it is to anyone reading.
1. Drink plenty of water
Now I've done a lot of weight lifting and martial arts training over the years, sometimes 2-3 hours or more of hard training back to back. You'd think I'd be aware of the importance of hydration. Apparently I'd forgotten. :(
Talking for 60min or more gets you dehydrated MIGHTY fast. That one glass of water on the table next to the podium isn't going to cut the mustard. That's there incase you get parched (or need to slow down your talk to buy time). Loading up on the caffeine before hand to wake you up may sound like a great idea to give you some GO power if you're running on vapour, but it is a bad idea if it isn't followed up with at least a two glasses of water for each cup of coffee you consume. If you're presenting during a breakfast slot, start your day with a litre of water before you hit the caffeine. Then follow it up with water. That way you can still have your go juice without stalling.
2. Consider The Logistics
One of the places I presented in was a very, very narrow hall. I was positioned at a podium that had about two feet of clearance from the projector screen and I barely had the room to stand in the one spot - certainly not enough to pace around (I would have had to cut infront or behind the screen). To make matters worse, I was stuck directly under a heating duct where the temperature rose by 10 degrees relative to the rest of the room (I imagine being under a headlight would have a similar impact).
I had never even considered this aspect while presenting. My prior prep focused on timings, content, rehearsals, dry runs, etc. Not this. As a result of this (and #1), I choked during one of these presentation at least two, perhaps on three occasions. Not due to nerves but I couldn't think! I was dehydrated, hot and my tongue getting tied. This had never happened to me before. I wasn't prepared for it. I got through my content but the feedback afterwards reflected the performance (although the content seemed to be valuable to everyone).
So, the takeaway lessons there - get to your presentation venue early. Assess your speaking area. Ensure you do not have an uncomfortable presentation area, that you have room to walk around, that you have a clicker for moving through slides as well. Don't be afraid to change the environment to better suit you (as much as you can). If you can, provide feedback to the organisers afterwards what you didn't like about the presentation environment.
3. Preparation
This is something I think I do well (and according to some, I overbake). But of course it is pretty bloody obvious to anyone that you need to prepare. But I don't think there is such a thing as overbaking when it comes to presenting. Know your content - inside and out so you can then justify sweeping statements or otherwise be clear on the exceptions. Be familiar with your timing and delivery of your content.
This time round was the longest presentation I have ever done. Due to specific circumstances relating to my content, I had to produce additional content that wound up with me effectively doubling the number of slides. After cutting this down by 25%, I still had a LOT of content to hammer through. Being thorough with my timing was all that kept it on track.
Takeaway lesson - know the content, rehearse it, rehearse it, rehearse it. On your own or with others. If you don't like it, change it.
4. Content & Flow
For this presentation I produced the content originally for a technical audience. I then had to re-engineer it for a business audience as well and then try to find a middle ground between the two. This is not a good way to prepare a presentation.
As a result of this activity, I had too much content. I also felt it missed the mark for both audiences (but again the feedback here was positive so I have to take that onboard). But during the initial prep, it got to a point I had so much content I had to ask myself "what the hell am I trying to say??".
I literally went back to the drawing board. I put up on a whiteboard all my key points and how I would like to structure them. I then moved slides around, moving some content to my presenter notes and then with despair in my heart, gutting slides that weren't consistent with the messages I was trying to convey. Even then, the final product was much clunkier than other presentations I've done in the past. I didn't like the flow and again, this was reflected in some of the feedback.
To be fair , I would never deliver a presentation in this manner normally. Typically I would START with the message I am trying to convey, distill that message down into several key pointers and build a presentation around those pointers. Next time I will stay true to this and start from scratch.
Key lesson here - start with the message first, less slides doesn't mean you have less to talk about.
5. Pacing
Closely related to the last two point, I feel I learned a lot on the importance of pacing. My original presentation was around 114 slides with approximately 70min speaking time. That works out to 1 slide every 45 seconds. That works great when some slides are intended to be rapidly flicked through - but what about those slides that aren't?
This is where presenter view becomes critical for note taking, marking in your timings as a reminder as well as dry runs to ensure you're familiarity with the delivery of the content AND the timings.
In the end I got it to a sum total of 80 slides, only 77 of which I had to present. This, with my 'skim through' slides, worked out to roughly 1 minute of talking per slide, which flowed much, much better. I still had too much content in retrospect, but hey, at least the flow was greatly improved.
If you are building your presentations from scratch for one intended purpose and do not have to retrofit it as I did, I suspect you won't have the same problems I did.
Lesson - do your rehearsals. They help identify pacing issues. Also, mind your talking speed. Don't talk too fast!
6. If You're Travelling, Check-In Where You Are Presenting
On the advice of my manager, I actually wound up checking myself in at the various hotels where I was due to present. This was a brilliant idea and I was so grateful for doing this. I flew to my destinations during the day, arriving at my hotel around dinner time, leaving me plenty of time to eat, rest up and rehearse.
This meant the next morning I didn't have to wake up extra early, book a cab and race to where I was going to present and dodge traffic. I wound up having breakfast with my co-presenter and we had ample time to not just discuss the approach but relax.
If travelling, always stay where you are presenting (if you can).
7. Be Prepared
If you're travelling, fly a day in advance and give yourself time to adjust to any new timezones. Bring business cards. Anticipate the sorts of questions you're going to be asked. Bring your customers. Be able to cite your references (audiences LOVE supplementary reading material). Ensure your content is made available online afterwards (e.g. PDF on a website). Bring your own clicker.
I did all this except the last one. Well, I brought one with me but I didn't test it before hand, it was busted and I couldn't get it to work (fail). I've decided now that they are worth their weight in gold. I will always have one from now on.
--
Anyway, I hope this helps you all as much as it has helped me. If anyone has any tips of their own, throw them up here. Next time I'll refer back to this post just to remind myself.
- J.
Sunday, June 13, 2010
Lamo vs Wikileaks + Manning
The recent emergence of the alleged source of the 'Collateral Murder' video has left a bitter taste in everyones mouth. 22 year old Bradley Manning was an Army Intelligence Analyst with Top Secret clearance has been arrested (and at my last check, held in a Kuwait prison) awaiting a hearing. He has allegedly provided Wikileaks vast volumes of classified data. The most controversial which - has not yet been disclosed - over 260,000 pieces of classified US State Department diplomatic cables. Manning was arrested on the basis of chat evidence provided by one time hacker, full time 'journalist' Adrian Lamo. Lamo, rather than disclose this to the police, feds, military, anonymously if need be - decided to go to Wired.com, his mate Kevin Poulson to get the story out (Wired.com has all the key articles on this topic. This one being the latest). Patrick Grey, producer of the Risky Business podcast also interviewed Lamo and actually did a good job of putting the hard questions to him (so I thought).
I won't say too much but I think Lamo did the right thing but for all the wrong reasons. I hope he's being truthful with himself because he's got a lot on his conscience. If it is true that Manning was behind it, then God grant him mercy because I don't think the U.S. military will give him any.
I think there's a lot of interesting issues that should/could be explored. I won't prattle on but I'd be very keen on hearing views from anyone reading as to what they think.
- J.
EDIT: Now the transcripts are out on Wired, I'm kinda torn. On one hand it seems blatantly obvious Manning was heavily disillusioned based on the crimes of his government. Actions such as the disclosures he allegedly made (it is still alleged isn't it?) are how government imbalances and abuses of power are identified and called to task. All the same, should there be no penalty attatched for people who abuse their access? I mean this is the classic insider threat scenario that all security professionals should be dreading. It isn't a textbook answer here. I guess both parties can only take action as their conscience deems prudent. It just seems unfortunate that Manning is probably going to get roasted alive for following his.
I won't say too much but I think Lamo did the right thing but for all the wrong reasons. I hope he's being truthful with himself because he's got a lot on his conscience. If it is true that Manning was behind it, then God grant him mercy because I don't think the U.S. military will give him any.
I think there's a lot of interesting issues that should/could be explored. I won't prattle on but I'd be very keen on hearing views from anyone reading as to what they think.
- J.
EDIT: Now the transcripts are out on Wired, I'm kinda torn. On one hand it seems blatantly obvious Manning was heavily disillusioned based on the crimes of his government. Actions such as the disclosures he allegedly made (it is still alleged isn't it?) are how government imbalances and abuses of power are identified and called to task. All the same, should there be no penalty attatched for people who abuse their access? I mean this is the classic insider threat scenario that all security professionals should be dreading. It isn't a textbook answer here. I guess both parties can only take action as their conscience deems prudent. It just seems unfortunate that Manning is probably going to get roasted alive for following his.
Thursday, June 10, 2010
Counterpoint: Commoditising Penetration Testing
Recently Drazen Drazic put out an article on his blog at Beast Or Buddha about penetration testing and how it has become heavily commoditised. Or more specifically how businesses and individuals are attempting to do so, when infact they can't.
Drazen points out that there are some things you can commoditise, good penetration testing you can't. While I agree with this 100%, I do disagree with his view on commoditisation. I hope I can present a different viewpoint.
Commoditisation in this sense means that the skills required are becoming something that can be trained. Look at penetration testing back in say 2000. It wasn't that many years earlier the first book 'Maximum Security', the first book to really look at this in any depth was written. Hacking texts were limited to old BBSes, early underground forums, newsgroups, etc. You had to know who to talk to and where to look. More often than not, you were told to go figure out stuff yourself. If you had to ask, you fail. So in its earliest forms, hacking was really a form of exploration, self-discovery and learning (and understanding) technology. It was like this for many years prior to 2000 as well but the point being is that this is the mold that many of the "old school" penetration testers come from.
Fast forward to 2010. We now have course after course after course, certification after certification, book after book. For those of us who have been at this long enough many of these options are regarded as a mixed bag. Some people see these as "dumbing down" the content and presenting the technical tools and methods without any understanding/appreciation for the underlying technology. Others see them as not providing true value to prospective students. Some see them as an entry path into the field, lowering the barrier to entry that has often existed in this field. And there are many compelling arguments for each position.
Where I sit, the commoditisation is good. I'll try and explain why but I'll also explain why commoditisation doesn't actually hurt penetration testing.
1) Unit testing
Many of the tests to perform a specific function are very simple. Lets say you want to test that input validation is working on a single form field. It is relatively simple for anyone to peform this test. Training your application testers on basic web application penetration testing (lets assume developers are doing some form of development training) means then they are able to validate that no cross site scripting is present. While this certainly doesn't obviate the need for penetration testing at the final phase or even multiple phases, what it does do is reduce the likelihood of critical security errors common to applications. It reduces the load on the penetration testers. But most importantly, it means these defects are detected earlier. Now, if you're a security manager overseeing large volumes of application development and testing, wouldn't you want to see your testing teams attempt to validate your security requirements as much as possible prior to obtaining independent penetration testing? I know I do.
2) Trained vs. Skilled
Secondly, good penetration testers is actually hard to come by. It is a very specific skillset that requires someone with a good grasp on just about all technical areas and in some cases, a specialisation or two. Networks, operating systems, applications, databases, programming. All this and more is part of their skillset. They understand how people think, how programmers write code, how administrators handle their environments. They can think like an attacker and more frighteningly, it comes naturally. They can pull apart just about any piece of technology you give them and figure out what makes it tick and love every minute of it. Now do you really think any training course can commoditise that skillset and that mindset? Hell no! That comes with instinct and experience - something no course alone can provide.
3) Nature vs. Nuture
Thirdly, apart from the fact this is a skill you cannot train, it is one that must be nutured. Most in-house security teams won't pay their staff to continually upskill themselves, stay abreast of the latest technology and trends. They really get to go on courses, let alone conferences. Don't even get me started on building test labs or pay for software licensing. Most of these guys might do it on their own time but they won't remain inhouse security when just about any consultancy team will grab these guys, pay them a lot more money to do what they love to do, pay for all their training, toys, etc AND do it all on company time. And given that in-house security teams cannot retain good penetration testers for long, surely it makes sense to go to a consultancy that you rely upon as a trusted partner? That makes perfect sense to me.
4) Methodology Matters
Fourthly, the methodology that a lot of these consultancies use is to make penetration tests a measurable, repeatable process. That's not to say all penetration tests, or the testers, are equal, but the intention is to come up with a proven approach to ensuring that each test will yield a high quality result as possible. In that respect, I actually think this is a good approach. Not just from ensuring the quality of the testing but even from a viewpoint of training up your new staff (who may be very technically proficient btw). Now the methodology is not the "be all and end all" but the fact that it can provide a common framework designed specifically to yielding results based on a proven approach cannot be understated.
5) Knowing The Path vs. Walking The Path
I'm paraphrasing Morpheus here, but this is the final distinction between 'good' and 'great'. A decent penetration tester may be able to follow their methodology and generate consistent results and findings for their client. However, a great pentester is one that is able to look at their methodology, their current findings and say "I know the methodology says this, but I am going to go off the beaten path and explore this...". They are operating on either a hunch (which I covered above), evidence, whatever - there are somethings that simply only experience can yield. And this is the distinction I am trying to make. No course or certification alone is ever going to provide this edge. Ever.
6) Increased Awareness
Raising the profile of penetration testing is good for the profession. It is good because IT shops begin to realise the value of a good pentester. Consultancies develop a clearer picture of what different roles exist - and that a penetration tester becomes a clearly defined role, rather than an implicit skillset that every security professional is assumed to have.
Now I am not saying the issues raised by Drazen aren't that bad - they are. But he did neglect to touch on these points I've raised and I think its remiss to not mention these benefits.
There are always going to be consultancies that try to sell vulnerability assessments as 'cheap penetration tests', or tools like nmap and use open ports as 'critical security defects'. There are going to be people who rely on certification as evidence of a great penetration tester. There are going to be consultancies or individuals that just deliver terrible quality penetration tests and useless reports. C'est la vie.
However, that's why it is up to security professionals to cast a discerning eye over these potential partners. It's up to us to provide that insight and find the value.
In my last role I worked with a few great security professionals and we had to evaluate many consultancies and their penetration testing offering (so it was great, I got to see a stack of our competition in the field now! LOL). Here's some of the tips my teammates and I used to help flush out the good guys:
FIVE WAYS TO FIND A GREAT PENETRATION TESTER:
1. Ask for a copy of a sanitised pentest report.
What are the findings? Do they discuss serious application faults? Are they able to articulate how this vulnerability can lead to a business impact (and I mean a business impact, not a technical impact)? You'd be amazed how rare this ability is. Poor ones often just do a bad job alround of explaining what a technical risk actually means.
2. Ask what conferences they go to or what professional associations they're apart of.
Do they share their information? Do they present? Do they mingle with other security professionals and swap war stories from the trenches? Some pentesters keep this information very close to their chest and don't like sharing. While this doesn't make them any less technically capable, I question the wisdom behind this approach. I believe security professionals should be able to educate the wider community as well as our own.
3. Ask what research are they doing.
What projects are they working on. Are their tools they are developing? Are they doing vulnerability research? Perhaps its a presentation they are working on? Research represents an interest in their field over and beyond what a cert monkey is capable of. Additionally, some security consultants that perform pentests are often people who are heavily utilised on other projects, in which case penetration testing might be just one of many service offerings. This means at best, they might be good but they definitely won't fall in the "great" category.
4. Ask about their methodology
What does it align with? What doesn't it? If it doesn't align - ask why? Sometimes a company will borrow heavily from a standard but choose to modify it or disregard it based on their own experience. Some of them will actually have their own and it will borrow heavily from several standards. Any group that is consistently refining their metholody and can cite their influences gets big brownie points in my book.
5. Ask what their speciality is?
This is a trick question really. Don't trust anyone who says EVERYTHING. A consultancy may have capability in all areas but either their collective skills will fall into a particular arena, or their individual testers will have unique specialisations. So ask the testers themselves and listen to what they say.
- J.
Drazen points out that there are some things you can commoditise, good penetration testing you can't. While I agree with this 100%, I do disagree with his view on commoditisation. I hope I can present a different viewpoint.
Commoditisation in this sense means that the skills required are becoming something that can be trained. Look at penetration testing back in say 2000. It wasn't that many years earlier the first book 'Maximum Security', the first book to really look at this in any depth was written. Hacking texts were limited to old BBSes, early underground forums, newsgroups, etc. You had to know who to talk to and where to look. More often than not, you were told to go figure out stuff yourself. If you had to ask, you fail. So in its earliest forms, hacking was really a form of exploration, self-discovery and learning (and understanding) technology. It was like this for many years prior to 2000 as well but the point being is that this is the mold that many of the "old school" penetration testers come from.
Fast forward to 2010. We now have course after course after course, certification after certification, book after book. For those of us who have been at this long enough many of these options are regarded as a mixed bag. Some people see these as "dumbing down" the content and presenting the technical tools and methods without any understanding/appreciation for the underlying technology. Others see them as not providing true value to prospective students. Some see them as an entry path into the field, lowering the barrier to entry that has often existed in this field. And there are many compelling arguments for each position.
Where I sit, the commoditisation is good. I'll try and explain why but I'll also explain why commoditisation doesn't actually hurt penetration testing.
1) Unit testing
Many of the tests to perform a specific function are very simple. Lets say you want to test that input validation is working on a single form field. It is relatively simple for anyone to peform this test. Training your application testers on basic web application penetration testing (lets assume developers are doing some form of development training) means then they are able to validate that no cross site scripting is present. While this certainly doesn't obviate the need for penetration testing at the final phase or even multiple phases, what it does do is reduce the likelihood of critical security errors common to applications. It reduces the load on the penetration testers. But most importantly, it means these defects are detected earlier. Now, if you're a security manager overseeing large volumes of application development and testing, wouldn't you want to see your testing teams attempt to validate your security requirements as much as possible prior to obtaining independent penetration testing? I know I do.
2) Trained vs. Skilled
Secondly, good penetration testers is actually hard to come by. It is a very specific skillset that requires someone with a good grasp on just about all technical areas and in some cases, a specialisation or two. Networks, operating systems, applications, databases, programming. All this and more is part of their skillset. They understand how people think, how programmers write code, how administrators handle their environments. They can think like an attacker and more frighteningly, it comes naturally. They can pull apart just about any piece of technology you give them and figure out what makes it tick and love every minute of it. Now do you really think any training course can commoditise that skillset and that mindset? Hell no! That comes with instinct and experience - something no course alone can provide.
3) Nature vs. Nuture
Thirdly, apart from the fact this is a skill you cannot train, it is one that must be nutured. Most in-house security teams won't pay their staff to continually upskill themselves, stay abreast of the latest technology and trends. They really get to go on courses, let alone conferences. Don't even get me started on building test labs or pay for software licensing. Most of these guys might do it on their own time but they won't remain inhouse security when just about any consultancy team will grab these guys, pay them a lot more money to do what they love to do, pay for all their training, toys, etc AND do it all on company time. And given that in-house security teams cannot retain good penetration testers for long, surely it makes sense to go to a consultancy that you rely upon as a trusted partner? That makes perfect sense to me.
4) Methodology Matters
Fourthly, the methodology that a lot of these consultancies use is to make penetration tests a measurable, repeatable process. That's not to say all penetration tests, or the testers, are equal, but the intention is to come up with a proven approach to ensuring that each test will yield a high quality result as possible. In that respect, I actually think this is a good approach. Not just from ensuring the quality of the testing but even from a viewpoint of training up your new staff (who may be very technically proficient btw). Now the methodology is not the "be all and end all" but the fact that it can provide a common framework designed specifically to yielding results based on a proven approach cannot be understated.
5) Knowing The Path vs. Walking The Path
I'm paraphrasing Morpheus here, but this is the final distinction between 'good' and 'great'. A decent penetration tester may be able to follow their methodology and generate consistent results and findings for their client. However, a great pentester is one that is able to look at their methodology, their current findings and say "I know the methodology says this, but I am going to go off the beaten path and explore this...". They are operating on either a hunch (which I covered above), evidence, whatever - there are somethings that simply only experience can yield. And this is the distinction I am trying to make. No course or certification alone is ever going to provide this edge. Ever.
6) Increased Awareness
Raising the profile of penetration testing is good for the profession. It is good because IT shops begin to realise the value of a good pentester. Consultancies develop a clearer picture of what different roles exist - and that a penetration tester becomes a clearly defined role, rather than an implicit skillset that every security professional is assumed to have.
Now I am not saying the issues raised by Drazen aren't that bad - they are. But he did neglect to touch on these points I've raised and I think its remiss to not mention these benefits.
There are always going to be consultancies that try to sell vulnerability assessments as 'cheap penetration tests', or tools like nmap and use open ports as 'critical security defects'. There are going to be people who rely on certification as evidence of a great penetration tester. There are going to be consultancies or individuals that just deliver terrible quality penetration tests and useless reports. C'est la vie.
However, that's why it is up to security professionals to cast a discerning eye over these potential partners. It's up to us to provide that insight and find the value.
In my last role I worked with a few great security professionals and we had to evaluate many consultancies and their penetration testing offering (so it was great, I got to see a stack of our competition in the field now! LOL). Here's some of the tips my teammates and I used to help flush out the good guys:
FIVE WAYS TO FIND A GREAT PENETRATION TESTER:
1. Ask for a copy of a sanitised pentest report.
What are the findings? Do they discuss serious application faults? Are they able to articulate how this vulnerability can lead to a business impact (and I mean a business impact, not a technical impact)? You'd be amazed how rare this ability is. Poor ones often just do a bad job alround of explaining what a technical risk actually means.
2. Ask what conferences they go to or what professional associations they're apart of.
Do they share their information? Do they present? Do they mingle with other security professionals and swap war stories from the trenches? Some pentesters keep this information very close to their chest and don't like sharing. While this doesn't make them any less technically capable, I question the wisdom behind this approach. I believe security professionals should be able to educate the wider community as well as our own.
3. Ask what research are they doing.
What projects are they working on. Are their tools they are developing? Are they doing vulnerability research? Perhaps its a presentation they are working on? Research represents an interest in their field over and beyond what a cert monkey is capable of. Additionally, some security consultants that perform pentests are often people who are heavily utilised on other projects, in which case penetration testing might be just one of many service offerings. This means at best, they might be good but they definitely won't fall in the "great" category.
4. Ask about their methodology
What does it align with? What doesn't it? If it doesn't align - ask why? Sometimes a company will borrow heavily from a standard but choose to modify it or disregard it based on their own experience. Some of them will actually have their own and it will borrow heavily from several standards. Any group that is consistently refining their metholody and can cite their influences gets big brownie points in my book.
5. Ask what their speciality is?
This is a trick question really. Don't trust anyone who says EVERYTHING. A consultancy may have capability in all areas but either their collective skills will fall into a particular arena, or their individual testers will have unique specialisations. So ask the testers themselves and listen to what they say.
- J.
Thursday, June 3, 2010
Microsoft Talks Back To Google's Security Claims
Recently Google have indicated they are abandoning Microsoft for desktop usage, as a result of the Aurora incident earlier this year. Microsoft look like they have something to say about this. I find myself siding with Microsoft on this. What Google are really doing is taking a knee jerk reaction to the incident and instead saying we will change operating systems thinking this will make us more secure. This is a cut and dry example of "security through obscurity" which we know DOES NOT WORK.
Frankly I am disappointed at the news. You'd think with all those PhDs that someone would point out the insanity of this move? Yes, Microsoft is more targeted but it has been 8 years since they begun down the path of Trustworthy Computing. They respond to vulnerability fixes, they have set the standard on secure application development, they supply hardening and configuration guides to everyone, etc. There are better, more sophisticated memory protections for Windows 7 than OS X. Vulnerability trends already prove that the applications are now being targeted - e.g. Adobe Acrobat, Flash and Sun (oops... Oracle) Java. So even if somehow you aren't being hit with specific malware based attacks, there are enough issues with browsers that between Javascript and Flash, that you really don't even need to touch the operating system to do enough damage.
I am hardly a Microsoft fanboy, but there are clear industry lessons everyone can learn from them. Adobe, Oracle and Google - I'm looking directly at you.
If Google are serious, why don't they force a migration to Windows 7, have a hardened build with whitelisted apps out of the box or look at completely segregated (if not offline) dev/test environments? There are plenty of companies that do this already.
If Google think moving to Linux or Macs is going to save them or reduce the attacks against them, then as Schneier would say, they simply do not get it.
Knee jerk reactions never improve security. Thoughtful, measured, planned responses do.
- J.
Frankly I am disappointed at the news. You'd think with all those PhDs that someone would point out the insanity of this move? Yes, Microsoft is more targeted but it has been 8 years since they begun down the path of Trustworthy Computing. They respond to vulnerability fixes, they have set the standard on secure application development, they supply hardening and configuration guides to everyone, etc. There are better, more sophisticated memory protections for Windows 7 than OS X. Vulnerability trends already prove that the applications are now being targeted - e.g. Adobe Acrobat, Flash and Sun (oops... Oracle) Java. So even if somehow you aren't being hit with specific malware based attacks, there are enough issues with browsers that between Javascript and Flash, that you really don't even need to touch the operating system to do enough damage.
I am hardly a Microsoft fanboy, but there are clear industry lessons everyone can learn from them. Adobe, Oracle and Google - I'm looking directly at you.
If Google are serious, why don't they force a migration to Windows 7, have a hardened build with whitelisted apps out of the box or look at completely segregated (if not offline) dev/test environments? There are plenty of companies that do this already.
If Google think moving to Linux or Macs is going to save them or reduce the attacks against them, then as Schneier would say, they simply do not get it.
Knee jerk reactions never improve security. Thoughtful, measured, planned responses do.
- J.
Subscribe to:
Posts (Atom)