There’s no magic wand that can make a ransomware attack simply disappear – with no impact at all on an organization. However, you can lessen the problem by carefully following tried-and-trusted steps in the immediate aftermath of an attack.

The Cybersecurity and Infrastructure Security Agency (CISA) and the Multi-State Information Sharing & Analysis Center (MS-ISAC) have jointly released an in-depth guide that not only includes recommendations on how you can reduce the chances of being the next ransomware victim, but also provide a step-by-step checklist for how to respond to a ransomware attack.

We believe that the ransomware response checklist could be a valuable addendum to organizations’ incident response plans. Your company does have a cyber incident response plan, right?

And the advice couldn’t be timelier, with more and more organizations hit by ransomware attacks that cripple their ability to operate normally or at all.

So, let’s take a look at the checklist step-by-step, focusing specifically on the very first things you should do:

“1. Determine which systems were impacted, and immediately isolate them.

If several systems or subnets appear impacted, take the network offline at the switch level. It may not be feasible to disconnect individual systems during an incident.

If taking the network temporarily offline is not immediately possible, locate the network (e.g., Ethernet) cable and unplug affected devices from the network or remove them from Wi-Fi to contain the infection.”

If it’s one or two computers that have been infected by the ransomware then you may be able to get away with just disconnecting those PCs and dealing with them individually. But if the infection has distributed itself more widely then you may have to take more significant action to prevent the ransomware from spreading further.

So clearly, it’s important to attempt to determine the scale of the problem as quickly as possible, as this will influence the nature of your response.

“After an initial compromise, malicious actors may monitor your organization’s activity or communications to understand if their actions have been detected. Be sure to isolate systems in a coordinated manner and use out-of-band communication methods like phone calls or other means to avoid tipping off actors that they have been discovered and that mitigation actions are being undertaken.”

In some instances, organizations have used personal email accounts or instant messaging services like WhatsApp to communicate if they fear corporate communications systems may be being monitored by the attackers.

Obviously, response teams should be careful to ensure that out-of-band communications they receive are genuinely from fellow workers rather than from malicious actors themselves.

“Not doing so could cause actors to move laterally to preserve their access — already a common tactic — or deploy ransomware widely prior to networks being taken offline.”

But what if you cannot temporarily shut down your network or disconnect affected computers from the network?

In that case, the response guide offers the following advice:

“2. Only in the event you are unable to disconnect devices from the network, power them down to avoid further spread of the ransomware infection.”

However, it should be noted that if you do this you may lose potential evidence about the attack which would be useful to the authorities.

Law enforcement agencies, as well as CISA and MS-ISAC, may be interested in gathering a wide variety of other information that could be useful in their investigation.

This includes, but is not limited to, the following:

• Recovered executable files
• Copies of any readme file (this should not be removed as it often assists decryption)
• Live memory (RAM) capture from systems with additional signs of compromise (use of exploit toolkits, RDP activity, additional files found locally)
• Images of infected systems with additional signs of compromise (use of exploit toolkits, RDP activity, additional files found locally)
• Malware samples
• Names of any other malware identified on systems
• Encrypted file samples
• Log files (Windows Event Logs from compromised systems, Firewall logs, etc.)
• Any PowerShell scripts found having executed on the systems
• Any user accounts created in Active Directory or machines added to the network during the exploitation
• Email addresses used by the attackers and any associated phishing emails
• A copy of the ransom note itself
• Ransom amount and whether or not the ransom was paid
• Bitcoin wallets used by the attackers
• Bitcoin wallets used to pay the ransom (if applicable)
• Copies of any communications with attackers

Even if there is little chance that an attacker might be identified and caught, details like the above – if shared with other companies – could help prevent them from becoming the next victim of the ransomware.

And it is only after the first two response steps that the guide recommends victims attempt to restore critical systems.

“3. Triage impacted systems for restoration and recovery.

Identify and prioritize critical systems for restoration and confirm the nature of data housed on impacted systems.

– Prioritize restoration and recovery based on a predefined critical asset list that includes information systems critical for health and safety, revenue generation, or other critical services, as well as systems they depend on.

Keep track of systems and devices that are not perceived to be impacted so they can be deprioritized for restoration and recovery. This enables your organization to get back to business in a more efficient manner.”

While these first three steps are being considered in order, there is additional work that can be taking place in parallel.

“4. Confer with your team to develop and document an initial understanding of what has occurred based on initial analysis.”

This clearly is a document that will grow over time as more information is found out about the ransomware, and what systems have been attacked and which have not.

“5. Engage internal and external teams and stakeholders with an understanding of what they can provide to help you mitigate, respond to, and recover from the incident.”

The guide provides contact information for CISA, MS-ISAC, as well as the FBI and US Secret Service.

“Share the information you have at your disposal to receive the most timely and relevant assistance. Keep management and senior leaders informed via regular updates as the situation develops. Relevant stakeholders may include your IT department, managed security service providers, cyber insurance company, and departmental or elected leaders.”

