>Pen Testing for Low Hanging Fruit

>As a professional penetration tester and a business owner I am often asked, “Why should I pay you to break into my network?” There are many reasons for doing so and they have been discussed in many different places over the years.

In fact, there are probably as many reasons for performing a penetration test as there are for NOT performing a penetration test.

This article will explain what is penetration testing [1] and give some reasons for and against performing such tests.

This article will also describe some of the issues involved in deciding whether or not to perform penetration testing using internal staff or whether you should outsource the testing to a security vendor [2].

Penetration testing will also be discussed from an IT Security and Privacy perspective. The concept of Low Hanging Fruit (LHF) is then defined and the benefits of performing penetration tests to discover LHF are described.

What is Penetration Testing?

As a security professional I feel I have an obligation to my clients to try and persuade them to perform periodic testing from both an internal and external perspective.

I use the term “persuade” because often times it comes down to a passionate discussion about the risks and rewards of performing such tests.

Before going too much further I should define what I mean by “internal” and “external” testing. An “internal” penetration test is typically performed by plugging into the client network as would any normal employee.

One of the goals of penetration testing is to test for vulnerabilities that could be exploited by employees, contractors, guests and automated attack software such as worms, viruses and trojans.

The current use of malware by attackers is increasing and is often combined with other attacks such as phishing and can lead to identity theft.

There are many security and privacy concerns related to keeping such malware out of an organization. What once was controlled by simply installing anti-virus software has now grown into an industry separate from anti-virus programs.

An “external” penetration test is performed by attacking the client from the outside of the security perimeter. These tests model the attacks available to anyone around the world with the time, tools and motivation.

This is typically the area that most IT Security personnel spend the most time, energy and money controlling. Management understands the concepts of “perimeter security” and such purchases require less justification than other security initiatives.

This testing typically includes wireless, dial-in, and VPN access plus all Internet-facing computing resources.

Testing can also include social engineering components.

Some of the common social engineering tests include dumpster diving (going through an organization’s trash), sending phishing emails to employees, trying to gain physical access to facilities dressed as repairmen and testing physical controls including doors, locks, cameras and fencing.

There are many regulations regarding the proper disposal of paper documents and the dumpster diving test is important to ensure that privacy concerns are being properly satisfied.

Phishing emails sent to employees are used to ensure that privacy procedures within the organization are being followed by testing the reaction of an employee to accept or send sensitive information via email.

For years security professionals have debated the definition and merits of penetration testing. Many security practitioners and vendors still debate the definition of terms.

While there are technical distinctions between the terms “vulnerability assessment” and “penetration test”, for the purpose of this article I will stick to the use of “penetration test”.

To differentiate themselves vendors use terms such as “vulnerability assessments”, “tiger teams” [3], “white hat hacking”, “black hat hacking”, etc. Some vendors and clients do not like the word “hacking” in the title since it implies some illegal activity.

Regardless of what term you use the goal is to help protect the electronic assets of an organization and help it comply with all required privacy regulations.

There is a fair amount of overlap between IT Security and Privacy and by performing penetration tests we can satisfy a fair number of requirements for each.

Some of the reasons to perform a penetration test include:

  • To satisfy legal and/or governmental requirements such as HIPAA, SOX or GLB.

  • To become compliant with industry standards such as PCI [4].

  • To comply with Internal Audit requirements.

  • To develop a baseline of the overall security posture for new management.

  • To assess the security posture of an organization in an acquisition or merger opportunity.

One of the real benefits of performing penetration tests is what I call “putting together the pieces”. Management needs to understand this is where the real value lies in performing penetration tests.

Most people can clearly understand the danger in having a weak password on a server but not everyone can use that password to gain access to another server. This access will often provide information needed to take control over their network infrastructure.

The real value in penetration testing is using the information learned from one device to take control of another. The tester must follow the trail and use the clues provided to eventually gain access to the really important and sensitive data.

Examples of sensitive data often discovered during penetration tests include payroll data, employee information, client data and financial data. Much of the information found during such tests present privacy issues that need to be addressed.

Compliance and security employees are often asking for such tests to be performed because they need to know the current security posture, whether it is to satisfy a legal or privacy requirement such as HIPAA or SOX or because of a previous data breach.

The Audit department can use the results of a penetration test to help define security and privacy policies or to give upper management the ammunition they sometimes need in order to enforce such policies.

The Legal department should welcome penetration tests since they prove “due diligence” on the part of the organization.

Performing a penetration test does not guarantee an organization will not have a security breach resulting in a privacy violation, but if such a breach occurs at least the management team can point to the testing as proof of their due diligence.

