Pratum Blog

Cybersecurity in 60 Webinar: How to Get the Most Out of a Penetration Test Highlights

Performing regular penetration tests is an easy decision. They represent a key piece of your overall security strategy. But getting the most from your next penetration test can be more challenging as you sort through multiple questions. How do you choose the best penetration test vendor? How do you decide what to test? Why do quotes from different vendors vary so much?

All these key topics came up during Pratum’s latest Cybersecurity in 60 webinar. Pratum Senior Penetration Tester Jason Moulder and Troy University CTO Greg Price shared insights from the perspectives of a tester and a client on how to make the most of a penetration test. Here are the highlights of their conversation. To view the entire webinar, click here.

Pen Testing Client Greg Price, CTO, Troy University
Greg Price
CTO, Troy University
Pratum Senior Pen Tester Jason Moulder
Jason Moulder
Senior Penetration Tester, Pratum

Q:

What should everyone know before they start a penetration test?

Jason:

First, make sure that you’re getting an actual penetration test and not just a vulnerability scan. (This infographic shows all the elements that go into a full penetration test.)

Second, do your homework on the penetration testing company you’re thinking of using. What kind of credentials do the actual testers have? How many years of experience do they have? What are people saying about them online? You should look for a long-term partnership, not just one-and-done things.

Greg:

It seems like someone calls me every day who is hanging out their shingle as a cybersecurity expert. I’m always dubious of those claims, especially if the organization appears overnight. So the maturity of the organization we’re going to work with is of enormous interest for me.


Q:

So what’s the difference between a vuln scan and a penetration test?

Greg:

A penetration test is predicated on a vuln scan. Any penetration testing professional has to know the lay of the landscape, which is where a vuln scan comes into play by knocking on the door, running various scans to see what’s forward facing for the Internet to take a peek at it.

The penetration test provides me greater insight into those vulnerabilities. It shows where gaps are not only from a technical perspective, but from a policy perspective. It provides a practical application of how my team is working, what’s going on with our resources.

Jason:

Keep in mind that a vuln scan is only programmed to find things that are known. (Click here for a full comparison of penetration tests and vuln scans.)


Q:

How do you set effective rules of engagement for the test?

Greg:

You can get stealthy with a penetration test or get loud and bang on the doors and hope somebody’s paying attention. If the rules are not laid out clearly, those doing the work can get too noisy and too rough and disrupt the environment, and that can be an absolute disaster.

We’ve used groups in the past that completely ignored the rules of engagement. If they found something, they would take it all the way down. That’s an awful experience for an organization of any size, but especially for us with a global operation and students engaged in various educational opportunities.

Jason:

That’s also an issue when it comes to automated tests like vuln scans. If the team isn’t coordinating with the client and saying what they’re going to be doing at a certain time, you can mess up all kinds of things such as rewriting databases, deleting things, and creating other unintended types of consequences.

Greg:

I don’t want a penetration test to turn into a test of my disaster recovery (DR) plan.


Q:

How do you set the proper scope for a penetration test?

Jason:

We identify components that would seriously affect you and everybody connected to you if they got compromised. I try to work with clients to keep the cost manageable while giving you what you actually need. We’ll guide you on what we see with other clients in the same industry, threat intelligence we’re getting and other things.

Greg:

As the customer, I should have some idea of where my weaknesses are, what I want to build on, where I want to strengthen the environment. If you’re not focused and looking at what’s vital to your organization, you could waste a lot of money just wandering around the edges and poking at things that are trivial. Also, be sure that you know how cloud and third-party components are managed before starting a penetration test.

So when you walk into a penetration test scoping call, you have to know what’s of great value and what needs to be protected from a corporate strategy perspective, a regulatory need, or a compliance need.

Take a good look at your DR plan. What are you looking at reconstituting if you have an enormous failure of your primary data operations? That’s probably the template for what you want to put in front of someone to do a penetration test against.


Q:

How often should you do a penetration test?

Jason:

If you have some underlying regulation that says you have to do at least two penetration tests a year, then you can’t really bypass that. But on average, if you don’t have anything really pushing you to do this more often, you should do a full penetration test at least once a year on your entire environment: external, internal, wireless.

Greg:

If you have experienced some massive shift in the infrastructure, introduced some product, exchanged some hardware, or done something else sizable, then it’s time to have someone come in and go after it and make sure it’s living up to expectations from a security perspective.


Q:

Should you tell your IT team when a penetration test is going on?

Greg:

I don’t tell anybody within my organization. I want it to be a test of our controls and tools, but I also want to see that the team reacts appropriately and that the various mechanisms we have in place for mitigation and triage are also functioning.

Jason:

I would rather see a team doing what they’re supposed to be doing. If it gets up to the CTO’s level, he can stop it there rather than going into the IR plan. We may purposefully fire off some real heavy stuff to see if we get shut down.


Q:

What’s your advice for organizations early in their security journey who might be choosing between things like a penetration test and risk assessment?