The guide also references the “Public Power Cyber Incident Response Playbook”, which although targeted at power utilities contains advice that would be appropriate for any organization needing step-by-step guidance on how to engage teams and co-ordinate messaging to customers and the public.

Ideally you do not wait until you are suffering a ransomware attack to read guidance like this but build a playbook of your own in advance that is specific to your organization.

There are many more steps detailed, and good advice offered, in the full MS-ISAC Ransomware Guide and we would strongly recommend it to anyone responsible for securing an organization against an attack.

Cybersecurity is no exception – there are tools for every need: from firewalls to antivirus and reporting to automation. When it comes to cybersecurity, proper usage of these tools is what separates a mature environment with real protection from cyber threats from a slapdash environment that has tools tossed together in the hopes that they will protect an organization. This difference in an organization’s cybersecurity maturity comes from something that tooling currently cannot offer it is the proper knowledge, understanding, and planning that allows organizations to design and develop an environment that mitigates risks effectively.

To ensure that organizations adhere to a certain level of security and maturity, the world has come up with various standards and frameworks that organizations can use as a guide for building their organization’s cybersecurity strategy. Frameworks such as NIST provide guidelines that organizations can use when building their cybersecurity strategy but do not provide certification options like standards such as ISO 27001 or SOC2 do. This certification option is essentially a verification for anyone else that an organization meets a standard level of cybersecurity which is quite important in today’s world. Having these certifications may be requirements at a government level, such as HIPAA, or they may be required to perform business with another organization at a contractual level.

Regardless of where the requirement is coming from, compliance with robust and well-designed standards is fast becoming the norm in today’s business industry. This shift has led to many organizations struggling to implement cybersecurity programs that adhere to the wide range of requirements these in-depth standards dictate. These new requirements in turn have led to the development and popularization of tools meant to help organizations achieve these compliance requirements. However, this has led many organizations to falsely believe they only need to use a tool to pass an audit. This is through no fault of the tool providers but rather it comes from a lack of thorough understanding or misunderstanding by the organization of what exactly is required for compliance with these standards.

Mature standards will often consist of at least two requirements: the first is documentation in the form of written policies, the second is implementation and the monitoring of controls. The written policies govern what an organization’s strategy will be, how they will identify risk, and how they plan to manage the risk. Implementation of controls on the other hand is closer to what people traditionally associate with cybersecurity: i.e. using firewalls to block network traffic or installing antivirus to prevent against malware. Tools are needed to implement many controls, including firewalls and antivirus, and many tools exist for helping an organization to implement a cybersecurity strategy that adheres to the standard the organization is attempting to meet. The keyword here is “help” – as they can play an important role and can be of great help to you and your organization. However, they ultimately cannot replace a solid cybersecurity strategy or knowledge to design and implement adequate controls. Controls, that not only fulfill the requirements but do not unnecessarily complicate processes for your employees.

To properly implement a cybersecurity program that will pass an audit and achieve certification, organizations need to have an in-depth understanding of how each requirement in a standard fits together to create a mature cybersecurity program. This task requires a human being with knowledge of the standard and the ability to both, create the policies necessary, and select the right controls for the organization. Once an organization has identified the person(s) who have this knowledge and can implement the standard for them, then the person(s) selected to do this work can identify tools that may make achieving the compliance easier.

These tools may include preassessment tools meant to identify and display the difference between where an organization currently stands and where they wish to be (Gap Analysis). Other preassessment tools allow for tracking of the status of the implementation, collecting documents as evidence, and the generation of reports to be used to demonstrate compliance in the audit itself. Regardless of which tool, they require people with the knowledge of the standard to input meaningful and adequate data so that these tools can be accurate.

Similarly, the use of templates for policies might help overcome initial writer’s block, hence facilitate the process of writing policies for an organization. Without a proper understanding of the requirements of the standards, however, these templates may end up lacking the necessary components that allow an organization to meet the standard and achieve certification.

Bottom Line:

Tools available for cybersecurity can play a useful role in a well-structured cybersecurity strategy. However, it is important to keep in mind that these tools are never a quick fix nor guarantee for security or compliance alone. In fact, using a variety of tools from multiply vendors might cause more and not fewer headaches. It is the knowledge of how standards work that allows us to pick the right tool for the job as well as understand the limitations of any tools selected.

When it comes to cybersecurity compliance with any of the standards specifically, self-assessment tools and software that keep track of the implementation status of a standard like ISO 27001 or NIST can be very useful, facilitate communication within the organization and with consultants like Ecuron. These tools can reveal gaps, track implementation and save time – but they can never replace the know-how to plan a solid cybersecurity strategy as a foundation or fulfill essential compliance requirements such as selecting efficient controls to put in place.