Management needs to be able to prove that they are sincere in their desire to limit the possibility of a violation of any privacy laws that could result from lax IT security. That is, of course, if they perform the required remediation after the tests are complete.

Privacy and security concerns are often disjoint in many organizations because the responsibility for each often lies in separate departments.

Information Security is typically a component of IT while Privacy is often in Compliance or Legal departments. While they can greatly impact each other, their legacy is to be kept separate.

In the world in which we find ourselves today the new trend is to recognize the impact they have on each other and begin to blend the functions of Security, Compliance and Privacy.

This blending offers a very tight synergy and can allow for economies of scale unavailable in the current management structures.

Penetration testing is also appropriate for measuring the effectiveness of existing IT security and privacy controls, policies and procedures. The tests can focus on specific applications, operating systems, departments or physical locations.

The security and privacy controls, including access controls such as wireless and dial-in authentication, application controls such as passwords and authentication tokens, and physical security controls such as badges and biometric controls should be thoroughly tested.

If an organization has a dedicated Information Security department, the results of a penetration test can be used to help garner support for existing security policies that may not be stringently enforced.

The results of penetration testing can also be used to institute new security and privacy policies. Many of the controls mentioned previously are crucial in meeting privacy requirements.

With the growing number of identity theft cases comes a higher level of responsibility on the part of the organizations holding sensitive data.

Proper implementation and monitoring of privacy controls is essential to ensuring that organizations can safely store and manage sensitive information.

I have seen many cases where a security audit where sensitive data was found has been used to help the security or privacy personnel implement sweeping changes in current policies.

Some of the many reasons that have been voiced over the years for not performing a penetration test include:

  • “We already know where everything is broken”.

  • “If you tell us what’s wrong, we’ll have to fix it”.

  • “We don’t have anything that hackers want”.

  • “We’re too small to matter”.

  • “We haven’t fixed the things you found broken last time.”

  • “Our employees don’t know how to do bad things.”

Information Technology security and privacy vendors add some amount of Fear, Uncertainty and Doubt (FUD) [5] to the decision-making process.

The thought is that if you scare clients enough they will spend money on your products and services. This tactic may have worked 5-10 years ago but not today.

With the amount of security information available on the Internet it is hard to bluff your way into a client’s wallet.

In reality, FUD will usually deter a client from spending money instead of encouraging them.

Companies today want honest, straightforward advice on the best and most economical solutions to help them meet their security and privacy concerns.

While there aren’t right and wrong responses to each of the objections specified earlier, I certainly feel there are more and less appropriate responses.

One appropriate response is to remind the client of their obligation to protect the sensitive information they possess on their employees, clients and customers.

There are many privacy concerns relating to employee information that need to be addressed. Simply hoping that your employees or contractors are honest and wouldn’t try and access unauthorized information is not enough.

Each organization has some responsibility to implement appropriate security and privacy controls and to periodically test those controls.

Where appropriate, an appropriate and effective response is to help the client understand that security and privacy compliance is often mandated by state or Federal law.

It is unfortunate but true that some organizations would not otherwise provide a sufficient level of information security unless required so by law.

Given the many different statutes that are in effect today it is hard to imagine having to explain to a company why these privacy regulations are needed.

It is important to convince that complying with privacy regulations makes sense for reasons other than simply complying with existing laws.

Compliance is good because in the long run it saves the company time, money and reputation.

Employee lawsuits due to privacy violations cost companies millions of dollars each year and often results in employees and customers losing respect in the integrity of the company.

The effects of privacy and security violations are seen in the news each week, with companies receiving fines and bad publicity for each violation.

Some companies never fully recover from large security or privacy breaches.

Others will recover but carry that stigma for a long time and spend large amounts of money in advertising campaigns designed to bolster their corporate reputation.

When performing penetration tests for a client this low hanging fruit (LHF) is the most obvious target. Why is this? Simply put, testing time = dollars. Clients are always looking for the most benefit from each dollar spent.

As a business owner, would you rather spend $5,000 to find a web server vulnerability that could only be exploited by two hackers on the planet or to know that your administrator password is easily guessed and could be exploited by 30 million people?

Some specific examples of LHF found by the author include the following:

  • 1. Blank, default or easily guessed database passwords. [10,11,12]

  • 2. Common passwords across different platforms and/or architectures.

  • 3. Default or easily guessed passwords on infrastructure devices.

  • 4. Lack of proper physical security for servers and other network infrastructure devices.

  • 5. Laptops without full-disk encryption.

  • 6. Obvious SQL Injection issues in web applications. [13]

  • 7. Missing patches on servers and desktops.

  • 8. Remote control/access programs that don’t require passwords.

  • 9. Sensitive configuration data stored or sent via email without encryption.

  • 10. Insecure wireless access points.