Jason:

First, make sure you’ve prepared by getting controls in place, mitigating vulnerabilities and patching software before you do a penetration test. Then you can engage a vendor to come in and do an audit or a risk assessment. When you get that report on paper, then the penetration test is there to quantify that.

Greg:

You don’t want to roll right out of the gate with having just turned on some new things and hired a couple of folks to work security and then bring in a penetration test group to examine what’s going on. That’s not going to be a good engagement for anybody. Use the penetration test as an opportunity for improvement. For me, it’s definitely a verification and validating tool.


Q:

The final report from a penetration test can be overwhelming. How do you react to findings and not take it defensively?

Jason:

We’re not trying to say you’re doing a bad job. We’re showing where you need to invest in training or shore things up. We hope that part of our result is to create a driving factor that shows your boss you need to reinvest into your overall scheme and hone the team’s skills a little more.

Greg:

I like to use the final report as a team-building exercise. We focus on the end goal of being better after we complete the exercise. If we got a report that proclaimed that we had absolutely nothing going on and everything was perfect, I would be skeptical.

Jason:

Some of the low-risk or informational findings could be the segue into a bigger finding when you chain that stuff together, and we identify that during the engagement.

Greg:

That shows the importance of people who have experience and actual experts to conduct these tests. Without that knowledge of the penetration tester to assemble those things, you may think it’s no big deal. But when it’s brought into context by people who have a lot of experience, that’s where the value really comes out in these types of examinations.


Q:

Prices on penetration tests diverge widely. What are key things to look at when comparing quotes?

Greg:

I typically look at the penetration testing team’s experience and their approach. We also review whether the tools they use are inhouse or open source or commercial.

Jason:

Take a hard look at why a lower price is lower. Sometimes we come in a lot lower than competitors because we cut out a bunch of stuff that you said you wanted, but doesn’t make sense for your objective. We want to focus in on your overall objectives and goals and why you need this penetration test to begin with. We don’t have to test everything in the environment. It's not cost-effective.


To talk with Pratum’s team about how can get the most value from your next penetration test, contact us today.

Information Security leader training employees about security awareness

If you work in the IT world or deal with information security on a regular basis, you’ll hear people talking about “security awareness training.” The term can be confusing because awareness and training are not the same thing. Generating awareness of something is distinctly different than the act of training. Awareness is about the learner receiving information from the teacher. Training is an active, engaged process in which the learner builds meaningful knowledge and skills that facilitate action.

To adequately train your team in cybersecurity, think of learning as a continuum. It starts with awareness, builds to training, and can evolve into education for those making a career out of information security. Building on concepts from the National Institute of Standards and Technology (NIST), this article highlights the IT Security Learning Continuum and covers both the differences and links among awareness, training and education.

NIST - Figure 2-1: The IT Security Learning Continuum
NIST's IT Learning Continuum

Security Awareness

Awareness refers to having knowledge of a situation or fact. According to NIST’s glossary of terms, “Awareness is not training. The purpose of awareness presentations is simply to focus attention on security. Awareness presentations are intended to allow individuals to recognize IT security concerns and respond accordingly.” Examples of awareness activities include anti-phishing posters placed in common areas; discussions of stronger passwords at staff meetings; or informational videos distributed via email.

It's critical to build your security training program on a strong foundation of awareness. The only way we can expect teams to innately understand existing risks, let alone react to them, is to give them guidance. That guidance begins on an employee's first day by including cybersecurity awareness as a required part of the initial onboarding process

For example, NIST uses the example of building an awareness session (or awareness materials you distribute) around virus protection. You can address the subject simply and briefly by describing what a virus is, what can happen if a virus infects a user’s system, what the user should do to protect the system, and what the user should do if a virus is discovered.

NIST’s guide to IT security training requirements (known as SP 800-16) describes a transition stage between awareness and training called Security Basics and Literacy. At this stage, users learn a core set of terms, topics, and concepts. During the literacy stage, information is not tied to specific tools or systems. Literacy delivers basic concepts so that users can move on to more robust training programs, and it prioritizes personal responsibility and behavioral change.

Security Training

NIST SP 800-16 defines training as the part of the continuum that “strives to produce relevant and needed security skills and competencies by practitioners of functional specialties other than IT security (e.g., management, systems design and development, acquisition, auditing).” The most significant difference between awareness and training is that awareness seeks to focus an individual’s attention on an issue or set of issues, while training seeks to teach skills that allow a person to perform a specific function.

Awareness is a basic necessity, but training is the difference maker when it comes to truly safeguarding an organization’s sensitive information. And delivering information security training one time per year is simply not enough. You should plan to spread awareness and training activities across the year to provide greater persistence. Because cyber threats are constantly changing, the awareness and training program must be agile enough to provide information regarding the latest threats.

Security Education

