Tag: Vuln Scan

  • How Much Should You Pay for a Penetration Test?

    “Even after 10 years as CEO of Raxis, I’m still amazed at the wildly different pricing attached to a vast and loose array of services broadly labeled as penetration tests. I know something is amiss when I see quotes range from $1,500 to $18,000 per week (and more) for what is ostensibly the same work.“

    Mark Puckett, Raxis CEO

    I understand and appreciate the confusion among companies large and small who need this essential service, but who have no good way of knowing whether they’re getting a bargain or being fleeced. That’s why, once again, I’m stepping in with a straightforward guide that I hope will be helpful to any business that needs to test its cyber defenses against professional, ethical hackers.

    Rules of Thumb
    • As with other professional services, the adage that you get what you pay for does hold true in penetration testing. A quote that’s a lot lower than reputable competitors is cause for skepticism, as is one that is substantially higher. Fortune 500 companies may well need multi-month testing that can cost $250,000 and more, but it’s unlikely smaller firms do.
    • There are some external factors that can affect the price of a penetration test – whether it’s conducted onsite or remotely, or whether it’s a remedial test. For the purposes of this guide, we’ll stick with just the testing itself.
    • The scope is everything. Be certain that what you discuss is exactly what you are getting for the price. Consider carefully what you’re trying to achieve. Are you serious about preventing hackers from hijacking your network, stealing your data, or holding it for ransom? That’s a different objective than simply checking a box to comply with laws or industry regulations.
    The Differentiators

    When you’re considering a company to perform a penetration test, there are three major factors you should take into account alongside cost. They are the skillsets of the pentesters who will actually be doing the work, the time they propose to spend doing it, and the methodology they will employ in the process. Reputable firms like Raxis will spend the time necessary upfront to make certain you know what to expect before you sign a contract.

    Skillsets

    Not all pentesters are the same, and the pricing should reflect that. For example, some testers are phenomenal at hacking Windows systems, but are not nearly as strong when it comes to Linux or mobile technology. Many environments have a mix of Linux, Windows, Android, iOS, Mac OS X, Cisco IOS, wireless networks, and others. Make certain that the team you select is well-versed in all the technologies you have in scope so they can perform a valid test.

    Earth with a question mark

    To reiterate, you should know exactly who will be doing the testing. Just because a company is based in the US does not mean that its testers are. Some firms cut costs by using un-credentialed, offshore teams to do their work. That may or may not be a cause for concern if it’s disclosed upfront. If it’s not, however, I would consider that a big red flag. 

    Time Dedicated to the Job

    The amount of time penetration testers spend on jobs can really vary, and that will influence the price. Some pentesters believe that a week, two weeks, or even months are required to get a comprehensive test completed on your network. There are no hard and fast rules here, but the time should be proportional to the challenge.

    If you’re quoted anything less than a week, I would hope that it’s an extremely small scope of just a handful of IPs with a few services running on them. Otherwise, I’d be skeptical. The key here is to make sure the time spent on the job makes sense with what is in your scope. Also, remember to factor in complexity. For example, a single IP with a large customer facing web portal with 10 user roles will take a lot more time than 250 IP addresses that only respond to ping.

    Interestingly, I’ve heard that some of our competition is taking a week or more to quote the job.  I don’t understand the reasoning behind delays during the sales process, but I certainly recommend taking that into account when you make your decision.

    Methodology

    There are a few different ways to conduct penetration tests. I’ve broken them down into three types for reference.

    • Type A – The “Breach and Reach”: This type of test starts with the low hanging fruit and gains access as quickly as possible, just as a malicious hacker would. The goal is then to pivot, gain additional access to other systems, ensure retention of the foothold, and finally exfiltrate data. This is a true penetration test and demonstrates exactly what would happen in the event of a real-world breach. Some companies call this a “deep” penetration test as it gains access to internal systems and data. It’s the type of test that we prefer to do and what I would recommend as this is what the real adversarial hackers are doing.
    • Type B – The “360 Lock Check”: This test searches for every possible entry point and validates that it actually is exploitable. This validation is most often completed by performing the exploit and gaining additional privileges. The focus with this type is to find as many entry points as possible to ensure they are remediated. The underlying system might be compromised, but the goal is not to pivot, breach additional systems, or to exfiltrate data. This type is often useful for regulatory requirements as it provides better assurance that all known external security vulnerabilities are uncovered.
    • Type C – The “Snapshot”: This is more of a vulnerability scan in which the results from the scanner report are validated and re-delivered within a penetration testing report. Many lower-cost firms are calling this a penetration test, but that is not what it is. However, it may be all you need. If so, Raxis offers a vulnerability scan on an automatic, recurring basis, and it is very useful in discovering new security risks that are caused by changes to the environment or detecting emerging threats. (And no, it’s not a pen test.)

    If you’re serious about security, I strongly recommend testing that ensures both Type A and Type B are part of the scope. That means testing even a small range of IPs can often take a week. However, it is the most comprehensive way to pentest your environment and meet regulatory requirements as well. Type A tests for the ability to pivot and exfiltrate information. Type B will get you that comprehensive test of any vulnerabilities found to ensure that you’re fixing real issues and not false positives.

    In an upcoming post we’ll tell you about a new capability offered through Raxis One. This is pentesting that leverages the power of AI to extend and enhance the capabilities of our talented team of elite ethical hackers. Raxis Pentest AI is considered a hybrid of all three types of testing mentioned above in that it combines continual monitoring and random testing to find and exploit vulnerabilities as soon as they appear.

    The most important advice I can offer anyone shopping for penetration testing services is to ask a lot of questions. High-quality, reputable companies like Raxis will be happy to put experts on the phone with you to provide answers. You can draw your own conclusions about any who won’t.

     

  • Chained Attacks and How a Scan Can Leave You Vulnerable

    The results from your vulnerability scan showed only a couple of low or moderate level findings, but there is no denying that two experienced hackers now have domain admin rights; the freshly printed summary document on your desk spells out in excruciating detail how they traversed the darkest corners of your network and gained access to critical data.

    Fortunately for you, they’re Raxis team members, and you’ve paid them to do just that.

    The Chained Attack

    This scenario plays out frequently for Raxis customers who previously relied on companies that pass off vulnerability scans as faux penetration tests. It highlights why a scan, by itself, can give businesses a false sense of security about their cyber defenses. At their best, scans only point out individual links in what skilled and experienced hackers can turn into a chained attack – using one vulnerability to discover others, increasing or escalating network access with each move. In the case of parameter or business logic exposures, scans often remain blissfully unaware, failing to identify the exposures at all.

    UNFAMILIAR WORD OR TERM? VISIT OUR GLOSSARY.

    We’ll use a real-life example from a recent Red Team engagement to illustrate just how this works. Keep in mind that the following recap is just one way to employ a chained attack. There are many others. In fact, it’s such a common technique that it’s part of the test ethical hackers take to earn the Offensive Security Certified Professional (OSCP) certification. (Read about Senior Penetration Tester Andrew Trexler’s experience with the OSCP exam.)

    The First Link

    Using a response poisoning attack, our testers achieved Man in the Middle (MitM) and relayed Server Message Block (SMB) handshakes to hosts with SMB signing disabled, which allowed them to execute local commands and extract local password hashes stored by the security account manager (SAM). One of those hashes was associated with a local administrator account, and they used it to connect to a system on the internal network.

    Once inside, they exploited a known design flaw in Windows authentication and used this local administrator hash in a Pass-the-Hash (PtH) attack using CrackMapExec (CME). They didn’t even have to crack the hash and get a cleartext password. Just sending the hash was sufficient to allow access.

    Creating the Chain

    Using PtH, our ethical hackers enumerated users logged on to a system, determined valid usernames, and extracted their Kerberos ticket hashes. This time, they did have to crack the hashed ticket for an administrative service account they found. A weak password and robust cracking hardware made this possible within seconds.

    Having identified the cleartext password for that administrator account, they found that it was shared amongst numerous systems. They connected to other systems across the network and found a domain administrator logged into one of them. An attempt to access the Local Security Authority Subsystem Service (lsass.exe) file failed at first because the company’s security blocked “procdump.exe,” the tool we were using to gather a memory dump of the process. However, a second attempt with Process Explorer was successful and allowed our team to download a memory dump of the “lsass.exe” process, giving us access to the runtime state of the service that performs Active Directory database lookups, authentication, and replication.

    Another tool, Mimikatz, enabled our testers to extract the contents of that file, including the reusable NTLM password hash of a Domain Administrator (DA). Again, using CME, they used the NTLM DA password hash to extract the contents of the entire Active Directory database. This is the database housing all Active Directory objects, including users and their password hashes for the entire domain (that often means every employee at a small company or every employee in a division of a large company).

    “Vulnerability scans are excellent point-in-time snapshots of potential problems. But it takes comprehensive penetration testing to demonstrate how easily a malicious hacker can link them together to create a chained attack.”

    Tim Semchenko
    Owning the Network

    Using this DA access, our team created a new backdoor domain administrator account in the Domain Admins group – ample proof for the customer that Raxis had in fact pwned their network.

    What else could they have done? Anything they wanted, including staying on the system indefinitely or just logging in periodically to steal data or disrupt operations. Once a hacker has this type of access, it’s very difficult for a company to know if their access has been truly and completely removed.

    How is this possible? Because a serious security flaw – one that would not be revealed in full by a vulnerability scan – offered our skilled team members an entry way to take down an entire network had they been bad guys.

    The point is that vulnerability scans are excellent at providing a point-in-time snapshot of potential problems on your network. But it takes comprehensive penetration testing to find out just how serious those issues are and to demonstrate how easily a malicious hacker can link them together to create a chained attack.

  • Helping Nonprofits and Other Growing Businesses Understand Security Risks

    I’m excited that NTEN, the Nonprofit Technology Network with more than 50,000 community members, invited me to be a guest blogger this week.

    It’s important that nonprofits avoid the mindset that leaves so many businesses vulnerable. Specifically, I’m talking about the idea that they are too small or have too little money to be of interest to scammers, hackers, and other cyber criminals. The truth is that the bad guys often don’t discriminate, and you may have something they want more than money.

    For example, if you keep detailed donor records, that personally identifiable information (PII) might be devastating in the wrong hands. A skilled hacker or social engineer can do a lot with names, email addresses, and phone numbers alone. Add in Social Security numbers or bank account information, and you may be sitting on a gold mine for a malicious actor.

    Some of today’s most serious threats are driven by political goals more than financial interests. In many cases, these are well-financed state-sponsored attacks, and your organization may have data that can help them breach a government agency’s security or social engineer their way into a large corporation.

    And forget about hackers leaving you alone because of your mission. After my years in the cybersecurity sector, I’m no longer shocked at how low some of these black hats will go. We’ve seen hospitals and health care organizations, charities, churches, schools, and other do-good groups fall prey.

    The saddest part is knowing that some of these attacks were successful for the very reasons the organizations thought they would never happen. To a hacker, the idea that you’re too small to notice may mean they see you as an easy target, even if you’re only one step toward their larger goal.

    If you’re a nonprofit leader, board member, or even a volunteer, please take a moment to check out the article above. You may find some nuggets that will help you help your organization avoid a breach. And that may be the most important contribution you can make to your favorite cause.

  • Goodies for Hoodies: TCP Timestamps

    The Picts were a tribal culture in northern Scotland that history has relegated to the realm of myth and enigmatic legend. Largely forgotten, the Picts fought off the military superiority of Rome’s army and built a sophisticated civilization on the whole before disappearing from history. These were a people dismissed by the advanced thinkers of the day as unimportant and trivial in their capabilities, only to rise up unexpectedly to great effect. What does this have to do with Security? Nothing really, unless your data center is staffed by Roman centurions on horseback. If that’s you, then I am ripe with envy. But all levity aside, so it was with the Picts, it is today with the humble and unassuming TCP Timestamp.

    What is a TCP Timestamp?

    If you’ve ever run a vulnerability scan, you’ve probably seen a low or informational severity finding associated with TCP Timestamp responses. The recommendation is always to disable them, but rarely is any background information provided. What are those little timestamps doing there and who really cares anyway? Like the Picts, much lies below the surface, and we dismiss them at our peril. Before we can get into the ramifications of this misunderstood protocol option, we must understand the mechanics behind TCP Timestamps, and what they actually are. The basis of TCP is that it is a stateful, reliable means of sending and receiving IP packets. In order for reliable communications to take place, there must be bidirectional communication between the sending and receiving nodes so that, in basic terms, the sender can know that the target system received the communication correctly, and the receiving node has confidence that the message it received was correct. To such ends, TCP communications are session-based, and the two nodes employ features in the protocol as a framework to manage the reliability of communications. This involves things like resets, syn-acks, re-transmissions, and the like, that you’ve probably seen in any number of network captures. TCP was designed to communicate reliably over any transmission medium at any speed; it provides the same level of communications integrity over dial up as it does on a LAN.

    It is important to understand that TCP was originally designed to overcome the challenges of unreliable communication channels. Not much thought was given to excessively reliable and fast communications.

    It seems counter intuitive, but, because TCP is synchronous and keeps track of packets, it can break down over high bandwidth connections. It sounds crazy, I know, but let’s look at how this might happen.

    Grab your pocket protector here, folks. We have to get a little nerdy.

    If you asked President Trump about packet loss on TCP communications, he might respond, “It’s bad, very, very, very bad.” And he would be correct. But packet loss does occur for any number of reasons, and TCP maintains reliability by using selective acknowledgments to tell the sending node what TCP segments are queued on the receiving node and what segments it is still waiting for. These segments are, like anything else in network communications, numbered in finite sequence numbers. This value occupies a 32 bit space and exists within the confines of a Maximum Segment Lifetime (MSL), which is enforced at the IP level by something we’re more familiar with, the Time to Live (TTL). This MSL is usually adjusted based on the transfer rate so that faster speeds have smaller MSLs. This works pretty well until we introduce things like fiber optics. The bandwidth on a fiber connection can be so high that a TCP session can exhaust all of its sequence numbers and still have segments queued up in the same connection, leading to sequence number reuse, aka TCP Wrapping. This causes problems.

    In short, as things get faster, it becomes more error prone to use timeout intervals to manage reliability.

    The number of sequence numbers can not exceed the 32 bit value of 4,294,967,295 so as transmission speed increases, the MSL values must get shorter to compensate. With enough bandwidth, they can shrink to the point that they are no longer able to provide message integrity. If only there was a way to identify whether packets were dropped based on actual timing rather than a sequence number, but how?

    Behold the mighty TCP Timestamp!

    TCP Timestamps are an important component of reliable high speed communications because they keep TCP from stumbling over its own sequence numbers!Officially, this benefit is referred to adoringly as “PAWS” or Protection Against Wrapped Sequence Numbers. PAWS operates within the confines of a single TCP connection under the assumption that the TCP timestamp value increases predictably over time. If a segment is received with an older timestamp than one that was expected, it’s discarded. In doing so, PAWS protects against sequence numbers being reused in the same connection. It’s worth pointing out that there are a lot of weird exceptions and math around how that actually takes place, but for purposes of a blog post, we’ll steer clear of that rabbit hole. It should be clear at this point that TCP Timestamps serve a purpose in network communications, and that disabling them as a standard practice is a perilous endeavor.

    Still awake? Good! Now we can talk about security!

    Strictly speaking, TCP Timestamps are no more a security risk than the TCP protocol itself. Why then are they subject to all the bad press and mob calls for their disablement? The security concerns arise with the underlying mechanisms that are used to populate the values within the timestamp option itself. As the name suggests, the timestamp makes use of a virtual “timestamp clock” in the sender’s operating system. This clock must approximate real time measurements in order to remain compatible with other RTT measurements. There is no requirement for the timestamp clock to match the system clock, but it often maps to it for ease of design. After all, why make a new clock if you can just use the existing clock to derive values to be presented as those belonging to the new clock?

    This leads to the one thing for which we hackers profess a deep and undying love for, unintended and predictable behavior. Am I right?

    By measuring multiple timestamp replies, we can determine what the clock frequency is of the target system. The clock frequency is how many “ticks” the timestamp clock increments per unit of real time. For example, if we measure 5 timestamp replies each 1 second apart, and each timestamp value increases by 100 with each reply, we can infer that the clock increments 100 ticks for every second of real time processed by the system clock.Since most (not all!!) clocks start at 0, we can compute the approximate uptime of the system. Using the above example, if the timestamp value is 60000, we know that each 100 ticks of that value equate to one second of real time. We can assume that 600 seconds have elapsed since the clock was started. In laymen’s terms, the system was rebooted 10 minutes ago. We’re using small whole numbers here for purposes of illustration, but you get the idea.

    In the real world, accurately fingerprinting the system will help with establishing timestamp validity, since clock specifications are documented.

    System uptime by itself is an arbitrary value and doesn’t give away much on it’s own. But consider that patch cycles almost always include mandatory reboots. By surveying these values over time, one might be able to determine patching intervals by correlating reboot times across systems. What if you surveyed the same IP address multiple times and received different but consistently disparate values in the timestamp responses? That might allow you to identify systems that are behind a NAT or a load balancer, and may even allow you to draw conclusions about the load balancing configuration itself. Suppose you were testing a customer for susceptibility to DOS attacks. You may be able to use timestamps to determine with certainty whether the target system was knocked over, or whether you were just shunned by the IPS.

    TCP Timestamps grant the hacker insight into a given system’s operational state, and how we use that information is limited only by our imagination.

    But to dismiss their presence as a low severity security finding just to be remediated is inappropriate, and it may do more harm than good. When to use TCP timestamps should be determined by operational requirements, not by blanket assumptions of their importance. Are you listening, vulnerability scanners?So next time you find yourself knee deep in informational findings from a vulnerability scan, put your ear close to a network cable. It’s possible you may hear the faint battle cry of a forgotten hero. Want to keep reading? Learn the difference between vulnerability scans and penetration tests, more about Vulnerability Management, and how a penetration test can help you understand which risks are most relevant to your network.

  • Vulnerability Scan Vs Penetration Test: What’s The Difference

    Many people seem confused when it comes to understanding the difference between a vulnerability scan and a penetration test. This article will examine the differences between the two and help guide you with decision points in making the right choice for your needs.

    Vulnerability Scan

    A vulnerability scan is conducted using an automated tool that is purpose built to identify potential security gaps on a remote system. This ‘vulnerability scanner’ sends targeted traffic to ports and services on systems and analyzes the responses in an attempt to identify the presence of a vulnerability. At the completion of the scan, a report is generated. The engineer that initiated the scan designates what type of report to generate depending on the specific requirements with regards to verbosity, margin of error, intended purpose, or other business drivers. Some reports are hundreds of pages detailing each individual “finding” while others are as simple as a two page summary.Because a vulnerability scanner has a limited means with which to validate the presence of a vulnerability, the accuracy of the output may be suspect. Depending upon the scanner configuration and the target system, a report may contain a myiad of false positives or fail to identify legitimate vulnerabilities. The end result is that a security engineer has a laundry list of possible flags to chase down and attempt to verify the validity of the issues as well as develop a solution.

    Penetration Test

    A penetration test is a real-world exercise at infiltrating your network systems. To such ends, a security engineer will utilize many tools (including in some cases a vulnerability scan). Wheras vulnerability scanning is a largely automated process, penetration testing involves manual and targeted testing using specific toolsets and custom scripts. Using a combination of techniques and technical knowledge, the penetration tester focuses their efforts on areas of exposure that likely constitute a legitimate risk to an organization’s security.Having identified likely insertion points, the penetration tester will actively attack gaps in the network’s security posture. The execution of a practical attack using the same methodologies that an actual attacker would employ is the most effective way by which to ascertain the real world exposure of a given system or network.As the engineer begins to infiltrate the system he or she will take detailed notes and screen shots documenting the process. The goal is to articulate to the customer the nature of the exposure, and how its presence helped to facilitate a compromise.A seasoned penetration tester will provide a detailed report outlining the various vulnerabilities as well as the severity of each finding within the context of the business, something that a vulnerability scanner cannot provide. The result is an actionable report that provides validation of exposures and targeted guidance on remediation measures.

    Which is Best?

    A true penetration test by a qualified engineer is most often the best overall value for a business. Not only does the stakeholder gain an understanding of the workflow of a real-world attack they also get specific guidance from the perspective of an attacker on what measures would be most effective in thwarting validated attacks. This is articulated in the context of the business drivers of the organization. The end result is that the security organization can focus their efforts where they are most effective and prioritize remediation tasks based on real-world data.A penetration test is more expensive because of the thoroughness of the assessment and the greater value of the outputs. A vulnerability scan is a good starting point and may achieve the bare minimum of satisfying compliance mandates. An organization that understands the difference between compliance and security, however, will endeavor to move beyond automated outputs and seek to understand the practical nature of their security posture.

    Are All Penetration Tests The Same?

    The short answer is no. When you are shopping for a penetration test there are several things you should consider:

    1. Get a sample report – some companies are much more informative in their documentation and a sample report will reflect what you should expect to receive.
    2. History – ask about the team and their experience working with organizations of a similar caliber.
    3. Diversification – find out the background of the team members; the technical expertise brought to bear during the test should be appropriate to the technologies that your organization utilizes.
    4. Duration of test – based on your specific situation ask how long the assessment should take to perform. This may be governed in part by the scope of assessment or other logistical factors.
    5. Their level of specialization – do they only offer penetration testing or do they also provide other products and services.

    Each of these questions will give you insight to the quality of assessment you’ll receive. Especially in security, the relationship between cost and value is subject to variation. Determine if the team is going to spend adequate time on your assessment and if their security engineers have the expertise for your specific situation. Compare reports and insure the report will satisfy your ability to properly remediate the findings. And finally, don’t be afraid to ask to speak to a security engineer and dive deep in questioning their methodologies and experience with the type of testing you need. A competent penetration testing provider will not shy away from such discussions and will welcome the opportunity to add value to your security program.

  • Penetration Testing Pricing

    Updated: April 9, 2018

    How Much Should You Pay for A Pen Test?

    It’s my job to ensure that we’re priced right and delivering a strong value for what we charge.  Yet, I’m continually amazed at the price differential I am seeing for penetration tests (pen tests).  With prices ranging from $1,500 to hundreds of thousands of dollars, I can imagine how difficult it might be for our customers to understand how penetration testing pricing works.Similar to many things that you buy, generally the higher cost products tend to be better than the lower cost products.  While this is likely true in the pen testing world too, how do you know what is adequate for your needs?  Even though there’s a need for high dollar tests at the highest category, most companies don’t need to spend $250,000 on a multi-month penetration test.  For just one week of penetration testing, pricing ranges from $1,500 to about $15,000 for a full retail price.  However, not all pen tests are equal.Here’s a breakdown of why pen testing prices are so different.  There are other elements that might come into play, such as on-site vs. remote and remediation testing, however this list focuses on the penetration test work itself.

    Skill Set

    Not all pen testers are the same, and the proposed pen test pricing should reflect that.  For example, some pen testers are incredible at hacking Windows systems, but are not nearly as strong when it comes to Linux or mobile technology.  Make certain that the team is well versed in all technologies that you have in scope.  Many environments have a huge mix of Linux, Windows, Android, iOS, Mac OS X, Cisco IOS, Wireless networks, and others.  Your pen tester needs to have skills in all of the areas that affect your environment to perform a valid test.

    Time Dedicated to the Job

    The amount of time that a penetration tester spends on a job can really vary, leaving lots of room in how the jobs are quoted. Some pen testers believe that a week, two weeks, or even months are required to get a comprehensive test completed on your network. If you’re quoted anything less than a week, I would hope that it’s an extremely small scope of just a few IPs with no services running on them.  Otherwise, I’d be skeptical.  The key here is to make sure the time spent on the job makes sense with what you’ve deemed in scope for the test.  Keep in mind a single IP with a large customer facing web portal with 10 user roles will take a lot more time than 250 IP addresses that only respond to ping.

    Methodology

    There’s a few different ways to complete a penetration test.  I’ve broken them down into types for reference.

    • Type A would be to search for the low hanging fruit and gain access to a system as quickly as possible. The goal would be to pivot, gain additional access to other systems, ensure retention of the foothold, and finally exfiltrate data. This is a true penetration test and demonstrates exactly what would happen in the event of a real world breach. Some companies call this a “deep” penetration test as it gains access to internal systems and data. It’s the type of test that we prefer to do and what I would recommend as this is what the real adversarial hackers are doing.
    • Type B searches for every possible entry point and validates that the entry point actually is exploitable. This validation is most often completed by performing the exploit and gaining additional privileges. The focus with this type is to find as many entry points as possible to ensure they are remediated. The underlying system might be compromised, but the goal is not to pivot, breach additional systems, or to exfiltrate data. This type is often useful for regulatory requirements as it provides better assurance that all known external security vulnerabilities are uncovered.
    • Type C is really more of a vulnerability scan where the results from the scanner report are validated and re-delivered within a penetration testing report. Many of your lower cost firms are delivering this as a penetration test, although it really isn’t one. It’s just a paid vulnerability scan, and, in some cases, that might be all you need. We offer a vulnerability scan called the BSA on an automatic, recurring basis and it is very useful in discovering new security risks that are caused by changes to the environment or detecting emerging threats. No, it’s not a pen test 😉

    My recommendation would be to ensure both Type A and B are part of your pen test.  This means that even a small IP range will have a week long test at a minimum, but it is the most comprehensive way to pen test your environment and best meets regulatory requirements as well.  Type A will ensure that a test is completed allowing pivoting and exfiltration of information.  Type B will get you that comprehensive test of any vulnerabilities found to ensure that you’re fixing real issues and not false positives.

    Don’t Go too Low

    If someone is offering you a pen test for less than $3,000 for an entire week of effort, I would be very skeptical that you’re getting an actual penetration test. The ethical hackers that perform these tests are costly, and as they don’t work for a salary that would fit the bill rate.  Remember that these resources need to understand networking, operating systems, applications, and security all at the same time.  In addition, there is also cost overhead from operating a business that should be considered.Regardless, penetration testing is a vital part of a strong security program.  Most regulations and security professionals recommend it be performed annually.  It’s better to be hacked by a pen testing vendor than the alternative, so give us a call at Raxis, and we’ll be glad to help you improve your security by uncovering any hidden security risks.