For the majority of clients in most vertical markets, testing for LHF provides the best bang for the buck. Given an unlimited budget every penetration tester would be happy to spend months testing for every possible vulnerability in all network devices.

Unfortunately this option rarely presents itself in today’s world. Budgets are tight and timetables are short. Given the frequency of new vulnerabilities and the easy availability of the tools necessary to exploit them, even testing everything would only be viable for a short amount of time.

Security auditing needs to be thought of as a wheel that never ends or a goal that is never quite achieved. There are no 100% guarantees in the field of IT Security so testing is one way to ensure that security and privacy controls are constantly being tested.

So what does LHF look like in the real world? They seem to cluster around three common areas. It doesn’t matter if the client is a local grocery store, a Fortune 500 retail establishment, a Federal government agency or a pharmaceutical plant.

Before listing these three areas it needs to be said that these three areas show up consistently during internal testing only. Externally, the major issues revolve around insecure wireless access, improperly configured firewall devices and application security.

The three areas that consistently show up during internal penetration tests as LHF are the following, which the author refers to as the 3 P’s of Penetration Testing:

  • 1. Passwords

  • 2. Patch Management

  • 3. Policies and Procedures

Hopefully if you’re still reading you agree that penetration testing is a necessary undertaking.

Debate continues on whether internal or external testing is more important as well as the frequency of testing. But most security and privacy advocates agree that periodic security audits need to be performed.

Some clients alternate internal and external testing on a yearly basis. Others perform external tests on a more frequent basis such as quarterly or semi-annually.

Some clients train their internal IT staff to perform the tests while others only use external resources to keep the separation of duties clear.

Much has been written about the rising tide of internal threats and from my own experience I can certainly say this is true.

There was a time years ago when external threats were the main concern. During this time firewalls and other security devices had arcane syntax and were often hard to configure and manage.

Today, modern firewalls have rich GUI command interfaces and software wizards that greatly reduce the amount of knowledge that security technicians need to properly configure such devices.

Between the advances in firewall technology, the increasing use of anti-virus and anti-malware software at the perimeter and an increasing awareness of internal threats the overall security posture for many organizations has greatly increased.

But, much still needs to be done to ensure that all organizations, both regulated and non-regulated, put forth the due diligence to ensure privacy and security concerns are being met.

Once you’ve decided that penetration testing is a good thing, how do you go about doing it?

One option is to outsource the whole process to a reputable security vendor. This option is appealing because it makes the whole process nice and neat and keeps the internal auditors very happy.

Auditing best practices generally prefer that outside consultants perform such tests since there is a clear separation of duties and the chance for conflicts of interest are eliminated.

However, it is perfectly acceptable for internal IT staff to perform tests throughout the year and then have an external consultant perform the tests for official compliance reporting.

This way the cost of the external consultant is reduced since most of the issues would have already been found and resolved.

If you do choose to outsource it never hurts to understand some of the process and terminology just to make sure the vendor you choose is using an acceptable methodology and that the results are sufficiently documented to allow you to remediate the issues.

If you choose to do the work using your own IT staff, the first step is to select an acceptable methodology.

There are many different methodology documents in use today [6,7] and they all basically attempt to ensure that all areas of network infrastructure devices are properly tested.

Some of the more popular ones have been submitted by the Center for Internet Security (CIS), NIST, CIA, OSSIM and COBIT.

Some are more structured and rigid than others and you will have to examine them for yourself and find the one with which you are most comfortable.

There is no right or wrong answers in choosing a methodology. The main decision factor should be your comfort level and a solid understanding of the techniques employed in the document.

The next consideration is tools and training [8,9]. There are two schools of thought concerning tools and training.

The first school says go to training first and then start learning the tools taught in class.

The second school says to spend time learning the tools and then go to training. The goal of the second school of thought is to allow you to fine tune your skills since you will already have a familiarity with the tools discussed in class.

Again, this decision is a personal one and will differ from person to person.

The choice of tools is a very crucial component of any good penetration tester’s arsenal. When comparing tools look for those that provide security and privacy reporting options.

Many tools have report templates for common regulatory requirements such as HIPAA, SOX and PCI.

Most professionals performing penetration tests will have well over a 100 tools designed to test a wide variety of operating systems, applications and infrastructure devices.

When running tools during a test, one suggestion is to always test any given device with several tools and never trust one tool too much. Another consideration is what devices will be tested and how often.

