"Historically, organisations have been concerned about the reputational impact of data breaches. This is often a primary motivator for penetration testing," Graeme Bell (below, right), the head of penetration testing in the APJ region for the company, told iTWire during an interview.
With at least one major data breach being reported every week, and the increasing awareness that it could be your business in the firing line next, penetration testing is very much in demand.
Bell, a CREST certified infrastructure tester, is a fan when it comes to Red Team Testing and developing security methodologies to help buusinesses understand the most critical vulnerabilities.
event based in Melbourne.
Bell has a strong technical background, a hacker mentality, and performs specialised penetration testing, as well as consulting on security, architecture and solutions for a wide range of clients including critical infrastructure, government, and finance.
He was interviewed by email.
iTWire: Do companies approach SecureWorks for penetration testing, or is it part of the marketing that is done when a general pitch is made?
Graeme Bell: Penetration testing isn't usually sold as a line item, we're usually approached with specific requirements in mind. Often after considering a client's threat model we tailor penetration testing engagements to focus on areas of concern.
How responsive are companies to the suggestion that a penetration test be done on their networks?
Usually they come to us ready to be tested. It's rarely an adversarial environment, people are happy to learn where their security gaps lie. We don't blame individuals, just demonstrate where there are gaps that can be improved upon, and how these gaps can be addressed. Blaming individuals is of no benefit, the real win is identifying gaps in process to improve an organisation's overall security posture.
How long does an average penetration test take?
This depends on what we're testing, but expect a couple of weeks on average. This can stretch to a couple of months for complex service offerings. For example, in Red Team engagements we are stealthy, build custom trojans, engage our CTU (Counter Threat Unit) to perform comprehensive threat intelligence, and perform other intelligence gathering activities, meaning these engagements can take a couple of months. (A red team is an independent group that challenges an organisation to improve its effectiveness).
Of course, penetration testing is just a "snapshot in time" and tomorrow the security landscape can change. We usually revisit businesses for usual penetration testing annually.
What are the normal tests done?
A lot of the testing that our customers request is network or host infrastructure testing and Web application penetration testing. We also perform a reasonable amount of wireless penetration testing, social engineering services, Red Team testing, and more commodity services like vulnerability assessment.
However, it really depends upon where the customer is in their security journey, we find more and more that organisations are talking to us about advanced and Red Team testing style engagements, as they increase their security-maturity. Organisations are thinking longer and harder about how to test their security posture, and provide further assurance that they are going in the right direction.
Do clients often ask for specific tests to be carried out?
More and more we are seeing a rise in requests for social engineering services. For example, we create bespoke phishing campaigns to demonstrate what a targeted attack would look like, and to test security awareness training effectiveness. Our customers are also becoming more aware of social engineering attacks against service desks and other personnel as part of a targeted attack against their organisations.
We offer an intermediary service, called a Tailored Targeted Attack, which models a semi-targeted attack against an organisation, sort of a "mini-Red Team" that is growing in popularity as this awareness rises. For these more complex and involved engagements, we also utilise threat intelligence information from our resident CTU analysts, to bring real-world intelligence and threat actor behaviour to bear on the attack scenarios that we develop. We work closely with our CTU in these engagements.
On an average, looking at an SMB, how much would such a test cost?
In the SMB space, we normally see organisations start their spending at the $20,000 mark. Of course, this figure varies based on the services performed and the amount of time required. There are cheaper options for commodity testing in the market, SecureWorks is focused on delivering value in the reporting and remediation advice so that clients can develop a roadmap to a more mature security posture.
Is there a great deal of awareness of the need to find holes within in order to guard against a data breach?
Historically, organisations have been concerned about the reputational impact of data breaches. This is often a primary motivator for penetration testing.
Have you noticed any kind of uptick in the number of penetration tests that are requested by clients as we approach February when the data breach laws will take effect?
We haven't really noticed any significant change to our penetration testing business as a direct result of the upcoming data breach legislation. However, we have developed a number of other services in other parts of our consulting practice to help organisations better understand how breach notification will affect them, and what to do. We have definitely seen an increase in interest in those services, and alongside those, we've seen an increase in organisations talking to us about GDPR (the EU's general data protection rules that take effect next year), and how we can help.
In terms of penetration testing, I'd suggest that once companies grasp the full ramifications and requirements that the breach notification legislation brings in, there will be an increased interest in all services that can help to prevent breaches, including penetration testing.
What are the most common holes you find in a company's networks?
Generally the most common issues surround Windows security: insufficient patching, unhardened group policy, and weak passwords. Further to this we commonly notice insecure practices, like insecure use of privileged accounts, or setting the same passwords across devices. Finally, commonly from a security architecture perspective customers have not considered the security impact of two-factor authentication and the correct use of management networks in segmentation and segregation.
How much of bad security is due to (1) users; (2) admins and (3) outsiders?
This is a very good question. If Microsoft had a default group policy option that isn't the most secure option, is this an outsider's fault or the admin's for not having more intricate knowledge? If there is a poor password policy that allows one to login with "Password1" is this the user's fault for picking the password or the administrator's for not setting a strong password policy? Or, is this a policy issue? Really, it's all of these things. Gaps in security arise from practices, policy, lack of understanding of security best practices, etc.
What is really important is understanding the true technical impact of a security problem, and what business requirement has driven the gap. If a customer has a legacy system they simply cannot patch, why not remove it from the domain and segment it into a management network? With a little consideration, there are options to raise the security posture of even the most legacy environments so that these cannot be exploited by attackers to move laterally and escalate privileges.
To what extent does the now common BYOD policy for tech devices add to security issues? What tests need to be done on these devices before they are permitted into a company's network?
BYOD devices have the potential to be a security nightmare. At a principle level security relies on compartmentalisation to work. Known knowns and all that jazz. Putting devices of unknown patch levels, anti-virus status, etc, on your network needs to be strongly considered to get right. At a minimum devices should be encrypted, require strong passphrases to unlock, be running antivirus.
But, more importantly than this, BYOD wireless networks (the common configuration for BYOD deployment) should be restricted to allow access in line with least privilege. That is to say, if a BYOD phone only needs to access the Internet, only let it access the Internet, not your domain controllers! Architect security considering devices are already compromised and an attacker will have their work cut out for them!