It is easy to get caught up in the hype of what the latest technology is, and the latest vulnerabilities in that technology – but it’s vital that we remember that the technology is only a tool to assist people in accomplishing their goals. Malicious actors aren’t just “out to get you”, they have motivations and goals that they are trying to accomplish. These goals vary from individual to individual, but most malicious attacks are performed for reasons as old as time: for financial gain, revenge, or to discredit rivals. Even nation state actors have goals that we can understand from a human motive: to further their own nation’s place in the world and to weaken their enemies. Whether that’s performed by introducing malware to affect nuclear centrifuges (Stuxnet) or by creating an army of bots and weaving a web of disinformation (Russian election interference), the motivations still become clear when you consider the people behind them and what it is that they hope to accomplish.

The reason it is so important to remember this: when malicious actors attack organizations, they are actively considering the people in place, their individual motivations. They are leveraging any personal information when building attack campaigns. Will people be more likely to open an attachment in an email from Bob274373982 or one claiming to be from the IRS that says they owe money? This is one reason why IRS scams are so popular each tax season. Does the developer really want to have to enter credentials each time they test an application? Of course not, so they come up with shortcuts. From hard-coded credentials, to passing in credentials automatically, or even removing authentication altogether when testing. While this isn’t something that most people are thinking about when they are just trying to do their job, it certainly is exactly something that malicious actors are considering while planning and executing their attack.

Fortunately, technology has come a long way forward in developing ways to counteract human weakness when it’s utilized properly. Tools that look for hard coded credentials in source code before the code is published can reduce the risk of lazy developers opening a security hole. Email filters and anti-phishing software can prevent the IRS scams from getting to employees in the first place. There are solutions, that when implemented properly, can be used to mitigate the risk presented by an organization’s untrained personnel.

Attackers have a very effective weapon in their arsenal when planning and executing attack campaigns – and it’s nothing technical: they constantly consider and plan around the human element. However, that doesn’t mean that the attackers are immune to human shortcomings. When designing an organization’s security strategy, it’s important to think about potential threats to your organization and what their possible motivations might be. This can help an organization better understand both, how they might be attacked and how to secure against that potential attack. In part two of this series we will explain the human side of the equation from a defender’s perspective and how that fits into an overarching security strategy.

Two stories from my own experiences demonstrate the importance of Incident Response Frameworks and the impacts of not having the right elements in place. The stories I relate here arose from my own experience assisting with Incident Detection and Response. In these cases, the lack of a robust Incident Response Framework (IRF) led to an extended Incident Response (IR) process, resulting in increased risk towards the organization’s objectives. I’ll illustrate how a seemingly unimportant and often overlooked piece of an organization’s overall security posture can lead to substantial financial and mission objective impact. By sharing these stories, I hope to help you to avoid experiencing a similar challenge.

Story One: When a Whale Gets Phished

Phishing is the fraudulent practice of sending emails purporting to be from a reputable company that is actually sent from a malicious party usually with the intention of inducing the victim to reveal personal information such as passwords or credit cards. These emails are usually mass spammed with the idea that if you send enough of them you are bound to get some responses. A more targeted form of this attack, in which the threat actor tailors the email to specifically targeted individuals, is known as a Spear Phishing attack. Whale Phishing is a version of Spear Phishing in which the phishing emails are targeted at high-level executives. This allows an attacker to leverage the executives high level of access and authority within the organization for malicious purposes.

In this story the targeted individual was an executive within an organization who fell victim to a phishing attack that gave the attacker the credentials to the executive’s Office 365 account, allowing them to not only copy sensitive information from the executive’s email and SharePoint, but also to send emails as if they were the executive in question. The attacker leveraged this access to send an email to the financial department asking for a wire transfer to a bank account which, if not for the diligence of the employees of this organization, could have led to thousands of dollars in losses. That said, the importance of this story lies not in the attack itself but rather in the Incident Response process of the organization.

When I was first alerted to the email asking for the invoice I was looped in after the account password had been reset and Multi-Factor Authentication had been enabled to prevent the attacker from further illicit access. My purpose was to help the organization identify how the account was compromised and to determine the scope of the compromise. At this time, it was not yet confirmed that the initial attack vector was phishing and we also were unsure if the attacker had managed to con the executive into installing malicious software on the executive’s workstation as well. As such we decided upon a two prong approach of reading logs, both email and workstation, as well as performing basic endpoint investigation on the executive’s workstation to ensure that the machine was not compromised as well as the executive’s Office 365 account.

The issue that we ran into is that when attempting to perform the endpoint investigation on the executive’s workstation we were unable to get ahold of it. While this person was in the office for the first two days of the investigation, they were unwilling to give up their laptop, citing a variety of excuses. As a result, what might have been a week-long investigation turned into a several week ordeal lacking only performance of the endpoint check to consider this incident successfully resolved. The failing with this organization’s Incident Response Process became quite apparent: lack of executive buy-in. As discussed in my last article, it is vital that the security team have the authority to perform their jobs when in the middle of an incident. Had the executive’s workstation been infected, the risk to this company would have been greatly increased with each passing day.

