How Face-to-Face Security Awareness Can Prevent Information Leaks – a Pentester’s Experience

How Face-to-Face Security Awareness Can Prevent Information Leaks – a Pentester’s Experience

In August 2008, the DEFCON security conference held its 16th session in the Riviera hotel in Las Vegas, Nevada. Among the litany of brilliant talks on computer security was a 30-minute presentation by Renderman on the topic of attacking client computers rather than servers. It was dubbed “How shall I pwn thee, let me count the ways” and it covered attacking an employee through his network connection, software, and Bluetooth. It was very well received.

I was in the audience for that talk. It was eye-opening; at the time, in my experience, the industry was emphasizing hardening infrastructure against attacks coming from outside companies’ walls. The point Renderman made clear, at least to me, was the ease with which one could compromise employee devices while they are in transit and the ease with which, once back in the office, these compromised devices could be used to access resources that are difficult (if not impossible) to attack from the outside. That same year, I began providing security awareness coaching to my clients, both individuals, and groups. These mostly-informal, 15-minute sessions with employees attempted to convey the fact that one needs to be mindful of the risks inherent to using technology while not being paralyzed by the fear of compromise. When we started offering security awareness training sessions at Kudelski Security, I was delighted to be given the opportunity to contribute to what I think is a cornerstone of corporate security. If our people don’t know how they can be attacked, how can we expect them to defend themselves?

Security awareness coaching is an art rather than a science: you are trying to convey the notion of good security hygiene to people that may not be intimately acquainted with technology, let alone security. As well, more often than not, the people who you are trying to coach are busy and stressed, on top of being confused by the topic of information security. One approach that I think helps in these sessions is to share my experiences as a pentester, to provide concrete examples of what constitutes risky behavior before discussing best security practices for employees to follow.

For example: if during a security engagement, we find an insecure guest Wi-Fi access point, we may try to capture employee password hashes by injecting malicious HTML tags in web traffic. Though one could make a point that the infrastructure, in this case, would greatly benefit from some hardening, what could an employee do to avoid risk? There are several good practices here: the employee could, for instance, choose to use the encrypted corporate access point rather than the guest access point. Using the guest access point with the corporate VPN could also be a viable alternative. If the employee knows how to differentiate between an encrypted and an unencrypted WiFi network, then this could make the difference between an attacker gaining access to the employee’s sensitive e-mails or not.

One challenge that security awareness trainers face is that of producing updated, relevant content. For example: in 2017, ransomware was a dangerous – and rather endemic – family of malware that affected hospitals[1], police stations[2], home users and companies alike[3]. Then, in 2018, ransomware infections took a sudden dive[4]. Is this due to the invention of a miraculous counter-measure that drastically improved computer’s defenses against ransomware? Sadly, no. Attackers realized that it was much simpler and more lucrative to run cryptominers and moved away from ransomware. Trainings should, therefore, focus on how to help users identify cryptominers. If your employees fail to see the relevance of their training, they are unlikely to pay heed to it.

A venerable figure in the infosec community once said that security is a process, not a product. We cannot buy a turn-key solution that magically transforms our infrastructure into an impenetrable fortress. We must make do with a judicious mix of hiring the right people to secure our networked services, acquiring (and tuning!) products that help us eliminate threats, and educating our staff to be sensitive to computer-related threats. This is by no means an easy task; however, it is a vitally important one and success depends on following best practices in all three areas instead of devoting energy to only one.

Interested? Follow the links to more info on security training or penetration testing.





Penetration Testing: Stories from the Trenches, Lessons Learned

Penetration Testing: Stories from the Trenches, Lessons Learned

Last year, my colleague Fabrice wrote about the benefits and challenges of penetration testing to businesses’ security. I decided to revisit the subject and provide more insight as a practicing security engineer.

An opportunity to compile a security checklist

Something I hear a lot when talking shop with colleagues and friends is that the companies they work with aren’t ready to undertake a penetration test (‘pentest’ for short). I find this notion puzzling. Why do they think they’re not ready for a pentest?

