Let's start this post on a happy note: You have been promoted. You are now in charge of cyber security for your entire organization. Congratulations. The birds are singing. It's a nice spring day outside. The executive washroom -- if there are still such things -- is now available to you. Most importantly, there are no issues that you know of in your enterprise IT network.

But in the back of your mind, there's probably a small worry creeping in. "How can you be sure?" it queries.  "How do you know your network perimeter defenses are doing their job?" You have spent a fortune on Intrusion Detection Systems and firewalls and routers and anti-virus products and data log analyzers and have probably been responsible - single handedly - for meeting various software and hardware sales rep quotas. Yes, you have some of the latest and shiniest  products the cyber security marketplace has to offer.

But, the voice persists, is my enterprise truly safe?

This is where penetration testing (pen testing, for short) comes in. Regardless of the size of your enterprise, or the number of assets, if you can be damaged by an intrusion -- and that means everyone -- you should be penetrating testing. 

Why Attack Yourself?

There's no better way to determine if you have adequate cyber defenses than by emulating an attacker. One of the advantages of using third party experts in a specialized IT domain such as this is that pen testers know about and look to exploit the latest vulnerabilities,seeking to compromise defenses as an attacker would. In addition, they possess a toolkit of prior exploits that have been successful, allowing organizations to prove to themselves they have adequate cyber hygiene in place. With software vulnerabilities increasing as new software is rolled out and installed it becomes more important than ever to not only test for new issues, but to defend against old ones as well.

Understanding Pen Testing

Penetration testing (‘pen’ testing for short) is an integral component of a comprehensive cyber security assessment for any organization – be it a commercial venture, a federal agency or a DoD military unit. A pen test probes a computer system with the intention of identifying and quantifying vulnerabilities that could be exploited by an adversary. 

This can be done as a white box test (where the tester has full supporting system information and documentation) or a black box test (where no prior information is provided). Grey box testing is between the two extremes and is done by providing some data to the pen testing team.

  Where Pen Testing Began

Pen testing is a modern response to security concerns that have existed since the advent of computer time sharing systems in the 1960s. At the time, computing resources were particularly expensive and initial concerns were for proper billing and accounting to be in place. A natural outgrowth of that was preventing unauthorized access by other system users.

In fact, one of the first security conferences was held in 1965 when it was reported that a defense contractor was easily able to circumvent system access mechanisms that were supposedly in place. Subsequent study by the RAND Corporation and others included the phrase ‘penetration’ to describe just such a computer attack.

The DoD convened a task force in 1967 to formally assess this emerging threat.  Both military and industry security experts then began studying the issue and building operationally focused teams. Groups of uniquely skilled testers were organized into ‘tiger’ teams who conducted the actual first known instances of penetration tests. Reports are that given little adequate protections in place, these teams were quite successful. Since these were the early days in online computing however, ‘data breaches’ were not yet in the vernacular and moreover, a limited amount of crucial data was even available online.

Conducting formal pen tests has continued to mature in sophistication up to the present day with open source tools becoming widely available leading to enhanced capabilities not even requiring coding skills. As the nature of computing changed, so did the nature of the attack methods. The internet enabled a proliferation of web applications providing user friendly access to back end databases. Web application form attacks have been noted as far back as 1998 and more recent techniques have included such things as SQL injection, web application data fuzzing (trying non-standard data inputs) and more recently exploiting the latest uncovered Java vulnerabilities. Current industry best practices dictate that security must be integrated into the software development lifecycle and ALL developers are expected to have at least a rudimentary knowledge of pen testing techniques and building code resistant to such attacks.

The OWASP (Open Web Application Security Project) has emerged as a leading industry voice and has a 224 page testing guide available which details testing frameworks and details on specific software vulnerabilities. In the hands of experienced pen testers, information such as this is gold in constructing a comprehensive set of test conditions and scenarios.

(Grey box testing can be of particular use if an organization is worried about a specific threat type or simply wants the pen testers to focus on particular system aspects.  For instance a network map with device manufacturer and type may be provided to allow for scanning for default passwords.  This shortens data discovery steps and allows a pen tester to more quickly act like a trusted insider seeking key data items.)

Rules of Engagement

No matter how the pen testing is defined, explicit ‘rules of engagement’ should be formally be put in place before the project commences. This is a series of requirements that specify how the tester is supposed to respond in a particular situation. It defines the scope and comprehensiveness of the testing activities.

There may also be an accompanying set of general principles such as ‘a tester is not to cause any intentional damage to the test target system’.  Another might be ‘no data is to be removed from the test target system’.

IT operations personnel are typically informed of the activities to prevent unanticipated defensive reactions that might impact operations.  Some ‘lights out’ tests may go so far as to keep IT operations personnel uninformed of the ongoing testing activities, but even then senior personnel are usually informed.

Organizational Security Policies are the foundation to establish the extent and specific activities of the pen test team.  Adherence to these policies by organization personnel should be tested as well as IT network defenses.  Do end users actually know and follow these policies? Does the IT staff have policies that control items such as patch management, conducting vulnerability scans and security log creation, storage and archival? A checklist against sound information security best practices or a minimum set of security controls can also be applied.

Acceptable test techniques can also be detailed. For instance, phishing attacks against system users may be implemented to determine if users follow organizational policies on e-mail and attachments, usage of USB stick memory devices and file transfers outside the corporate network. As mentioned, having IT personnel informed of the testing can prevent unanticipated test reactions. For instance, keep help desk personnel informed if the intent is to test users, but do not keep them informed if their response actions are intended as part of the testing process.

Since the ultimate intent of a pen test is to reduce risk and strengthen defenses, it is often helpful to have a sample test report available for the target organization included in the project requirements. This report typically includes a comprehensive summary of the activities conducted. Using a sample template up front clarifies the exact information the organization will receive at the end of the test. Often security gaps are identified in a priority order so an organization can apply timeline and budget factors against the gaps as needed to reduce risk to acceptable levels.

It can become a conflict of interest if the same contractor conducting the pen tests is used to perform the security gap mitigation. Typically, pen test activities result in a report being generated and actually fixing the gaps is considered a separate project. At all times the organization should be in control of their IT infrastructure and should not experience any operational surprises. 

In addition, having differing perspectives provided by multiple groups can lead to higher quality results. An overall sequence of activities can be 1) conduct pen test, 2) mitigate identified security gaps, 3) conduct subsequent pen test to evaluate previous fixes and probe for new gaps. This process can be repeated as time and budget allows, enabling a continuous security improvement process.

About the Author

Robert J. Michalsky has served government and commercial customers for more than 30 years. As NJVC Principal, Cyber Security, he quantifies and pursues new business opportunities in cyber security. Mr. Michalsky spent more than 15 years providing cyber security-related IT engineering services for classified Intelligence Community and Department of Defense customers. Read More | Contact Us