While it is understandable that executives have mission critical work to perform, it is unacceptable not to work with the security team to find alternate ways to perform this work (even at a semi-reduced capacity) while an incident is ongoing. It is also important for the security team to understand the executive’s need to perform their job and to work with them and the IT team to solve this problem. My personal favorite method is to provide the executive with a replacement laptop that is built from a backup image of a known good configuration that they can use while security is performing their investigation, with the onus on the executive to have proper data backups so that they can access the information they need while the investigation is being performed. This would have led to a quickly resolved incident with all stakeholders assured that the threat had been properly contained and mitigated, allowing us to move on to other tasks rather than wasting time each day looking for suspicious logs coming from the executive’s potentially compromised workstation.

Story Two: Clear Communications

In this story I was brought in after the first 24 hours of the investigation had already passed to assist with providing ancillary information that would help the teams working the investigation to uncover the full timeline and scope of the compromise. I was told that a compromised system had been detected and initial investigation revealed lateral movement onto several systems. The goal of bringing me in was to help ensure that remediation had worked on the compromised systems and to look for Indicators of Compromise (IOC’s) from systems that had not been identified as compromised. It quickly became apparent that there was no IR in place, or if there was it was not flexible enough to account for this particular scenario. What should have been a 48 hour investigation followed by monitoring turned into an investigation that lasted almost a week as new problems in visibility were found and tools built to try and work around it. This was combined with a lack of clear and transparent communication between the various teams working on the incident and was further hindered by the fact that there were three third-party organizations working alongside the compromised organization, with limited communication and collaboration between the third-party organizations.

Over the course of this investigation it became clear that three key pieces were missing from the IRF that would have allowed for faster resolution and lessened financial impact. The first piece that was missing was a clearly defined escalation process. As a result, escalation to the wrong parties before certain parts of the IR process had taken place caused panic and led stakeholders to disagree on the best way to go about the IR. The second missing piece was designating who should oversee the IR process, from declaring it an incident to declaring the incident completed. And the final missing piece was clear communication between the various parties assisting in the investigation. The third-party organizations brought in to assist with the process were able to apply their own methodology and known best practices to the investigation of the compromise so that ultimately the incident was successfully contained and remediated. But the entire process was rendered highly inefficient due to the lack of a more clearly defined escalation process and assignation of responsibility within their own organization. Bad as it was in this relatively simple incident, such a problem would quickly spiral into major complications in a more complex and severe incident.

Conclusion:

As I’ve stated before, it is usually not the lack of proper tooling but rather the processes around tools and people involved in the IR process that leads to IR failure. In the first story we saw how a lack of executive buy in and lack of authority given to the security team can lead to greater financial risk for the entire organization. It’s not enough to have a security team with an Incident Response Framework, they also must be able to execute the processes laid out in the framework to be effective. In the second story we saw how a lack of clearly defined escalation paths and lack of assigned responsibility led to an increase in overall cost for the Incident Response process. By clearly stating to whom the incident should be escalated, we ensure that the proper stakeholders are notified at the proper time. With proper assignation of responsibility for each part of the IR process to the proper people we ensure that there is quick and clear communication amongst all parties involved, contributing to an efficient resolution.

When an organization includes these elements into their IRF, they reduce the risk to their organization in the event of an incident. This reduced risk directly translates to a reduced overall cost for the incident response process and a reduced negative impact upon the organization’s objectives. It is through proper planning and the design of flexible frameworks that organizations will be able to meet the ever-changing threat landscape of tomorrow.

What a MITM attack is

At its core, a MITM attack is a type of eavesdropping attack that occurs when a malicious actor inserts himself between two communicating parties. This allows the attacker to relay all communication, listen to it, modify it, and even impersonate one of the parties.

Nothing new

One of the most famous examples of a MiTM attack happened in 1568, long before computers were even invented. Known as the Babington Plot, communications between Mary Stuart and her supporters surrounding a plot to assassinate Queen Elizabeth I were intercepted by a third party. Altering the content of the messages revealed the identities of those involved in the plot, and they were executed.

In more recent times, MITM attacks have been used by everyone from criminals looking to commit financial fraud to the NSA looking to intercept Google searches. These modern MITM attacks, and the ones that the term is most applied to these days, are generally executed in the realm of Information Technology. There is a variety of ways that this technique can be used. Essentially, anytime there is communication between two parties a MiTM attack can be performed.

MITM and emails

When it comes to emails, this is often done using Domain Name Resolution (DNS) spoofing, in which an attacker convinces a victim that they are the authoritative DNS server and then routes the traffic to a server that the attacker controls. In the case of attacks against financial institutions, attackers will gain control of an email account of someone like a financial advisor or bank representative and then send an email purporting to be this person asking victims to send money to bank accounts owned by the attacker. Other cases are real estate closings and commercial transactions which are frequent targets: a hacker first acquires access to a firm’s server, then redirects all e-mails associated with the firm’s server to the hacker’s server. This allows him to subsequently change payment information and other information in those e-mails to defraud the firm and those working with the firm.