“Because you’d get in too easily” is a frequent response. I find this amusing because that is an excellent reason to conduct a security assessment. A pentest is not a validation check that one undertakes when one is sure that the attacker can’t get in; it is an exercise that helps a company identify and prioritize security issues that need to be fixed. It helps defenders understand how an attacker would get in, why it is easy to get in, what impact one can expect from an intrusion, and, hopefully, what countermeasures can be put in place to detect and prevent attacks.

I once had the opportunity to run an internal security assessment for a company that had never had one done before. The first day of the engagement, the client apologized for not having a wired connection ready for us and asked us to make ourselves comfortable while we waited. In the meantime, A guest Wi-Fi connection was available for our use, should we wish to check our mail and prep for the engagement. By the time our contact came back to say the wired connection would soon be ready, we had remote access to several internal systems.

It was easy to gain access to this particular client’s infrastructure; does this invalidate the pentest? Not necessarily. During our assessment, we were able to confirm that an attacker could compromise sensitive business information and cause long-term damage to the client’s systems; it’s one thing to suspect your systems are vulnerable, but to have those suspicions confirmed along with identification of an attack path and a realistic timeframe for an attack is an entirely different kettle of fish. More importantly, our assessment provided a prioritized list of what should be fixed along with suggestions on how to remediate. This ‘security checklist’ is in many ways the best thing a pentest can do for you; it provides you with a starting point for building your defenses so that you can make your security investments count.

A chance to test your defenses before they are tested for you

In addition to providing you with a prioritized list of security issues to fix, pentesting can provide valuable insight into how good your defenses are. Let’s say you’ve invested significant resources into building up your security operations center (SOC). How good are you at detecting intrusion attempts? How fast does it take your team to respond? Are you able to determine how many systems were affected by the latest attack? What is the impact of a successful phishing campaign within your organization? These are questions that are practically impossible to answer unless your SOC has had the chance to test its mettle during an attack.

On one occasion, we conducted a two-part security engagement of a client infrastructure: an external pentest followed by an internal assessment. When I came in for the internal part, the client gave me a tour of their security center, which featured several large screens with the latest security alerts. With a grin, he pointed out a series of alerts tagged with a familiar IP address: their systems had correctly detected not only our automated scans but much of our manual probing as well. They’d also had the chance to use our tests to tune their systems so that alerts would flag an attack without uselessly flooding their monitoring tools with redundant information.

The most productive pentests are those that involve communication between the blue team and the red team; by getting your defenders to talk to the attackers, you can see if your defense has any blind spots. It also gives your SOC the chance to test out some of their response processes or tools that they would not have the opportunity to cut their teeth on otherwise.

A way of seeing how prepared your staff is to attacks

Pentesting is not only a good training opportunity for your team; it is also a good means to evaluate the readiness of your most important asset against attacks: your employees. By that, I do not mean your SOC team: I mean non-technical staff and technical staff alike, throughout your organization. When we organize simulations of phishing campaigns, we request the authorization to send email to a representative population of our client’s staff, so as to realistically gauge the chances of a successful attack and estimate its impact. If the risk is significant, we’ll recommend security awareness training and then a follow-up simulation. You would not believe how a mere two hours of security awareness can benefit your company’s security!

The big picture

Penetration testing is a discipline that businesses often approach with a sense of apprehension, feeling that it is a better investment of time and resources to buy security solutions before mandating a pentest. While it makes a certain amount of sense to be prepared before one is conducted, I would contend that a pentest is a great way to evaluate how your assets, infrastructure, and staff can best benefit from strategic investments in security tools and training.

Penetration Testing: the Risk-Based Way

Penetration Testing: the Risk-Based Way

Usually a pentest is considered to belong to the realm of technical, geeky activities and is supposed to answer the question: “can my company be breached?” Unless you’ve been living under a rock during the last 10 years, you’ll know the answer is a simple “yes.”  It’s just a question of the attacker’s time spent and ability.

There are a lot of pentests available on the market and now is a good time to book one, either to end the year with your security vulnerabilities identified and remediated, or to start next year on the right footing.  To ensure you book the right type of pentest, you need to be clear what a good pentest can do for your organization.