NIST SP 800-16 defines education as the realm of people seeking a career in security. NIST says, “The ‘Education’ level integrates all of the security skills and competencies of the various functional specialties into a common body of knowledge, adds a multidisciplinary study of concepts, issues, and principles (technological and social), and strives to produce IT security specialists and professionals capable of vision and pro-active response.” Education goes beyond basic security courses and training. In NIST’s view, education is accomplished through a degree program at a college, university, or other educational forum.

You don’t need to give everyone a formal security education to establish a successful security program. Awareness and training, however, are integral to a security-minded business culture.

Pratum’s team can help you create an awareness and training program tailored to your team’s specific needs. To get started on your program, contact us today.

Incident Response vs. Disaster Recovery vs. Business Continuity

In a world getting less predictable every week, good business leaders proactively prepare for cyber incidents with plans that anticipate and minimize disruptions. But as you start looking ahead, it’s easy to get confused about the differences between incident response plans, disaster recovery plans and business continuity plans. In this post, we’ll explain how the plans all weave together into a holistic strategy to protect your business.

Incident Response Plan

The IR plan is the overarching document that gives your team clear guidance on exactly what to do during incidents, data breaches, and other pressure-packed situations when it’s easy to get overwhelmed. If you realize you may be facing a cybersecurity incident, the IR plan will help direct your actions. Every good cybersecurity program puts a high priority on writing and regularly reviewing an IR plan. In many cases, you may be required to have one by industry regulators, your cyber insurance company, key customers who want assurance that you can handle incidents, etc.

Your IR plan will describe your specific:

  • Definition of an incident – A clear checklist helps your team recognize situations serious enough to set the IR plan in motion. The plan also should include criteria for identifying the next stage: an actual disaster that triggers the disaster recovery/business continuity (DR/BC) plan.
  • IR team structure with each person’s responsibilities – This list ensures you have the right voices in the room. It’s easy, for example, to include a lot of IT people and forget to include reps from HR, legal, PR, etc. Be sure to include an executive who can make things happen in a pinch. For each person, clearly describe what they’ll do during an incident.
  • Procedure for reporting incidents – The plan works only if the right people learn about the incident in a timely manner. Clearly explain how team members should report suspected incidents through the right chain of communication.
  • Guidelines for talking to outside parties – When do you tell your customers what happened? Who is allowed to talk to the media if they call? Your plan should anticipate those scenarios and describe what to do.
  • Structure for summarizing lessons learned – Create a method for debriefing the incident, clearly stating what happened and making adjustments as required.

Disaster Recovery

Note that many organizations combine the DR and BC plans into a single document that outlines the processes involved for declaring a disaster, the formulation of the Response Team Members, the processes necessary for a secure recovery, and finally the steps necessary to maintain the continuity of business operations. We’ll explain the differences in the documents here, but rather than fixating on rigid definitions, just make sure you have thorough plans in place.

The DR plan usually centers specifically on data and technology operations with processes for recovering information systems at an alternate facility in response to a major hardware or software failure or destruction of facilities. The DR plan explains, for example, how you can restore lost data, whether that means restoring a single system or an entire data center.

The DR plan will include details such as recovery time objectives (RTOs) and recovery point objectives (RPOs). These define, respectively, how long you can function without a service and how current the data must be when you restore it. For example, RPOs may tell you that restoring copies of training materials from 48 hours ago isn’t a problem. But if your business runs on current stock market trading data, the RPO will show that you need data to be current within a few minutes.

Business Continuity Plan

The BC plan describes how you’ll maintain operations during and after a significant disruption or an incident. The BC plan should include a triage process for restoring the most essential operations first, such as filling customer orders, making payroll, supporting business partners, etc.

Your BC plan will explain how you can maintain operations in situations such as:

  • Encryption of your data by hackers
  • Loss of power to your facility
  • Failure of a supplier to deliver key materials
  • Natural disasters

The BC plan rests on the foundations of an overall information technology risk assessment and a business impact analysis (BIA). The BIA specifically identifies potential operational implications of various scenarios. What happens to your business if, for example, you lose access to a certain database or cloud-based software? How long could you withstand such an outage without major damage to your business? In a BIA, you’ll seek to put an actual financial cost on various interruptions so that you can make informed investments in prevention and mitigation strategies described in your BC plan.

Essentials for Every Plan

For all three of the plans described in this post, be sure to include these key elements:

  • A designated point of contact (POC) and a leader charged with heading up the effort in a specific area. Many compliance frameworks and private contracts require you to name your POC.
  • A schedule for updating the plan. Many companies are sitting on plans that have never been revised to reflect a remote workforce, reliance on cloud-based services, etc. Commit to an annual review of the plan and update it to reflect the realities of your operations.
  • A schedule for testing the plan. At the simplest level, you should do at least annual tabletop exercises. But you may determine that your situation requires more extensive testing.

For help assessing your specific business risks and making a plan to mitigate them, contact Pratum today.

The information we track while users are on our websites helps us analyze site traffic, optimize site performance, improve our services, and identify new products and services of interest to our users. To learn more please see our Privacy Policy.