The confusion

A lot of the confusion seems to stem from the fact that unlike an SQL injection attack, which by definition only works against SQL databases, a MITM attack is not limited to one technology or type of technology. Instead, it is an umbrella term and can be performed anytime there are two parties communicating – typically combined with other techniques such as phishing. This ambiguity is the reason that one of the most robust attack type classifications, the ATT&CK matrix from Mitre, doesn’t even list MiTM in their matrix of attack types.

The bad news

If a MITM attack is successfully performed, the victim has no idea that the attack is happening. In the case of fraudulent emails during real estate closings for example, the email was sent from a legitimate address, the victim has reason to trust the sender (i.e. title company), and there is plausible reason for the compromised email account to be asking for money to fund the business transaction. If the MiTM attacker used DNS spoofing, the victim would have to be actively monitoring every DNS request and know the legitimate DNS servers IP address by heart and then notice the discrepancy. And while there is software out there that can help detect DNS spoofing, a regular consumer will not be using it.

The good news

Without you even noticing, there are many protections against MITM attacks already in – such as right now while you are reading this article. One of the major reasons for websites to implement HTTPS is to greatly increase the difficulty of performing MITM attacks. When you first browsed to this website, your browser verified the validity of the SSL certificate of this website to ensure that the website you are visiting is exactly who it says it. Have you ever gotten a warning from your browser that the website your visiting isn’t safe? That’s usually because the SSL certificate is either expired or for a different website than the one you are visiting. This is how the browser tries to help you avoid being caught in a MiTM attack. To protect against financial attacks from compromised email accounts, many organizations require secondary authentication to help prevent that type of MiTM attack. Typically, before allowing monetary transfers a phone call to confirm the information and the request sent by email are mandatory.

Bottom Line

While there are many different types of MiTM attacks and they can occur in a variety of ways, Man-in-the-Middle means an attacker is positioned to intercept and/or modify communications between two parties. Email conversations are prone to this and DNS spoofing is a common way of achieving it.

1.      Application Penetration Test

The application penetration test is a test designed to identify and demonstrate the exploitability in any given application, defined by the scope of the test. If, for example, you want an application penetration test on a web application used by your company then the penetration tester would limit the test to the web application itself and not attack the web server or other services running on the machine where the web application is hosted. The purpose here is to test the security of the web application itself and look for design flaws in the web application which could allow an attacker access to sensitive information. This can be accomplished by attacking it as an external attacker might, with no knowledge of the source code, which is an example of the black box methodology applied to an application penetration test with a scope of the web application. Or it could be accomplished by giving the penetration tester full access to the source code as well as a running instance of the application itself, an example of white box methodology applied to a web application penetration test.

Application penetration testing is not only limited to web applications however, it can be applied to any application that an organization has developed. Mobile applications, desktop applications, and anything in between can all be tested for vulnerabilities via various techniques specific to the application type being tested. Typically, web application testing is included with a network penetration test (more on that later), whereas desktop or server applications are often performed as standalone penetration tests that do not require an organization to spend the money and time on a lengthier full network penetration test.

2.      Network Penetration Test

A network penetration test is the next type of penetration test, and the one that most people think of when they discuss penetration tests. In a network penetration test the penetration tester will attempt to gain access to sensitive information by testing the full range of an organizations network. This usually involves techniques such as port scanning and open source intelligence gathering to gain information on the target network followed by vulnerability scanning to gain information about possibly vulnerable services being run by the target. Once access to the targets network has been achieved the penetration tester will then use the access they have gained to further penetrate the target organizations network as much as possible within the scope and the time constraints given by the engagement. While it is called a network penetration test, these tests usually include web application’s and any running services or programs that the penetration tester can gain access to. However, network penetration tests will usually not include other attack techniques such as social engineering or physical penetration testing.

3.      Social Engineering Penetration Test

               The third major type of penetration test is the Social Engineering penetration test. Social Engineering is a type of attack that malicious actors use to leverage human nature in a variety of techniques against the target. The goal of this test is to try and utilize social engineering techniques to gain access to the target organization. Depending on the scope of the engagement, such as whether it includes physical locations, different types of Social Engineering techniques will be selected for use in the penetration test. The most common type of Social Engineering penetration test is Phishing, in which the penetration tester sends email’s to users in the organization under different pretexts to attempt to get the users to either download malicious files or give their credentials to the attacker. This may be performed either by itself or in combination with other penetration test types, such as a Network Penetration test.

Other Social Engineering techniques will often be used in combination with a Physical Penetration test to gain access to the offices of an organization. These include things such as tailgating, following an employee inside without having a badge, or pretending to be a service employee there to perform maintenance of some sort with the intention of gaining access to the building that the penetration tester shouldn’t have.