Almost all security companies have a “pentest” services in their portfolio; those that don’t usually employ a third party to do a pentesting engagement for them. Note that I have received many strange requests, including for a pain-test.  This requires an altogether different skill set… Anyway, I digress. Over the last years I’ve seen so many pentest reports, embedding thousands of lines of scripts and logs, highlighting tons of vulnerabilities in huge tables with red flags, some of which are described as potentially critical for the company.

But now here is the interesting question: does the report really present a relevant reality? What can the company do with such report? Are the findings actionable? At first glance, as most of the report focuses on prioritized key elements, you might say “yes, it is.” And that’s true, having priorities listed in a pentest report is good practice. But dig a little deeper and you’ll see that most of the time, unfortunately, the priorities reflect the severity of the vulnerability. Herein lies the real pain point.  Relying just on severity level does not translate into real relevance to the company.

Much more needs to be taken into account when defining a priority. Here’s a simple example that illustrates why: is a critical vulnerability on a test server that is disconnected from the rest of the network really critical? Although a vulnerability is critical, the level of priority should not be defined as high, as the impact on the business will be low or zero. Another example: would it be worthwhile for the client to read a top-1 priority remediation related to a critical vulnerability that indicates that thousands of machines should be upgraded to the latest OS version? Again, although vulnerability is critical, the business context should be considered to present the best remediation actions and the related effort, because – as anyone knows – it is far from simple to upgrade the whole company’s IT.

The risk-based approach to pentesting is something different altogether. Its different approach can be summarized in a few words: to present concrete, actionable and realistic information, it is essential to gather a good understanding of the Client. And when we say “Client”, we mean a point of contact who does not focus on the technical elements of an organization’s security, but rather someone with a broader understanding of the company, its business, its activities and its risk position and appetite. This also means that the most important part of such pentest engagement is the preparation phase during which several discussions with the Client take place in order to understand the business of the company, the company’s risk posture, its concerns, and its assets. In summary, the context.

With such information to hand, the pentest engagement can be performed differently. It is no longer a geeky activity for a geeky Client. It demands that the pentester has a Client-oriented vision, able to understand what a risk is, how they should invest their time during engagement, and even more importantly, how to report a vulnerability and how to classify it in the order of priority.

This approach to pentesting delivers a radically different result. The report of a risk-based approach to pentesting will be different to that delivered by a regular pentesting approach.

No more tons of logs or scripts, no more lists of thousands of vulnerabilities; all this content will appear in the appendices and used as a support to create the actual report where the added value is present. It is not that all this content is unnecessary, these activities need to be executed but they should not to be exposed as such. They should be deeply analyzed and contextualized to provide valuable content.

This is the difference between a vulnerability assessment (which is almost exclusively raw data and mostly performed by automated tools) and a genuine pentest engagement. I’m not saying vulnerability assessments are never appropriate. They have their time, place, and benefits, including the fact that they are (or should be) very inexpensive and that they can provide a gap analysis if done on a weekly or monthly basis. But they will not provide the Client with information on the relevant risks as they affect the business.

The final deliverable in a risk-based approach will consider the context and will contain text, a many humanly-readable text that will not come from an automated report generator. The content will be based on risk analysis, business context, and will present realistic and prioritized vulnerabilities and remediation. It could also show how several vulnerabilities, which in and of themselves are not critical, could be chained together in a real-world attack to have a critical impact.

Finally, a pentest built on a risk-based approach is not much more expensive than a vulnerability assessment-type pentest. It is just the time investment that is different. A significant portion of the time will be invested in the preparation of the engagement, in discussion with the Client and in reporting activities. Then, the execution part will be optimized and will focus on the most important elements and areas. This will also reduce the potential impact on the Client’s operation as the engagement is more controlled, targeted and its duration is reduced.

It is therefore important to keep in mind that if a Client wants to have an actionable output, time will have to be invested in discussion with the pentest provider. If your pentest provider does not ask for it, you will receive a less actionable vulnerability assessment rather than a realistic pentest.

Make your choice.

With the end of year looming, Kudelski Security believes that it’s a good moment for security professionals to take stock of their programs and reflect openly about what works and what could be improved upon. If you are interested in understanding more about how a risk-based pentest can help improve your security posture, we can talk.