Many of you will know of the White Hat Ball and the White Hat Rally - professionals from the information security world raising money for Childline. I have attended the ball a couple of times, but always in the past I have missed out on the rally so I'm delighted that this year I'm taking part.
This year the theme is Carry On Driving, running from Brighton to Blackpool from the 1st to 3rd of July and I have joined team "8485 80085" the Northern UK Security Group (NUKSG) team.
I will obviously be looking for as much sponsorship as possible, and there are a couple of options open - donations through the Virgin giving site, or sponsorship to get your logo on the car, on our t-shirts etc:
- the donations page
- corporate sponsorship
All donations welcome!
Sunday, May 29, 2011
Monday, May 23, 2011
Moving on from 7 Elements
So - we have come to the end of the wee project we set up last year, and I thought I should pop down some of my lessons learned and my thoughts on my next moves:
For me, the contrast between the global world of Ernst & Young, and our local 7 Elements world has shown that some things are the same at any scale. Interestingly the same people engaged me working as a small company as I would have expected from my previous role leading a team across multiple countries. The key is the people relationship - if someone likes and trusts you they will want to work with you.
I have definitely discovered what I enjoy least and most in day to day infosec work, and confirmed what is most valuable to me - my family first, then my profession. Being able to take my kids to school most days is a wonderful return to sanity.
I really enjoy meeting people who are either committed to security or those who aren't really security literate but want to understand and implement secure code or controls. It's also very rewarding to come into a 'greenfield' environment and make a distinct improvement in their security posture (I know, I used the 'P' word...)
OnStartups - part of the StackExchange family has been an incredibly good source of information. Kind of wish I'd hung out there before we founded 7 Elements!
So, not exactly sure what is happening now. Am looking at two sets of options - couple of really interesting permanent roles are being created at the moment, and a few companies have asked if I can do some consulting work over the next few months. So I guess we'll see. If it's consulting I have my Alsop Consulting company - check out www.alsop.net and if it's full time then I'll let you know:-)
For me, the contrast between the global world of Ernst & Young, and our local 7 Elements world has shown that some things are the same at any scale. Interestingly the same people engaged me working as a small company as I would have expected from my previous role leading a team across multiple countries. The key is the people relationship - if someone likes and trusts you they will want to work with you.
I have definitely discovered what I enjoy least and most in day to day infosec work, and confirmed what is most valuable to me - my family first, then my profession. Being able to take my kids to school most days is a wonderful return to sanity.
I really enjoy meeting people who are either committed to security or those who aren't really security literate but want to understand and implement secure code or controls. It's also very rewarding to come into a 'greenfield' environment and make a distinct improvement in their security posture (I know, I used the 'P' word...)
OnStartups - part of the StackExchange family has been an incredibly good source of information. Kind of wish I'd hung out there before we founded 7 Elements!
So, not exactly sure what is happening now. Am looking at two sets of options - couple of really interesting permanent roles are being created at the moment, and a few companies have asked if I can do some consulting work over the next few months. So I guess we'll see. If it's consulting I have my Alsop Consulting company - check out www.alsop.net and if it's full time then I'll let you know:-)
Penetration Testing? A Taxonomy
Initially while I was at Ernst & Young, then through my 7 Elements time, and with the help of many others from vendors and industry have been putting some thought into how penetration testing is currently sold and delivered and how we can improve the process for customers and suppliers. This is a consolidation of posts from other areas, and ideally should be built into the process along with the Penetration Testing Execution Standard.
One of the key issues that we see is that there are different reasons to go broad, or deep. A wide review could aim to identify a range of areas which should be improved, whereas a targeted attack simulation could give good information on what an attacker could do with an opening in the perimeter, combined with weak access controls for example, but may not find many vulnerabilities.
The second issue is with vendors that sell you a "penetration test" but only deliver a lower level of assessment and this can lead to a false sense of security.
So the problem with the "penetration test" term is that most people associate it with this idea that you'll also get coverage of security issues, rather than a focus on specific weaknesses and how they're exploitable.
At the end of the day, an attacker only needs to find one exploitable vulnerability, so while there are certain situations where allowing security testers free reign to go for the crown jewels may be the best option, due to the prevalence of the perimeterised "hard on the outside, soft on the inside" security model, organisations may find a broader approach provides greater assurance for the same budget.
So there is almost a forked model of testing. Typically you would begin with discovery, scanning for common vulnerabilities, and then assessment of those vulnerabilities. After this, the split could be towards Security Assessment (the broad review to find as many vulnerabilities as possible and assess the risk to the business) or towards Penetration Testing (the attempt to exploit and penetrate the organisation to gain access to a particular target).
There will be occasions where these two forks could join up again, where you want a broad review with added information on the extent to which a real world attacker could penetrate.
In order to make it easier to discuss the various stages, our taxonomy is as follows. Please leave comments if you feel improvements are required, and we will develop the taxonomy accordingly:
Discovery
The purpose of this stage is to identify systems within scope and the services in use. It is not intended to discover vulnerabilities, but version detection may highlight deprecated versions of software / firmware and thus indicate potential vulnerabilities.
Vulnerability Scan
Following the discovery stage this looks for known security issues by using automated tools to match conditions with known vulnerabilities. The reported risk level is set automatically by the tool with no manual verification or interpretation by the test vendor. This can be supplemented with credential based scanning that looks to remove some common false positives by using supplied credentials to authenticate with a service (such as local windows accounts).
Vulnerability Assessment
This uses discovery and vulnerability scanning to identify security vulnerabilities and places the findings into the context of the environment under test. An example would be removing common false positives from the report and deciding risk levels that should be applied to each report finding to improve business understanding and context.
Security Assessment
Builds upon Vulnerability Assessment by adding manual verification to confirm exposure, but does not include the exploitation of vulnerabilities to gain further access. Verification could be in the form of authorised access to a system to confirm system settings and involve examining logs, system responses, error messages, codes, etc. A Security Assessment is looking to gain a broad coverage of the systems under test but not the depth of exposure that a specific vulnerability could lead to.
Penetration Test
Penetration testing simulates an attack by a malicious party. Building on the previous stages and involves exploitation of found vulnerabilities to gain further access. Using this approach will result in an understanding of the ability of an attacker to gain access to confidential information, affect data integrity or availability of a service and the respective impact. Each test is approached using a consistent and complete methodology in a way that allows the tester to use their problem solving abilities, the output from a range of tools and their own knowledge of networking and systems to find vulnerabilities that would/ could not be identified by automated tools. This approach looks at the depth of attack as compared to the Security Assessment approach that looks at the broader coverage.
Security Audit
Driven by an Audit / Risk function to look at a specific control or compliance issue. Characterised by a narrow scope, this type of engagement could make use of any of the earlier approaches discussed (vulnerability assessment, security assessment, penetration test).
Security Review
Verification that industry or internal security standards have been applied to system components or product. This is typically completed through gap analysis and utilises build / code reviews or by reviewing design documents and architecture diagrams. This activity does not utilise any of the earlier approaches (Vulnerability Assessment, Security Assessment, Penetration Test, Security Audit)
One of the key issues that we see is that there are different reasons to go broad, or deep. A wide review could aim to identify a range of areas which should be improved, whereas a targeted attack simulation could give good information on what an attacker could do with an opening in the perimeter, combined with weak access controls for example, but may not find many vulnerabilities.
The second issue is with vendors that sell you a "penetration test" but only deliver a lower level of assessment and this can lead to a false sense of security.
So the problem with the "penetration test" term is that most people associate it with this idea that you'll also get coverage of security issues, rather than a focus on specific weaknesses and how they're exploitable.
At the end of the day, an attacker only needs to find one exploitable vulnerability, so while there are certain situations where allowing security testers free reign to go for the crown jewels may be the best option, due to the prevalence of the perimeterised "hard on the outside, soft on the inside" security model, organisations may find a broader approach provides greater assurance for the same budget.
So there is almost a forked model of testing. Typically you would begin with discovery, scanning for common vulnerabilities, and then assessment of those vulnerabilities. After this, the split could be towards Security Assessment (the broad review to find as many vulnerabilities as possible and assess the risk to the business) or towards Penetration Testing (the attempt to exploit and penetrate the organisation to gain access to a particular target).
There will be occasions where these two forks could join up again, where you want a broad review with added information on the extent to which a real world attacker could penetrate.
In order to make it easier to discuss the various stages, our taxonomy is as follows. Please leave comments if you feel improvements are required, and we will develop the taxonomy accordingly:
Discovery
The purpose of this stage is to identify systems within scope and the services in use. It is not intended to discover vulnerabilities, but version detection may highlight deprecated versions of software / firmware and thus indicate potential vulnerabilities.
Vulnerability Scan
Following the discovery stage this looks for known security issues by using automated tools to match conditions with known vulnerabilities. The reported risk level is set automatically by the tool with no manual verification or interpretation by the test vendor. This can be supplemented with credential based scanning that looks to remove some common false positives by using supplied credentials to authenticate with a service (such as local windows accounts).
Vulnerability Assessment
This uses discovery and vulnerability scanning to identify security vulnerabilities and places the findings into the context of the environment under test. An example would be removing common false positives from the report and deciding risk levels that should be applied to each report finding to improve business understanding and context.
Security Assessment
Builds upon Vulnerability Assessment by adding manual verification to confirm exposure, but does not include the exploitation of vulnerabilities to gain further access. Verification could be in the form of authorised access to a system to confirm system settings and involve examining logs, system responses, error messages, codes, etc. A Security Assessment is looking to gain a broad coverage of the systems under test but not the depth of exposure that a specific vulnerability could lead to.
Penetration Test
Penetration testing simulates an attack by a malicious party. Building on the previous stages and involves exploitation of found vulnerabilities to gain further access. Using this approach will result in an understanding of the ability of an attacker to gain access to confidential information, affect data integrity or availability of a service and the respective impact. Each test is approached using a consistent and complete methodology in a way that allows the tester to use their problem solving abilities, the output from a range of tools and their own knowledge of networking and systems to find vulnerabilities that would/ could not be identified by automated tools. This approach looks at the depth of attack as compared to the Security Assessment approach that looks at the broader coverage.
Security Audit
Driven by an Audit / Risk function to look at a specific control or compliance issue. Characterised by a narrow scope, this type of engagement could make use of any of the earlier approaches discussed (vulnerability assessment, security assessment, penetration test).
Security Review
Verification that industry or internal security standards have been applied to system components or product. This is typically completed through gap analysis and utilises build / code reviews or by reviewing design documents and architecture diagrams. This activity does not utilise any of the earlier approaches (Vulnerability Assessment, Security Assessment, Penetration Test, Security Audit)
Subscribe to:
Posts (Atom)