4.      Wireless Penetration Test

               Wireless penetration testing is when the penetration tester attempts to gain access to sensitive information via the organization’s wireless network. In this sort of test, the penetration tester will need to be on site in order to properly perform this test. In a black box wireless penetration test the tester will first have to gain access to the wireless network, which is a good way to test the security of the wireless network against attacks such as wireless password cracking. Once access has been gained, the penetration tester can then test for vulnerability to other attacks such as Man in The Middle (MiTM) attacks and sniffing for unsecured sensitive communications. Alternatively, a white box wireless penetration test would be when the penetration tester would be granted access to the wireless network so that they can test for the MiTM and unsecured communication’s without first having to spend the time trying to break into the wireless network resulting in a shorter amount of time needed to complete the penetration test.

5.      Physical Penetration Test

Physical penetration testing is often the most underutilized, and most sorely needed, of all penetration test types. It doesn’t matter how good your firewall is if an attacker can easily walk into your building and plug in a USB drive. Once an attacker has physical access to an organization’s environment, it is usually quite trivial to gain access to confidential and proprietary information. When a penetration tester is performing a Physical Penetration test, they will use a variety of Social Engineering techniques, such as tailgating, to gain access to a facility. The purpose of this sort of test is to test how easy it is to bypass physical defenses, up to and including personnel at the location, in order to gain access to the organization’s network. This type of penetration test is often one of the most costly as the penetration tester must be on location in order to perform it. However, it is also one of the most important to perform as physical access is usually the biggest vulnerability any organization will have.

What Is Right for Your Organization?

               As seen above there are quite a few different types of penetration tests that can be performed, often with at least some level of overlap. When deciding which type of penetration test is right for your company it is important to consider what the goal of the penetration test is. Do you want to test for vulnerability to internet based attackers? Do you want to know the effectiveness of a phishing attack against your organization? Or are you most worried about people gaining access to your office in an illicit manner in order to access your proprietary information? Knowing what you want the penetration test to test for is the first step in deciding what type of penetration test is right for your organization.

After deciding upon what the purpose of a penetration test is you will be able to select the type, or multiple types, of penetration test that will best accomplish your objective. This is then followed by deciding upon the scope of the penetration test. In the case of a network penetration test you may wish to restrict the scope to specific IP addresses or domains, or you may wish for all IP’s and domains owned by your company to be tested by the penetration tester. This scope definition will also help you clarify what methodology you wish the penetration tester to utilize when performing the penetration test. If your goal is to test your vulnerability to internet based attackers against all of your company’s production assets, you would probably ask for a network penetration test including all web applications performed with the black box methodology. In other words, restricting the scope to only production assets to reduce the time of the engagement but asking them to attack those assets as a malicious internet based threat would.

On the other hand, maybe your goal is to test for your organization’s vulnerability to an insider threat. You could then ask for an on site penetration test involving Wi-Fi, Social Engineering, and Network Penetration using a white box methodology. While this type of test may involve techniques from several different types of penetration testing, by stating the goal as that of being testing for insider threat the penetration tester has specific attack venues to attempt via white box methodology which can significantly reduce the time needed to perform the engagement.

Red Team Testing

               There is one final type of testing that goes by several names but is often referred to within the Information Security Community as Red Team testing. This is basically a “gloves off” approach to penetration testing in which the penetration tester will perform any and all techniques they can to attempt to gain access to your companies’ sensitive information. Engagements of this variety often take much longer to complete and thus be more expensive, however, they are also the best way to gain a complete look into the state of information security within your company. It reflects best the threat an organization faces when under serious attack such as by state sponsored attackers. The team performing the penetration test will often break a Red Team engagement into several phases, each consisting of a different methodology and attack technique so that they can accurately simulate the various threats that your organization may face.

Post Engagement: What to Expect

               After a penetration testing engagement is complete the final deliverable to an organization should be a report in which the penetration tester outlines the results of the test. Typically, report writing takes the same amount of time as the actual engagement, so for a 5 day engagement expect 5 days for the penetration tester to complete the report. Upon delivery of the report to the organization, a post-engagement meeting should be held between the penetration tester and the organization’s management team to discuss the findings in the report.

A good report will include an executive summary of the engagement which includes the purpose, a general idea of methodology and techniques utilized, and an overview of the findings. The report should contain a technical section that can be disseminated to the organization’s technical teams which outlines how the penetration tester was able to exploit vulnerabilities and what that allowed them access too. In addition, it should provide a detailed breakdown of each vulnerability found, whether or not it was exploited, the severity of the vulnerability, and a quick note on how to go about fixing the vulnerability. This technical portion should then be used by the organization to improve their security posture.  

Conclusion

                When it comes to testing your organization’s security posture there is no better test than a penetration test. It can be used to test with a limited scope such as only your web application, it can be used to test your entire network including onsite Wi-Fi and secured areas via physical penetration testing or within the much wider scope of a red team engagement . And it can be performed in a couple of different ways, depending on what sort of threat to your organization you wish to test for and the time constraints on when you need the final report. Network penetration testing will often be longer than application penetration testing, however it also usually includes website application penetration testing within the scope. A physical penetration test may be done quite quickly; however, it will be more expensive due to the need of the penetration testing team to actually be on site in order to perform it. No matter the type of testing, you should always expect the final deliverable to be a detailed report that will not only detail the issues found but also give you a road map to addressing them.

