Tag Archives: Penetration Testing

Posted on by

The Importance of Letting the Penetration Tester Test

Have you ever had a penetration tester ask permission to execute an attack or perform some other action?  You should have, because we would prefer to do that rather than just try that “risky” exploit or make the configuration change.  To be clear, most penetration testers don’t go rogue.  If the company that does your assessments is doing these types of actions without checking with you first, it’s time to reconsider who you are contracting for your assessments.

Continue reading →

Comment on this post
Posted on by

Penetration Testing: Choose Wisely for IT Security

When selecting a Penetration Testing Company for your IT Security program needs, there are certain things you’ll want to ensure your consulting firm has, is involved in, does and can handle. 

To begin, you’ll want nationally renowned ethical hackers on the team. The team should regularly present at national and international security conferences, including: Defcon, ShmooCon, OWASP, and Black Hat.

The firm should employ a team-based approach to performing penetration tests.  This ensures a wide range of skills and expertise is brought to bear when performing a penetration test.

The firm should also have forensics experts on staff and get debriefed after every incident to ensure the techniques used by the team match the attacks that are being seen in the wild.

During the test it helps if they can explain all the tools, techniques and attacks that are being utilized. This provides an excellent opportunity for you to increase your knowledge and gain a deeper understanding of the vulnerabilities discovered.

It is always good if the firm does not sell products, which enables you to get the best recommendations, which can oftentimes include free solutions. This ethically independent opinion is crucial, even with the so-called “labs” from product vendors or resellers that are seemingly separate.

The team should have developed proprietary toolsets to speed the process of a penetration test without sacrificing quality.  In addition, they should create their own exploits and have a history of publishing those exploits out to the community. 

They should be able to offer vulnerability and penetration testing standards and metrics development when creating a program to review Penetration Test results.  Without putting data into a standardized form, it is impossible to compare multiple tests or develop meaningful trending.

If you’re really looking to separate the premium firms, ask them to map controls tested back to a framework or regulation. This not only identifies potential vulnerabilities, it looks at maturity and risk within your security program and gives executives specific controls to work on vs. the standard “there are problems” approach.

 

Comment on this post
Posted on by

PCI DSS and Penetration Testing

At times it can be frustrating when the PCI DSS lacks clarity on certain requirements, though it is generally very prescriptive in nature. It creates problems for both the QSA and the client who can and will disagree with interpretation. This is especially true when it comes to penetration testing. The requirement states:

11.3 Perform penetration testing at least once a year and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment). These penetration tests must include the following – network layer and application layer.

Now the first concern is that other requirements of the PCI DSS, such as 11.2 for vulnerability scanning, clearly distinguish where it should be performed (internal and external networks). Now generally, penetration tests are done externally. But the standard, when not specific, is supposed to have an understood “… as it applies to PCI data” in each requirement. So perhaps the penetration test should be on the PCI network. But from a risk perspective, would’t it be best to determine how might someone break in from the internal corporate network to the PCI network? As a QSA, I think any of them have to be acceptable.

Another concern lies in what a penetration test is. Other than the layers noted, it is’t really clear. Even there, I think it would be best to clarify the routing network versus the network operating system vs the operating system itself. All of these are distinct types of assets to attack. And as for the application layer, there is’t the same level of distinguishing between general applications and web applications, which are handled very differently within a pentest. Beyond these immediate symantics, there are many more nuances to what a pentest is that simply is’t defined or even referenced to some other body like OWASP for web application security.

But what bothers me the most about this requirement, is the lack of dictating who can perform a penetration test. PCI has done a great job establishing the ASV program to certify who can do a vulnerability scan. You’d think, at a minimum, that only ASV’s could do them given that penetration tests are sort of the PhD to the associates degree of vulnerability scanning. But to the previous point, there are a lot of people who can do scans. Very few are actually good at penetration testing. So the real goal should be to make an even higher standard and program for pentests.

With all that said, I am still a big fan of the PCI DSS. It really does outline a pretty darn good formula for a good, effective security program. And with each rewrite, the DSS does tend to improve and provide clarity. For example, when requirement 6.6 was added for web application review or web application firewall, they did clearly state that an organization that specializes in those types of assessments should be used. Could they at least say that for the penetration tests?

 

Comment on this post