In most of the security standards and regulations that I’ve been following there’s typically a part titled Risk Assessment. You can find this requirement in HIPAA, PCI DSS, EU GDPR, NIST, and SANS, to reel off just a few four- or five-letter abbreviations.
What is risk assessment? It’s the process by which you decide where the vulnerabilities are in your system, the likelihood of the holes being exploited, and then the potential impact on your business.
The Art of Risk Assessment
If you want a more formal definition, here’s how the folks at the Payment Card Industry (PCI) define it:
Process that identifies valuable system resources and threats; quantifies loss exposures (that is, loss potential) based on estimated frequencies and costs of occurrence; and (optionally) recommends how to allocate resources to countermeasures so as to minimize total exposure.
Risk assessment, though, is more than just an item you check off after chatting with your IT admins. Yes, there are formal methodologies to help you come up with your own assessment plan — see for example Octave.
Generally, these methodologies ask you to do something that goes a little like the following:
- Inventory your digital assets: locate key IP, customer PII, files, routers, servers, and apps and other software that keep your business going.
- Discover the threats or “threat agents” to your assets: foreign governments, criminal cyber gangs, hacktivists, employees with grudges, and executives who want to steal your IP and start their own company
- Probe the system for vulnerabilities or weaknesses that can be exploited by threat agents: weak passwords, insecure web software, poor BYOD policies, etc.
The last one, #3, is the field work part of the assessment process. Organizations have, until recently, based their security preparedness on a static list of vulnerability checks—“we passed a port scanner test, our anti-virus signatures are up to date, and our employee passwords are six characters and longer so we’re done!”
This is where the penetration (“pen”) tester comes into the picture. With a dynamic threat environment that involves sophisticated players, risk assessment requires a pro who knows what’s been seen, as testers say, “in the wild”.
Enter the Pen Tester
IT security teams can’t keep up with officially published CVEs, let alone new zero-day exploits and phishing techniques heard on the grapevine. So you need someone who’s completely focused on breaking into your system, to put it bluntly.
In fact, the people who write the standards have gotten the message. With the release of PCI DSS 3.0, the credit card folks have upped the bar on their penetration testing requirements. NIST, who’s been recently tasked with coming our nation’s cyber security framework, has also been talking up penetration testing and continuous risk assessments.
What Do Penetration Testers Actually Do?
This is an enormous topic, but researchers have organized their activities into four broad phases: planning, information discovery, attack, and reporting.
Pen testers, by the way, do more than just look for software vulnerabilities. They’re thinking like hackers: after they get into your system, their real work begins. They’ll continue to do more discovery and then base new attacks on what they learn as they navigate through folder hierarchies.
And that’s what makes pen testers different from someone hired to just to find vulnerabilities by using, say, port scanning or virus sniffing software.
Metadata Era readers know that today’s attackers are very good at getting around perimeter defenses through phishing and other social engineering. They’ll continue to do more discovery work and then base new attacks on what they learn as they navigate through folder hierarchies.
A Taste of Post-Exploitation
Over the next few posts, I’ll be examining the attack phase after initial access. In the pen tester’s terminology, we’ll be focusing on “post-exploitation”—what hackers see and do after they’ve entered through the front door.
I’ve already written about some of the tricks of the trade here — Pass the Hash, password cracking, and exfiltration.
In the next post, I’ll take on RATs (remote access terminals — or Trojans) to gain a hacker’s eye view. A form of advanced persistent threat (APT), RATs have two parts. The server side is embedded in the payload of a phish mail, or it can be manually installed by the hacker. The RAT server hides itself within other common software — say Windows Explorer—on the victim’s machine.
The client part is used remotely by the attacker to browse directories, search for patterns in files, and then upload and install additional malware.
With RATs the hackers are not explicitly logged into the system! Hackers communicate with the RAT server module as needed. As a result, security monitoring tools searching for unusual app activity will not necessarily spot anything.
You can think of the RAT as the way hackers get a small foothold in a system, allowing them to take their first post-exploitation baby steps.