To receive a sample report or to discuss your penetration testing needs please contact us.

Previous Articles from This Series:

Vulnerability Scanning vs Penetration Testing: Part 1

Vulnerability Scanning vs Penetration Testing: Part 2

But what exactly makes healthcare such a popular target among today’s cyber-criminal community – how big are cybersecurity risks in the healthcare sector really? In this post, we will take a look at what’s so appealing to malicious hackers about the healthcare industry, including:

• Sensitivity and Value of Health Information
• Control of Medical Devices and Systems
• Healthcare is Vulnerable

Sensitivity and Value of Health Information

Cybercriminals that are able to penetrate healthcare networks gain access to sensitive information through medical records. The value of a stolen record is based on its ability to be replaced. For example, credit cards are easy to replace. It simply involves a phone call to the card issuer and a trip to the bank to get a new one. Patient records and other human data, however, are difficult if not impossible to replace. Electronic Medical Records (EMRs) serve as a one-stop-shop thanks to the availability of full names, social security numbers, addresses, and more.

This information can be used for financial fraud outside the healthcare industry and if the victims’ health insurance information is gathered, criminals can then sell the information for even more money on black markets. In fact, one Medicare number can reportedly sell for nearly $500 on today’s black market – which is up to 10x the amount of a credit card number. Health insurance information can be leveraged for medical fraud, and arms criminals with the information needed to access free medical care, prescriptions, or even the ability to buy expensive medical equipment that can be sold for profit.

Lastly, stolen medical data can go undetected for much longer periods of time than something like a credit card, which is often closed within days of a breach.

Control of Medical Devices and Systems

More internet-connected medical devices and systems are being incorporated into the framework of healthcare than ever before. As a result, cybercriminals are being provided with more avenues of ingress and surfaces to attack than ever before.

Connected devices like drug pumps or pacemakers that are commandeered by cybercriminals could have fatal consequences. However, cybercriminals also try to breach non-life-threatening devices to gain access to systems. Newly introduced connected medical devices are especially vulnerable to threats, as security can oftentimes take a backseat to device performance and convenience across the industry.

Once cybercriminals find their way into networks, they aren’t just using access to steal patient data. In the past years, there have been a number of instances where ransomware was used as a means for quick financial “wins.” With ransomware attacks, cybercriminals seize control of systems and lock them up until the institution pays them currency for returned access. Healthcare institutions are often pressured into paying the sums of money being asked as prolonged downtime can be damaging not only to reputation as in any industry, but more importantly, patient safety. One of the most notorious ransomware attacks of all involved the WannaCry ransomware, which is believed to have struck 34% of all the National Health Service (NHS) trusts in England.

While we strongly oppose paying ransoms, this unique situation creates a more complicated scenario: It depends on the systems that were affected. Law enforcement has come out strong against paying the ransom for fear it will open up a Pandora’s box, but if patients’ health is at risk and the hospital’s business is affected severely, they may not have a choice.

But even if the attackers keep their word and decrypt your data after you pay, there is no guarantee that they will not leave other forms of malware running on the system in order to carry out other crimes, like sending spam emails, launching DDoS attacks, and stealing personal or financial data for use in online fraud and identity theft. This means, the cost of cleaning the organization’s IT environment could easily exceed the ransom that was paid many-fold.

Healthcare is Vulnerable

With so many connected pieces of medical equipment and different types of software being run, it’s a challenge for healthcare organizations to successfully defend against attacks. Inadequate budgets and a lack of skilled security personnel, combined with the hurdles presented by a variety of security needs, are all holding healthcare institutions back. And cybercriminals are aware of these struggles.

As a result, the industry’s vulnerability makes it an easy target for criminals. An attacker targeting a healthcare organization often has the luxury of gathering a little bit of information from one system, and then moving on to their next target without being detected. The number of vulnerable systems in an existing healthcare network makes it simple for them to collect a number of small wins over time that can equate to a big win overall.

And as proven in the last years, a relatively small-scale attack with only a few individual systems infected with ransomware can have a devastating effect – i.e. it can force an entire hospital to revert to a manual system to provide care because the data isn’t available otherwise. Health organizations have to start considering the fact that the integrity of the data and the availability of the data is in many ways more important for the operation than confidentiality.

End of 2018, Michigan-based medical billing company Wolverine Solutions Group (WSG) reported thousands of patients impacted by a ransomware attack. According to WSG, its critical operations were down for over 40 days after the ransomware attack was initially detected. While this is bad enough – work has continued in the months since to identify those individuals whose healthcare clients were affected. The company has mailed out a number of notifications to affected individuals in December, January and February, and says it will send out more this month.