Generally, it is best to test all devices connected to your network on at least an annual basis.

Categories of Vulnerabilities

The category of passwords includes all forms of passwords and similar authentication schemes.

They take the form of default application passwords, missing, blank and easily guessed passwords on operation system accounts and other password uses such as SNMP community strings.

Another common area of password weaknesses is cases where administrators use similar passwords across different platforms.

In other words, this becomes a problem when network administrators use the same password for their Microsoft Windows account, the Oracle “system” account and the Cisco administrative account.

Patch management for desktop PC’s and servers always seems to be an issue even in organizations that have robust patch management applications and policies already in place.

It is not uncommon to find missing patches from vulnerabilities that were announced three or four years ago. The implications of missing patches on security and privacy cannot be overstated.

Missing patches accounts for a very large percentage of successful network attacks.

Information Technology policy and procedures are often the bane of a network administrator.

Next to documenting network topologies and device configurations, policies and procedures are often the IT stepchild and receive the least amount of effort.

Nobody likes to write them and few people read them. But they are critical to the overall success of any information security and privacy plan and should drive the configuration of all security devices.

There are many reasons why organizations don’t have current IT policy and procedure documents. The first reason is that it takes a lot of time and managers don’t often get evaluated on such projects.

Metrics are developed to measure and reward for successful network implementations, short times for help desk users and great call qualities for the new VoIP implementation.

Few corporate leaders are going to reward IT managers for well-written policy documents.

Another reason for not having accurate policy documents is that often the person writing them has no authority to enforce them.

Despite all of these reasons, IT managers need to work together with human resources, legal and compliance personnel to convince top management of the need for current, accurate policies and procedures.

Well written documentation is the key to an effective management strategy and in the long run will help save the company money by ensuring a consistent process for each management task.

Consistent procedure documents also reduce the time spent training new employees which also helps to save money.

Finally, accurate documentation is also a key component of most security and privacy regulations.

It is my hope that this series of articles have successfully made the case for performing regularly scheduled penetration tests.

When combined with enforceable policies and procedures such tests can be an invaluable asset to any organization.

The question of “enforceable” is usually illustrated by an organizations password policy. The security officer might write a policy indicating a minimum password length of 8 characters.

However, the employees might complain that the password is too long and hard to remember. Ultimately the password policy is changed to something smaller, say 5 characters.

This effectively reduces the overall security and privacy benefits of having strong password policies.

One caution regarding penetration testing is to remember that penetration testing is not a magic bullet. It will not detect all problems in your networks and applications, especially when it involves custom code.

By searching for and finding the LHF in your organization, you are taking a major step in securing the information that gives value to your company.

From a privacy perspective, removing the LHF is one component of ensuring that sensitive data is not available by unauthorized users.

Increasing the overall security posture by eliminating LHF will provide management with confidence that their privacy concerns are being addressed and will help reinforce the notion that security and privacy are inextricably intertwined.

Regardless of how and when penetration testing is performed, none of the tests will be beneficial if the proper remediation steps are not completed.

Remember the goal is not just to fix what is broken but rather to incorporate the findings into long-term policies and procedures that will help to ensure that the issues found will not be recreated at some point in the future.

Business owners do not want to pay for annual tests and continue to find the same issues year after year. Take the results of the tests and use them to refine your IT practices so that each year the list of vulnerabilities continues to decrease.

You may never see that list reduced to zero but the real business value comes from the pursuit.

References

[1] http://en.wikipedia.org/wiki/Penetration testing

[2] Kevin Beaver, “Outsourcing security testing: What’s right for you?”, October 2004.http://searchcio-midmarket.techtarget.com/news/column/0,294698,sid183_gci1018599,00.html#

[3] http://en.wikipedia.org/wiki/Tiger_team

[4] PCI DSS Standards – https://www.pcisecuritystandards.org/

[5] Roger Irvin, “What is FUD?”, 1998. http://www.cavcomp.demon.co.uk/halloween/fuddef.html

[6] Stuart McClure, Joel Scambray, George Kurtz, “Hacking Exposed: Fifth Edition”, McGraw Hill, 2005.

[7] ISECOM: http://www.isecom.org/

[8] SANS: http://www.sans.org

[9] Foundstone: http://www.foundstone.com/us/education-overview.asp

[10] http://dev.mysql.com/doc/refman/5.0/en/default-privileges.html

[11] http://support.microsoft.com/kb/313418

[12] http://download.oracle.com/docs/cd/B10501_01/win.920/a95490/username.htm

[13] http://www.securiteam.com/securityreviews/5DP0N1P76E.html

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s