Final Thoughts

As evidenced by the headline-grabbing data breaches over the past few years at large insurers and healthcare systems, hackers are finding the most lucrative information in patient medical records. As a result, there is more pressure than ever for healthcare organizations to refine their cybersecurity strategies.

Today’s healthcare organizations need to think about ways to speed up and improve their security. Comprehensive cybersecurity solutions that address today’s borderless attack surface make it possible for healthcare institutions to be both secure and high-performing at the same time. An added benefit of making security a primary requirement for every data record and application is faster processing due to increased trust and proven competence.

Additional Reading:

Penetration Testing Methodologies & Scope

When looking at the different types of penetration testing there are two parts that need to be considered: methodology and scope. The first determines what exact type of penetration test will be performed – where the different types are primarily differentiated by the amount of information provided to the tester at the outset. The second breaks down the scope of the penetration test which can vary by what is being examined: Will it be limited to just web applications? Will the network be involved? Should the server software be included? Would DDoS be allowed for testing? In today’s article I will focus on the main types of penetration testing techniques, and in a future article we will go into the issue of scope.

Different Types of Penetration Testing: “Boxes”

The three main types of penetration testing are often referred to as “Black Box”, “Grey Box”, and “White Box”. A different set of information about the IT infrastructure to be tested is provided to the tester in each of these, simulating the different types of attack which might be perpetrated by a malicious actor. The choice of which “Box” to use will be driven by the type of information the test is intended to reveal.

Black Box Testing

“Black box” is a term used through programming and engineering to depict a situation in which you know what goes in and what goes out but have no information about what happens within the box. For example, let’s look at a car. The average driver knows that a step on the accelerator (gas pedal) accelerates the car, however, they do not know exactly what sequence of events causes acceleration (black box). What is known is that the input, stepping on the accelerator, provides the output of acceleration.

Similarly, in black box penetration testing all that is known to the tester is the target IP’s, domains, and/or applications that they can attack. It is up to the penetration tester to use their own ingenuity and resources to determine specifics about the target such as the operating system, open ports, possibly undefended resources, etc. This type of penetration test is most analogous to a real-world malicious actor attempting to break into your organization. A malicious actor will only know what they can publicly find or derive via scanning tools and base their attack on that information.

While this covers the most common scenario, it does have the downside of missing anything that could be derived from an insider threat or any information that a malicious actor may find that the penetration tester cannot for whatever reason. To account for the possibility that a malicious actor may have more information & resources available than thought possible – think i.e. state sponsored hacking – there are two more methodologies of penetration testing.

White Box Testing

The idea of a white box is meant to be the exact opposite of a black box: the tester can see every single internal working of the “box” that leads to an output. In terms of our vehicle acceleration analogy above, it’s more like a bicycle than it is a car engine. When you turn the pedal on a bicycle you can see the chain and the gears interacting which lets you see exactly how it is accelerated. In the same vein a white box penetration test is one in which the penetration tester has full access to the IT infrastructure source code, system architecture, and even internal security controls before beginning the penetration test. This allows the testers to perform a faster penetration test because they don’t have to wait for i.e. port scans to finish – instead they have that information available already. Similarly, the penetration tester does not have to gain access to an organization’s network via an exploit in order to find internal security controls that are lacking. The largest advantage of a white box test is that a penetration test is more likely to uncover problems than in a black box penetration test. Consequently, the resulting report will be more detailed which will allow an organization to have the greatest opportunity for improvement to its security posture.

Grey Box Testing

As the name implies, grey box testing is meant to combine the ideas from both black box testing and white box testing in a middle ground that uses aspects of both methodologies. Most often, this is achieved by providing the penetration tester limited information about the inner workings – i.e. by giving access to system architecture diagrams and possibly even source code for perusal. The idea here is to give the penetration tester knowledge that will allow them to target their attacks from the beginning like in a white box test, but still attack the organization from outside in a manner like a malicious external actor would. By utilizing diagrams and source code the tester can pinpoint the most likely weaknesses and get started on manually attacking those even while the automated scans a black box test uses are running concurrently.

Which Box Is Right for Me?

There is no one methodology that fits all organizations, as it is largely dependent on an organization’s individual security goals and requirements by security standards such as ISO 27001 or contract partners. To pick the appropriate methodology you need to determine what the goal of the penetration test is. If it’s simply to meet a contractual obligation, you may elect for a grey or black box test as it will most closely simulate an external actor.  Unless the penetration tester can breach the perimeter, it will keep the list of fixes potentially required to a manageable amount. On the other hand, if your goal is to be as secure as possible no matter the work required to fix potential issues, you may elect for a white box test or a grey box test with source code analysis included. Here, the list of findings can result in a much longer list of fixes required and include various internal mechanisms that need to be addressed.

In the next article we will address different scopes of penetration tests in relation to the methodologies and how both, the scope and methodology chosen can influence time and investment.