Penetration Testing, otherwise known as “Ethical Hacking”, robustly interrogates your site’s security posture to identify vulnerabilities or weaknesses. By undertaking Penetration Testing before launching your site, you have the ability to fix bugs in advance of going public. Regular Penetration Testing is an essential step in giving your site users confidence they are engaging and transacting in a secure environment.

Developing Secure Apps

Developing secure apps starts with ensuring your code is secure

Perhaps you need to develop a new e-commerce platform. Perhaps you’re considering a new customer portal. Or perhaps your organisation needs to be able to transmit high volumes of data securely.

Whatever the reason, when it comes time to develop or upgrade your organisation’s web applications, having strongly written code is the first step towards ensuring your app will be secure.

From the outset of the Software Development Lifecycle (SDLC), you’ll be faced with a clear choice: to make use of closed-source or open-source code.

In this blog we’ll examine the pros and cons of both options and the importance of incorporating Secure Code Reviews from the earliest stages of the development pipeline.

Depending on the complexity of the web app you’re developing, a review could be as simple as a colleague looking over your code. However, when developing more complex commercial applications, in which private data is being transmitted, a professional Secure Code Review is essential. Having experts review your code, both at the early stages and throughout the project, after major releases or automatically on code commits, significantly improves the chances your final product will be a secure web application.

Secure Code Review

Closed-Source Code

For many organisations, the default choice when it comes to app and software development is closed-source code.

There are a variety of reasons why closed-source code can be a good choice for many organisations.

  1. QUALITY: Closed-source code tends to be developed to a high standard. As a product developed with commercial imperatives in mind, closed-source code writers naturally seek competitive advantages by updating their code and adding additional functionality. Given they are likely providing customer support, they have an interest in writing it well.
  2. COMPLIANCE: There is a tendency for closed-source code developers to align their code with a range of compliance standards. Many organisations have compliance obligations that determine how they handle and store data. Whilst open-source code may meet these requirements, often closed-source providers guarantee their product complies with certain security standards. This can make life much easier when developing an app that needs to align with specific compliance standards.
  3. SUPPORT: When purchasing closed-source code, it usually comes with developer support for a period of time. This can be extremely beneficial while building your application. Any questions or challenges you experience with the code can be addressed by the developer. Of course the level of customer support will vary between providers, but reputable code suppliers should offer prompt support to customers.
  4. SECURITY: When embarking on the process of developing an app, many organisations will be swayed by the notion that proprietary closed-source code must be more secure than free, open-source code. Having been developed in a corporation by a team of professional code writers, often with the funds to use security tools and employ security professionals, closed-source code usually undergoes extensive quality assurance vetting. In theory, this should help significantly reduce the number of vulnerabilities or bugs in the code. While such claims are hotly contested by advocates of open-source code, purchasing closed-source code from a reputable developer, who can be clearly identified and contacted in the event of any problems, gives many app builders a greater sense of security.

Should you decide to go down the closed-source route, it’s important to remember that only the original authors have complete access to view and alter the code. Typically, you don’t usually purchase the source code outright, rather you pay a license fee to access and use it. That could turn out to be a problem as you will be wholly dependent on the developers should any problems with the source code manifest.

In the event that you find vulnerabilities in the code, responsibility to fix them rests with the code’s authors, not you as the final user. While this can be a good thing, as the onus of responsibility isn’t yours, there’s no guarantee the vendors will be able to patch vulnerabilities quickly. With proprietary code, there may only be a small team of developers working on the project. Capacity constraints can mean patches are slow to be rolled-out. With only one place for you to go for support, patching and functionality enhancements, you’re essentially locking yourself in. If the vendor doesn’t fix bugs in a timely manner, you could be putting your entire web app project at risk as you’re totally reliant on a single supplier’s code.

Open-Source Code

When it comes to open-source code, some organisations are inclined to avoid it on the basis that it is free, and thus perceived as inferior. However this perception is not correct. Open-source code is ‘free’ in the sense of ‘free speech’.

The move towards opening up source code to the public started in reaction to frustrations developers faced with the restrictive practices of corporations who followed the proprietary model. Many companies refused to provide users with the ability to view or alter their source code, limiting developers in their capacity to adapt software to meet their specific requirements.

For Richard Stallman, a software programmer at the Massachusetts Institute of Technology, the problems posed by closed-source code became untenable. In the 1980s, Xerox had supplied Stallman’s department with a free prototype Xerox printer. The printer was prone to paper jams. Stallman, who had access to the source code, was able to write a simple script notifying the person waiting for documents that the printer was jammed and they should walk down the corridor to fix it. That simple work-around ensured people weren’t left for long periods of time waiting for their documents. However, one day Xerox sent a newer printer to Stallman’s department. It too was prone to paper jams, but this time Xerox refused to supply the source code. Stallman couldn’t write his simple script.

The experience was instrumental in convincing Stallman of the benefits of open-source code. Opening-up the source code didn’t deprive the people who developed the code of anything, yet it could enable code enhancements that would benefit everybody.

Stallman went on to developed a suite of free software tools, known as the GNU project. By 1991 he had teamed up with another programmer, Linus Torvalds, who had developed Linux. Together, GNU/Linux became the world’s first completely free and open-source computer operating system. 

Free-market economist, Friedrich Hayek, had long espoused the concept of the ‘Knowledge Problem’ in which no one individual, or even group of well-informed individuals, could ever have enough knowledge to plan a market. This same principle drove the advocates of open-source code. The knowledge bank in any corporation, even large ones like Xerox, Microsoft or Unix, could never compete against the vast collective knowledge of thousands of individuals. Source code was viewed as a shared resource. However, unlike other shared resources, it avoids the ‘Tragedy of the Commons’ problem. Whereas most shared resource are depleted the more they are used, source code becomes more valuable as it is used, because thousands of individuals contribute improvements to it and develop fixes whenever bugs are discovered. 

From a security point of view, the great advantage of open-source code is the more people inspect and use the code, the greater the chance that any vulnerabilities are identified and fixed promptly. 

Given enough eyeballs, all bugs are shallow

This principle became known as ‘Linus’s Law’ and was described in Eric Raymond’s seminal 1999 book ‘The Cathedral and the Bazaar’.

Raymond identified two competing approaches to development:

  • Cathedral approach: This was a conventional, closed development style. It included tight specification of objectives, small development teams, with the entire project run in a fairly hierarchical and authoritarian manner. This approach was also characterised by long release intervals.
  • Bazaar approach: This was a decentralised approach with a strong emphasis on peer to peer reviews. It involved constant solicitation of feedback from people who were formally outside the development project. The approach was characterised by very short release intervals.

For advocates of the Bazaar, or open-source approach, trading away the proprietary advantages of the closed-source approach was justifiable as it resulted in the very significant advantage of massive independent peer review. Having large numbers of independent people checking the code on an ongoing basis, ultimately resulted in superior code.

The notion that open-source code would be messy, inconsistent, vulnerable or inelegant, turned out to be incorrect. Open-source code projects still had a small team of core developers. These people acted as gatekeepers in order to filter the contributions and patches of the outside public and maintain the architectural integrity of the project.

There are a number of ways open-source code can be monetised. Some companies, such as Red Hat, enable customers to access code free of charge, but then charge for customer service. Other companies offer code for a license fee but allow the licensee the freedom to change the code as they see fit.

The core business case behind open-source is that real value isn’t derived from the code itself, but the way the code can be used to enable other commercial activities. Everyone therefore benefits when the code is regularly enhanced.

The major concern regarding open-source is that hackers have as much opportunity to inspect and scrutinise the code as anyone else. This may enable them to identify and exploit vulnerabilities before the general public has an opportunity to develop patches. Heartbleed and Shellshock are examples of two vulnerabilities that were discovered in code many years after the code was released. Some believe that the ‘many eyeballs’ theory falls short because only relatively few of those people have the time, skills and motivation to fix code, some of which has been in the public domain for many years.

Why you need a Secure Code Review

Whether you opt for using closed-source or open-source code, a Secure Code Review should be an integral part of your development lifecycle.

It is much less expensive to build a secure app than to retroactively fix security issues after completion. Some estimations suggest that implementing patches to remedy vulnerabilities is 60x more expensive than building-in security from the outset. This of course does not take into consideration the potentially devastating costs your organisation can face in the event of a serious security breach.


Code reviews are one of the most cost-effective ways to prevent vulnerabilities and help ensure your project is secure. A code review can be as simple as giving your code to a colleague to look over before implementation. It should be noted however that this approach may not be rigorous enough if the code you are using is complex.

At Shearwater, our methodology when conducting a Secure Code Review is multifaceted and includes both automated and manual investigations.

    To start, our team of experts will conduct a rigorous process of information gathering. This is the time when we gain a broad understanding of the context of the application, its business functions and any potential security concerns.
    To start, our team of experts will conduct a rigorous process of information gathering. This is the time when we gain a broad understanding of the context of the application, its business functions and any potential security concerns.
    Using Static Application Security Testing (SAST) scanning tools, such as Fortify, or Secure Code Analysis (SCA) tools, like OWASP Dependency Checker, our experts will interrogate the code for a wide range of common vulnerabilities. This includes examining source code from a multitude of languages and frameworks, such as Java, .Net, Python, Node.js and Ruby, regardless of whether they’re compiled or uncompiled. Automated scans can identify classes of vulnerabilities that occur regularly in code, such as injections.
    Also known as ‘Code Crawling’, a manual review is when our team of experts physically read the code base. We do this in order to locate and analyse potential vulnerabilities in areas of the application code that are likely to have security implications, and that may not be picked up during automated scans.

The key to successful code reviews is to begin in the early stages of the development pipeline, known as the ‘Shift-Left’ approach. Start by conducting code reviews at the beginning of the journey and ensure that your development team are trained in good code hygiene practices. At each stage of the development lifecycle, ensure that code is regularly reviewed.

By the time you come to the final stages of developing your app, have a 3rd party independently review the code again. It’s important to have this independent oversite. A fresh pair of eyes may identify vulnerabilities that had been missed.

Security Code Review in the SDLC

Source: OWASP:

How Shearwater can help you?

Integrating Security Code Reviews into your System Development Lifecycle (SDLC) can ensure the quality of your code, and the security of your application, are significantly enhanced.

Shearwater’s methodology for conducting Secure Code Reviews complies with industry best practice and combines both automated and manual investigations. We can also train your development team on the best ways to develop securely. 

A Secure Code Review should be seen as one of the layers in a defence-in-depth approach to app security.

For further information on Secure Code Reviews, Contact Shearwater today.

Securing Your Serverless Web Applications

Going Serverless

Let’s get one thing straight: A “serverless” web application IS still executed on a server.

So, technically it’s not “serverless”.

However, it is called “serverless” technology because your web app no longer needs to be permanently hosted on its own dedicated server, nor on a shared server.

Serverless technology is an example of an increasingly popular trend towards Function as a Service (FaaS). Put simply, a developer builds a piece of code. When it needs to be executed, an API or trigger sends the code to a cloud server where it runs.

That’s it.


Daniel Stori, ‘serverless economic impact’, Creative Commons

This allows developers to build and deploy web applications without the need to know in advance all the server capacity and infrastructure that will be required.

There are some significant benefits to going serverless including:

  • The ability to stop worrying about server management. The beauty about serverless technology is that you don’t need to configure or maintain any servers.
  • Unprecedented flexibility to scale up as required. As traffic to your web application increases, you can rapidly increase capacity.
  • Servers crashing and bringing down your entire web application are a thing of the past – assuming you have well written code!
  • Save a fortune by saying good-bye to excess capacity. When your code isn’t running, you don’t pay a cent. This can result in big savings. By only paying for the actual time your code is being executed on the server, you won’t be billed for any idle time. Typically serverless technology providers charge just when the code is running, down to the nearest 100-milliseconds.

For all these reasons, the trend towards serverless web applications is growing. Many cloud vendors, including AWS Lambda, Microsoft Azure and Google Cloud Platform, support it.

Best of all, by adopting the serverless model, you’re able to build and run applications without thinking about servers, allowing you to focus more time and energy on other priorities.


What are the downsides?

When it comes to securing your serverless web application, you still face the same vulnerabilities as with a traditional server-based application. However, there are some additional risks you need to consider.

Two of the most important considerations when going serverless are:

  1. API Security – Due to the fact that serverless web apps usually depend heavily on APIs to execute code or create the relevant trigger, ensuring those APIs are secure is a major concern.
  2. Lack of Control – Serverless web apps may be more susceptible because, compared to server-based apps, you have less control and there aren’t the range of security tools available. This makes ensuring you have quality code even more important.



Serverless apps work by transferring code and sensitive data via an API or a trigger to a server each time the code needs to execute.

Any security weaknesses in those APIs could result in you being more exposed to attack. You need to think carefully about having the right API security strategies in place to mitigate this threat. Apart from the risk of data breaches, vulnerable APIs could allow attackers to take control of your application.

With APIs integral to digital transformation strategies, many organisations are shifting from running a few APIs to now running hundreds, if not thousands of them. Having the capacity to detect malicious activity across so many APIs is a significant challenge. Our experience indicates that some of the most common attack vectors include broken authentication mechanisms and broken function-level authorisation flaws.

Furthermore, even if the API itself is secure, some inadvertently leak data while backing up files to a repository, such as GitHub, or expose information when interacted with in a manner that the developer did not anticipate.

The risks associated with APIs are exacerbated in a situation in which serverless resources are being automatically scaled-up to accommodate increased user demand. With automatic scaling, if you’re leaking data, you could start leaking data even faster.

That’s why organisations that adopt serverless web applications may be assuming greater risks than those that stick to server-based applications.  

At Shearwater, we recommend stricter controls around API usage to limit those risks.

Organisations should ensure they are maintaining an accurate inventory of all their APIs, in order to keep track of what’s running at any given time. In line with that, we also recommend that developers establish secure processes for the creation and deployment of new APIs.

Importantly, app developers should also review their authentication and authorisation mechanisms, as well as the processes by which API code is modified.



The flexibility afforded by serverless web apps is one of their great advantages. However, this could result in you forgoing a degree of control.

Serverless technology means practically anyone in your DevOps team can develop and execute code quickly. You need to ensure that adequate checks and balances are in place to review apps before they go live. Failure to have adequate controls in place could result in weak code, leaving you dangerously exposed.

Furthermore, there are still relatively few security tools available for this nascent technology, and the tools that are available usually don’t offer you the level of control you’d have with server-based apps.

When it comes to securing a serverless web application, you may be limited by the tools and features made available by the cloud platform provider you choose to use (e.g. AWS Lambda, Microsoft Azure or Google Cloud Platform).

Often, the security tools and features these providers supply are specific to their platform only. They are usually not compatible with other platforms. Such platform-specific security features often fall short of what’s really required: operating system security features and controls.

In addition to this, all too often we see that platform-specific security features made available by the big cloud vendors don’t meet the client’s specific requirements.

For example, if you’re developing a serverless web app that should only be accessible from specific IP addresses, and you’re looking to host it on AWS Lambda, you’ll face the problem that the AWS API Gateways can be reached from anywhere on the public internet. Furthermore, they can be accessed simply by using an API key, which many now consider offers insufficient security for APIs, given the volume of secure data they transmit.


How to stay safe?

All too often developers land in hot water because they’ve written code for a serverless environment and then forgotten about it. 

Due to the fact that ongoing work on a server isn’t required, it’s easy to lose track of the code that’s been written and is being executed by a cloud service provider.

Serverless technology isn’t “SET & FORGET”

To help developers who use serverless technology stay secure, OWASP (Open Web Application Security Project) recently launched a provisional list of the 10 most common vulnerabilities specifically faced by serverless web apps.

This initiative is recognition of the fact that serverless technology is increasingly popular and faces some unique security challenges. The list identifies the most common attack vectors, security weaknesses, and business ramifications of successful attacks on serverless applications. Importantly, OWASP focuses on prevention strategies.

OWASP Top 10 Serverless Vulnerabilities

Threat Type

Threat Gauge


Serverless applications tend to have larger attack surfaces than server-based applications. This could result in more injection attacks on various functions. The impact will depend upon the specific permissions granted to the attacked function. For example, if a function with high privileges which accesses cloud storage is attacked, the injected code could delete or upload corrupted data. If the function also has access to database tables, records could be deleted or inserted. It could even result in a cloud account takeover.

Broken Authentication

Broken authentication can allow an attacker to either capture or bypass the authentication controls used by a web application. This is usually caused by poor design of identity and access controls. With multiple serverless web apps running simultaneously in stateless containers, attackers will look for a forgotten vulnerable resource. If it can be accessed without authentication, this could result in sensitive data leaking, as well as the potential breaking of the system’s business logic and flow of execution.

Sensitive Data Exposure

Sensitive data exposure is a concern in serverless architecture, just as in any other architecture. Most of the methods used in traditional architecture, such as stealing keys, performing man-in-the-middle (MitM) attacks and stealing readable data at rest or in transit, still apply in a serverless environment. However, the data sources might be different. Instead of stealing data from a server, the attacker can target cloud storage and database tables. Storing sensitive data in plain text, or even using weak cryptography, should always be avoided.

XML External Entities (XXE)

An XML external entity injection (also known as XXE) is a vulnerability that allows an attacker to interfere with an application’s processing of XML data. XML is a mark-up language, much like HTML, that was designed to store and transport data. A successful XXE attack in a serverless application could lead to code and other sensitive files leaking from the environment.

Broken Access Controls

A serverless application can consist of hundreds of different microservices. Each will have different functions, resources, services and events. Together they create a complete system logic. The stateless nature of serverless architecture requires careful access control configuration for each of the resources. Attackers will target over-privileged functions in order to gain unauthorised access to resources in the account rather than having control over the environment.

Security Misconfiguration

In serverless architecture, each function or resource can be the weakest-link into the application. While the likelihood of gaining full control may be lower than in server-based apps, and the impact may be less (depending on the role), the increased number of entry points suggests a slightly higher risk when it comes to serverless technology, compared to traditional architecture. Misconfiguration could lead to sensitive information leakage or unauthorised access to cloud resources. Attackers will try to identify misconfigured functions with a long timeout or low concurrency limit in order to initiate a Denial of Service (DoS) attack.

Cross-Site Scripting (XSS)

Cross-Site scripting (XSS) attacks target browsers, which means attack vectors in a serverless environment are similar to a server-based environment. However, in a serverless environment, the difference is likely in the source of the attack. The source of traditional XSS attacks are usually databases or reflective inputs. In a serverless environment they could also originate from different sources like emails, cloud storage, logs, IoT, etc. Encoding all untrusted data before sending it to the client, as well as using known frameworks and headers, are essential to prevent XSS attacks.

Insecure Deserialisation

Dynamic languages like Python and NodeJS, together with the common use of JSON, a serialised data type, could make deserialisation attacks a little more common in the serverless world. As usual, the impact depends upon the application and the data it handles. Insecure deserialisation usually results in running arbitrary code that could eventually lead to data leakage and, in severe cases, even resource or account take-over.

Using Components with Known Vulnerabilities

This is one of the most widespread vulnerabilities when it comes to serverless web applications. Serverless functions are usually small and used for micro-services. To be able to execute the desired tasks, they make use of many dependencies. Developers may not be aware of all of them and may not be keeping them updated. Dependency scanners can help with this.

Insufficient Logging and Monitoring

Attackers rely on the lack of logging and monitoring to achieve their goals without being detected. Serverless auditing is more difficult than traditional-server auditing, because developers usually rely on the security tools supplied by the cloud vendor rather than using their own more suitable tools. This provides an opportunity for attackers. You should deploy auditing and monitoring mechanisms beyond those supplied by the cloud vendor to better identify security events.


In addition to these Top 10 serverless vulnerabilities, OWASP identifies some additional serverless security risks you should also consider:

Threat Type

Threat Gauge

Denial of Service (DoS)

The fact that each function is handled in a separate environment means that DoS attacks are not necessarily as great a risk in serverless technology. The fragmented nature of serverless apps means it will only affect those events coming into this specific environment without usually affecting subsequent events.

Denial of Wallet (DoW)

Automated scalability is one of the reasons to go serverless. It allows you to pay for the amount of server capacity you use to execute your app’s code and nothing more. Nevertheless, it comes with a risk that attackers can trigger resources (e.g. external APIs, public storage) upon their will and cause financial damage to your organisation.

Insecure Secret Management

It is always hard to securely manage all our secrets. However, secrets can usually be managed on a protected location in our backend. However, in a serverless environment, secrets are shared across resources in the account. Secrets like cryptography keys, API tokens, storage credentials and other sensitive settings are now shared more easily between functions and code, which could lead to sensitive data leakage that could be hard to mitigate.

Insecure Shared Space

Serverless environments are usually designed to be temporary. Once a serverless environment becomes redundant, there’s a risk that the application wrote some data into the user-space (e.g. /tmp) which could subsequently be accessed by an attacker.

Business Logic Attacks / Flow Manipulation

Business logic attacks may be the most complicated attacks to detect and usually have a high business impact. In a business logic attack, an attacker takes advantage of a flaw in the programming that manages the exchange of information between a user interface and an application’s supporting database. Microservices can be particularly vulnerable. While attackers can identify, constrain and manipulate flows in both traditional and serverless environments, the fact that microservices mostly execute in serverless environments means that careful design principles should be applied.


How Shearwater can help you?

When developing serverless web applications, it is essential to ensure you have secure APIs.

Shearwater are experts at API Penetration Testing.

Our team will scrutinise your APIs to identify and exploit potential vulnerabilities and weaknesses. This is a critical step in hardening your APIs to prevent them being exploited by malicious attackers.

We can also robustly interrogate your serverless web apps to identify any weaknesses.

This will give you the awareness you need to ensure you can make the most of the advantages that come from going serverless, without opening yourself up to additional risks.

Contact us  today to speak to our expert Pen Testers.



Unauthenticated vs Authenticated Penetration Testing. What’s right for you?

Fort Knox, home to America’s gold bullion reserves, is synonymous with impenetrability.

Despite formidable and multi-layered defensive measures, could an attacker still identify security gaps and penetrate the perimeter?

Regularly checking perimeter defences can help identify potential vulnerabilities. Conducting assessments from the outside, like an attacker without access credentials, is an Unauthenticated test.

But what if an attacker malevolently obtains access credentials? What if an attacker is invited inside by an employee? What if an aggrieved employee turns nefarious and becomes an attacker? Security measures within the Fort need to be assessed to limit the damage of an attack launched from the inside.

Conducting assessments like an attacker already on the inside is an Authenticated test.

This is the fundamental difference between
Unauthenticated and Authenticated Penetration Testing.

An Unauthenticated Penetration Test is an examination of an asset without login credentials – usually a username and password. It simulates how a random outside attacker would approach the asset.

Conversely, an Authenticated Penetration Test is an examination of an asset from the perspective of an attacker who has managed to gain entry, whether with compromised login credentials, or a malicious employee with access rights.

Whether you decide to undertake an Unauthenticated or an Authenticated Pen Test, it’s important you understand the differences between the two so you can make the right decision based on what you’re trying to achieve.


How does this differ from External and Internal Penetration Testing?

All too often ‘External’ is used interchangeably with ‘Unauthenticated’, while ‘Internal’ is used interchangeably with ‘Authenticated’.

However these terms are not synonymous.

    • External Penetration Testing refers to assets that are externally facing. Such assets are usually accessible via the internet. Some examples may include websites, email systems, or file sharing platforms.
    • Internal Penetration Testing refers to assets that are internally facing. These are accessible from within an organisational environment, such as a network or a server.

Both External and Internal assets can be tested in an Unauthenticated or an Authenticated way, depending on whether you have access credentials.

• No access credentials = Unauthenticated
• Access credentials = Authenticated

With an Unauthenticated Pen Test you’ll know whether an intruder can breach your defensive perimeter. With an Authenticated Pen Test you’ll know what damage they can do if they’re already on the inside.

External vs Internal

External Penetration Testing examines externally facing assets that are usually accessible through the internet. Examples include email, websites and file sharing platforms.

Internal Penetration Testing examines internally facing assets, such as networks or servers, that are accessed from within an organisational environment.

Unauthenticated vs Authenticated

Unauthenticated Penetration Testin involves examining the security perimeter of an asset without any login credentials or access rights.

Authenticated Penetration Testing involves examining an asset with login credentials or access rights in order to determine how much manoeuvrability someone has once inside.

‘External’ and ‘Internal’ refer to the type of asset being examined.
Both types of assets can be tested in either ‘Unauthenticated’ or ‘Authenticated’ ways.



When deciding what type of Penetration Testing is right for you, start with a clear awareness of what you’re trying to achieve.

If your goal is to satisfy certain compliance standards that require regular perimeter testing, an Unauthenticated Penetration Test may suffice. You will gain awareness of vulnerabilities, such as open ports in firewalls, that could be used by attackers to breach your perimeter defences.

There certainly is merit in such an exercise, and it may be all that’s required in certain circumstances.

However, for a more complete picture of what damage an intruder could do once they’re on the inside, Shearwater recommends you undergo an Authenticated Penetration Test.

Authenticated Penetration Testing is best practice because we examine both your perimeter, as well as your internal security defences.


With Shearwater’s Authenticated Penetration Testing, you’ll benefit from:

❖ Greater Accuracy about your Risk Profile

Having accurate information is essential when assessing risk.While Unauthenticated Pen Testing can highlight perimeter security gaps, it has its limitations.Conducting Authenticated Penetration Testing offers deeper awareness into potential risks from a broader range of vulnerabilities.

Whether you’re testing a network, operating system, web application, or any other type of External or Internal asset, Authenticated Penetration Testing ensures you have an accurate and complete picture, so you can correctly assess your organisation’s risk profile.


❖ Protect Yourself from Malicious Insider Threats

Malicious insider threats are an increasing risk for many organisations.

Fraud, sabotage, and data theft can be inflicted by trusted insiders, such as employees, who may be motivated by financial gain or vengeance.

With an Authenticated Penetration Test you’ll know what damage an individual with malicious intent could inflict if they are already inside your defensive perimeter.

By allowing security analysts to access your system as privileged users, for example with login credentials, you’ll have the ability to detect vulnerabilities from within, whether they be weak passwords, malicious software or configuration issues.


❖ Strengthen your Security Posture Against Intruders

Authenticated Penetration Testing simulates circumstances in which an intruder gains access to your systems without your knowledge.

They may have obtained access by compromising legitimate users as a result of “password spraying” or “credential stuffing” attacks.

Whatever method was used to obtain illegitimate access, you need to strengthen your security posture by limiting the amount of access they have once they’re on the inside.

Only by conducting Authenticated Pen Testing will you have the visibility to know what needs to be done to compartmentalise and restrict internal lateral mobility.  

Furthermore, strengthening your security posture is important to maintaining a competitive advantage in an era of heightened cybersecurity concerns. It demonstrates your organisation’s commitment to cybersecurity and data confidentiality.


How Shearwater can help you

Heighten your organisation’s security with Shearwater’s team of expert Penetration Testers.

By engaging our team to undertake Authenticated Penetration Testing, we go the extra mile by examining both your perimeter and your security defences within the perimeter.

The aim of an Authenticated Pen Test is to identify and exploit vulnerabilities relating to:

  • Access Permissions;
  • Security Configurations; and
  • Data Protection Mechanisms.

We offer in-depth executive level reporting which serves as a risk minimisation tool for management, and a technical document – listing vulnerabilities prioritised according to risk level – for the internal security team to remediate.

The report also provides access to mitigation strategies based on Shearwater’s key insights into the cyber-threat landscape.

Building a Secure Web Application

Combining OWASP’s TOP 10 within a SECURE DEVELOPMENT FRAMEWORK gives you the strategy you need.

When it comes to building a secure web application, developers have relied on OWASP’s list of Top 10 vulnerabilities for the best part of two decades.

But increasingly we hear people asking: Is OWASP still relevant?

At Shearwater, we believe OWASP is important and the guidelines still have much to offer.

However, we also believe it is absolutely crucial developers understand the right way to make use of the OWASP Top 10 list.

Don’t treat OWASP as just a checklist.

Rather, you should consider it in the context of a secure development framework. This will enable you to conceptualise security requirements early in the lifecycle.

While OWASP provides the ideal starting point for web app developers, achieving a comprehensive security posture requires the standards be implemented from the very beginning of the development process.

This is where a secure development framework, like OWASP ASVS, BSIMM or Microsoft’s Security Development Lifecycle (SDL), become significant.

By considering the OWASP Top 10 vulnerabilities within a secure development methodology and timeline, you’ll achieve a comprehensive Shift-Left approach towards web app security.

Shift-Left  /ʃɪft/-/lɛft/

A Shift-Left approach can be used by developers to identify and pre-empt software defects, including security vulnerabilities, as early as possible in the development pipeline.

By using a Shift-Left testing strategy for potential vulnerabilities earlier in the lifecycle (i.e., moving your testing to the left on the project timeline), you’ll benefit by being able to:

· Enhance Product Quality
· Save Time
· Save Money


When did OWASP and Microsoft’s SDL begin?

Bill Gates is a name you’re familiar with. But are you also familiar with Mark Curphey?

Both played pivotal roles in raising web app security awareness in the early 2000s. Within the space of just four months, both Gates and Curphey introduced principles that continue to set the benchmark for web app security standards till today.

Back in September 2001, Curphey launched OWASP, or the Open Web Application Security Project.

Together with legions of volunteer contributors, Curphey set out to shed light on what it takes to achieve software security best practice. In doing so, he sought to ensure developers would be better informed about web application security risk. They would also be exposed to potential solutions to mitigate those risks.

Just four months later, in January 2002, Gates announced Microsoft’s commitment to “Trustworthy Computing”. The landmark commitment would place security at the heart of all Microsoft initiatives. This became the foundation of the Microsoft Security Development Lifecycle (SDL), which outlines a clear pathway, so security and privacy considerations are incorporated at every stage of the software development pipeline.

At Shearwater, we believe that developing a secure web app requires combining the OWASP security parameters, while implementing them at the appropriate stages of a development pipeline, such as the one outlined in Microsoft’s SDL.

While the SDL is only 100% relevant if you’re building software exactly the way Microsoft does, following a traditional ‘waterfall’ software development model, it nonethless has elements you can adapt for agile development, as preferred by many developers.

This combination of the OWASP Top 10 with the Microsoft SDL increases your chances of developing a robust and secure web application.


What is the OWASP TOP 10 and why is it important?

By 2003, OWASP refined its list to the 10 most significant web app vulnerabilities. Since the release of the initial OWASP Top 10 list, many developers have relied on it as the holy grail of vulnerability assessment.

With the OWASP Top 10 being updated approximately every three years, most recently in 2017, developers have an up-to-date list of the most common vulnerabilities. These are identified following extensive studies. The 2017 list was compiled after analysing in excess of 2.3 million potential vulnerabilities on approximately 50,000 web applications. OWASP today has more than 36,000 participants in local chapters world-wide.

Whatever the nature of the site, such as webmail, e-commerce, online auctions or any other type of web app, it’s imperative that vulnerabilities and security flaws are plugged before going live.

It needs to be noted that the OWASP Top 10 is NOT designed to identify every possible vulnerability. Rather, it is designed to assist developers avoid common threats that pose the greatest risk to their application. Any determined hacker will find ways to breach even the most secure web apps. But in line with risk management strategies, the OWASP Top 10 list focuses on the most common vulnerabilities.

That’s why OWASP is important.


How to do OWASP Testing?

Many developers use the OWASP Top 10 as a checklist against which they can test their site before launch.

However, the checklist approach to security and privacy is not considered best practice.

Rather than developers considering from the outset how OWASP works and what the OWASP standards require, a tendency has emerged to consider the guidelines at the end of the development process.

We’ve witnessed many developers build web apps without explicitly incorporating security requirements as core priorities from the get-go. All too often, we encounter developers seeking to validate their work as OWASP compliant just prior to launch, almost as an afterthought.

Such a strategy is fraught with risk.

At such a late stage in the development pipeline, vulnerabilities that would have been easily rectified earlier, may become significantly more complex, timely and expensive to remediate.

This tendency to leave security considerations for late in the development pipeline stems from developers being educated to focus primarily on getting a web app built and working efficiently, often within tight deadlines. With this mindset, security is not the central concern because security-related issues are usually addressed by security specialists rather than developers.

One way in which this lack of focus on security manifests itself is in relation to the use of open source software. Increasingly, developers rely on open source components to quickly and easily add features to their products. This avoids the need to develop every component themselves from scratch.

However, frequently we see open source software being used that is prone to vulnerabilities. On many occasions, developers conduct cursory checks of the open source software in use, without delving deeply enough to identify potential flaws. Once any vulnerabilities in the open source software are identified, having already been integrated into the app, and usually at a late stage in the development, a significant risk exists that the project timeline will be set back, often at significant cost.   

This misunderstanding surrounding how and why OWASP should be used in the advancement of secure, high-quality coding is concerning. According to current OWASP chairman Martin Knobloch, the list should be a guide to writing good code. It was never designed to be a validating or box-ticking exercise after the code is written.

“ A guide on how to validate is not a guide on how to build in security.
You need to make security explicit. ”

OWASP chairman Martin Knobloch


Integrating Security and Privacy from the Outset

Knobloch’s message is one we strongly endorse.

We always urge web app developers to consider security and privacy from the outset of a project.

At an early stage of the development pipeline, you should explicitly specify minimum security and privacy requirements for the application. This should be done alongside your plans for how the app will ultimately be utilised within an operational environment.

Take time to establish a tracking system that includes ongoing testing for security vulnerabilities, as well as any remediation work that may be required to address them. Including this within your workflow should reduce the risk of major surprises at the end of the development pipeline and will help ensure your product release is not delayed due to unforeseen security vulnerabilities. 

Another strategy you can adopt is to integrate security specialists within the development team. Bringing together developers and security specialists allows everyone to bring their expertise to the table from the outset. The security specialists can ensure the vulnerabilities identified in the OWASP Top 10 are addressed at each stage of the project.

Remember – you have a big incentive to incorporate strategies that integrate security and privacy considerations from the very early planning stages: COST.

Analysis shows that a bug identified and fixed at the design stage of the development pipeline can be up to 60 x cheaper than attempting to remediate it with a patch after release. 



OWASP and the Secure Development Lifecycle

While embracing the OWASP guidelines is an important first step in developing a secure web app, of equal importance is the development lifecycle, so you can ensure you’re incorporating security at all the right stages.

This is best achieved by adopting the timeline recommendations advocated by Microsoft in the Security Development Lifecycle (SDL). This approach lays out all the security activities you should embrace in the development lifecycle, and the order in which you should implement them.

Following the SDL helps developers build more secure software and address security compliance requirements while reducing development costs by helping ensure security flaws are not discovered at the last minute. Comprising a collection of mandatory security activities, they are presented in the order in which they should occur and grouped by the phases of the traditional software development life cycle.

“The optimal time to influence a project’s design trustworthiness is “early in its life cycle. It is critically important to consider security and privacy concerns carefully during the design phase. Mitigation of security and privacy issues is much less expensive when performed during the opening stages of a project life cycle. Project teams should refrain from the practice of ‘bolting on’ security and privacy features and mitigations near the end of a project’s development.”

Microsoft SDL

By considering security and privacy in the ‘Requirements’ and ‘Design’ stages, which are the first two stages of the SDL, you will have an effective framework for incorporating the OWASP Top 10 and it will help you achieve the Shift-Left approach you need.

OWASP and the Secure Development Lifecycle

With Microsoft’s SDL, the key is to start early. Explicitly consider security from the beginning of the process, at the same time as you’re refining and designing your project.





Establish Security Requirements

  • Analyse security and privacy requirements from the outset of the initial planning phase.
  • This allows your development team to clearly identify what security measures need to be implemented at each stage of the development pipeline.
  • This also ensures the integration of security and privacy measures in a way that does not disrupt development plans and schedules.
  • Consider the security and privacy measures that will be required once the app is developed and running in a typical operating environment.
  • Establish a tracking system to ensure security measures are regularly tested throughout the development process, allowing time for additional work to remediate any identified vulnerabilities.

Create Quality Gates & Bug Bars

  • Use Quality Gates and Bug Bars to establish minimum baselines of acceptable security and privacy levels.
  • A Bug Bar is a fixed maximum number of bugs you’re prepared to accept. Bug Bars can be set for different types of bugs, depending on the severity of the bug and the risk it poses to your app.
  • This will enhance your ability to understand the risk levels associated with various security issues.
  • It will also enhance your team’s capacity to identify and fix bugs throughout the pipeline, prioritising “critical” or “important” bugs that pose greater levels of risk.


Security & Privacy Risk Assessment

  • Conduct Security Risk Assessments (SRAs) and Privacy Risk Assessments (PRAs) to identify areas for deeper investigation.
  • These assessments will help you determine:
    · Any threat modelling requirements before release.
    · Any Penetration Testing requirements by external experts such as Shearwater.
    · What your Privacy Impact Rating (PIR) is:
    ⋅ High – transferring Personally Identifiable Information (PII).
    ⋅ Moderate – transferring anonymous data.
    ⋅ Low – no data transfers.





Establish Design Requirements

  • This phase focuses on more specific design requirements including:
    · Security and Privacy design specifications.
    · Minimal cryptographic design specifications.
  • The design specifications should describe features that will be directly exposed to users and how all functionality should be securely deployed.
  • Focus on building in ‘secure features’ where all aspects of the functionality are well engineered with respect to Security and Privacy, as opposed to bolting on ‘security features’ which describes specific functionality with security implications.

Analyse Attack Surface

  • Involves reducing risk by giving attackers less opportunity to exploit vulnerabilities.
  • This is achieved by restricting access levels and employing the principle of least privilege with layered defences.

Threat Modelling

  • A team exercise involving managers, developers and testers.
  • It is the primary security analysis task during the design stage of the pipeline.
  • It allows development teams to consider the security implications of their web app designs in the context of the planned operational environment.

Adopted individually, each of these measures provides a degree of enhanced security. However, the full benefit comes from implementing all of them as integral parts of the development process.



How Shearwater can help you

Vulnerable web applications are the most common point of attack on an organisation.

Attacks via web apps have resulted in the theft of millions of credit cards, and
compromised critical information for organisations and end users.

Reduce your vulnerability to attack with Shearwater’s team of expert Penetration Testers.

We understand how to protect your web app from the most common vulnerabilities identified by the OWASP Top 10 list. With a Web Application Penetration Test, we will perform an authorised ethical hacking attempt on your web application.

The aim of this test is to identify and exploit vulnerabilities relating to:

  • Authorisation;
  • Security configuration; and
  • Data protection mechanisms.

We offer in-depth executive level reporting which serves as a risk minimisation tool for management, and a technical document – listing vulnerabilities prioritised according to risk level – for the internal security team.

The report also provides access to mitigation strategies based on Shearwater’s key insights into the cyber-threat landscape.

By following the OWASP Top 10 guidelines in conjunction with the Secure Development Lifecycle timeline, and then having your web app expertly tested by Shearwater’s team of Penetration Testers, your organisation stands the best chance of reducing your web app’s risk profile.

What are the different types of penetration testing?

In this blog article, we describe the different types of penetration testing and various approaches (black, white and grey box) that make up the general range of strategies employed to conduct a penetration test.

There are many different testing methodologies. They are generally categorised into:

What are the different types of penetration testing?

  • Networks (external, internal, mobile, wireless)
  • Applications (mobile, Web, Web service/API)
  • Physical security & Social engineering
    • Phishing
  • Secure code reviews
  • Red teaming


External Network Penetration Testing

An external penetration test is an authorised hacking attempt against your organisation’s Internet facing servers, such as Web and email servers and ecommerce infrastructure. This test aims to harden the external facing network against attackers attempting to compromise vulnerable hosts from outside your organisation’s perimeter.

Internal Network Penetration Testing

Internal penetration testing aims to identify and exploit vulnerabilities from within your organisation’s perimeter defences. Testers are typically given onsite access (similar to the way employees or contractors could connect to an internal environment). They then attempt to escalate privileges and gain access to sensitive information. For certain environments, such as data centres, jump hosts are used to test remotely via your organisation’s VPN access.

Mobile Device Penetration Testing

BYOD has significantly increased the cyberthreat surface by creating a variable endpoint ecosystem. Employee personal information may be used for social engineering, allowing a cybercriminal to gain a foothold into your organisation, and employee access credentials may be used to attack the portal that the mobile device connects to and compromise sensitive information.

Mobile device penetration testing attempts to bypass authentication on mobile devices including laptops, tablets and smartphones to assess whether stolen or lost devices can be compromised and then used as a pivot to compromise an organisation’s sensitive information. Testing can also assess third party MDM implementations and devices configured with MDM policies.

Wireless Penetration Testing

An insecure Wi-Fi network opens your organisation to a myriad of attacks that could compromise your sensitive information. A Wireless Penetration test aims to detect and exploit vulnerabilities in security controls employed by a number of wireless technologies and standards, misconfigured access points and weak security protocols.



Mobile App Penetration Testing

Mobile App penetration testing is an authorised and simulated hacking attempt against a native mobile application (such as Android, Windows and iOS) that aims to identify and exploit vulnerabilities in an application, and the way it interacts and transfers data with back-end systems.

Web Application Penetration Testing

Untested applications remain the most common point of attack on an organisation. Web application vulnerabilities have resulted in the theft of millions of credit cards and compromised sensitive information for organisations and end users. A Web Application Penetration test targets open-source and commercial software and custom web applications to identify and exploit vulnerabilities relating to authorisation, security configuration and data protection mechanisms.

Web application vulnerabilities have resulted in the theft of millions of credit cards and compromised sensitive information.

API Penetration Testing, including Web Services

A Web Service Penetration Test aims to identify and exploit vulnerabilities in the architecture and configuration of a web service. The purpose of this test is to fortify secure data exchange by demonstrating the ways a cyberattack can compromise a web service and gain access to an organisation’s information assets.


Physical & Social Engineering Penetration Testing

Physical penetration testing is the process of identifying and bypassing security controls implemented on buildings, data centres and employee operational security knowledge. All targets and exclusions follow specific pre-agreed criteria. To prevent negative business impacts during testing, the following methods are generally used: tagging unsecured devices, sending an email from unattended devices, identifying and photographing exposed paper documents with sensitive information (in line with the client’s security standards).

Closely linked is: Social engineering penetration testing which replicates how cybercriminals target employees to gain privileged access to protected systems and information by:

  • Tailgating – the tester will attempt to follow employees into secure areas.
  • Pretexting – the tester will impersonate an employee and attempt to persuade employees to divulge confidential information.
  • Baiting – the tester will leave USB keys, infected with malware, inside and outside the building for employees to find and insert into a computer.

Phishing Attacks Risk Assessment & Penetration Testing

A specialised type of social engineering is phishing. It takes only one user to fall prey to a phishing scam for an attacker to gain a foothold in your organisation. A phishing risk assessment and penetration testing service helps you to understand your organisation’s phishing posture and prepare for ransomware and other phishing introduced threats.

A phishing risk assessment and penetration testing service helps you to understand your organisation’s phishing posture.

Baseline Penetration Testing allows you to measure your organisation’s phishing risk. A simulated phishing campaign is sent to all end-users, or just a select control group. By tracking open and click-through rates, the campaign provides key stakeholders with a baseline of the organisation’s phishing risk.

A more advanced Phishing Penetration Test also assesses the performance of the security stack at the desktop/server level and across the inbound and outbound points of the network. These technologies include file extension handling, port filtering, MIMES, type checking, anti-virus, application whitelisting, and proxy filtering.


Red Teaming

A red teaming assessment is the process of using all available resources (broad scope) to demonstrate the impact of a targeted cyberattack. This can include identifying and bypassing security controls implemented on buildings, websites, servers, networks or by finding ways to abuse or bypass policy or processes implemented within an organisation. By conducting this type of assessment, you can understand the effectiveness of current security controls and adherence to security policies and procedures in every way that they are exposed to threats.

During a red teaming assessment, testers will mimic the behaviours of a malicious hacker to understand what sort of vulnerabilities exist and what information they may be able to compromise.


Secure code Reviews

Secure code reviews focus on identifying vulnerabilities in application source code that could allow exploitation or abuse.

Testers conduct research on how the application is used on a day-to-day basis, identifying its design and business objectives and the existing security controls that have been implemented. Then, using specialised security source code review software, the source code is analysed to identify application inputs, the attack surface, simple coding errors and vulnerabilities.

The vulnerabilities identified include those that can be identified through web application penetration testing as well as many others. During this stage, a hands-on approach is also taken, not only to confirm valid findings, but to identify possible logic flaws or design failures in the application which cannot be discovered using automated processes. Where required, and if possible, weaknesses identified through the discovery stage can be confirmed through actual exploitation. This allows you to understand your risk level to the most accurate degree.


Which approach: Black, White or Grey Box?

You will discuss the best approach, to meet your organisation’s needs, with your penetration testing provider during the project scoping stage. Your chosen provider will work with you to develop a customised test plan that will identify the objectives, scope, approach, limitations (e.g. avoidance of disruption of business operations) and legal and confidentiality requirements.


White Box

Grey Box

Black Box

All the information that testers require is provided/accessible.


Limited information is provided to testers (e.g. logins)


No information is shared with the penetration testing team, to simulate an attack from a malicious hacker.


This is useful for:

  • Facilitating testing of all known and unknown vulnerabilities.

  • Organisations new to penetration testing, where a pen test is completed following a vulnerability assessment.

  • Where the aim is to also simulate an internal attack.

This is useful for:

  • Where the aim is to simulate an internal attack or an attack from a potential disgruntled employee or from a lost/compromised employee laptop or phone.

This is useful for:

  • Experiencing a simulated malicious attack either as a monitored, learning experience or as a defensive exercise.

  • Understanding what information is available on the Internet that can be used by a hacker for reconnaissance purposes.



Generally, the less mature an organisation’s cybersecurity and information security management program, the less aggressive and the more collaborative the approach. However, an organisation with a more mature program (and an identified high risk of cyberattack) may cycle between black box, grey box and white box approaches along with regular, ongoing vulnerability assessments. In terms of ROI for a new client, the best approach is white box.


Do you forewarn your IT Team?

Another important consideration is whether the management team informs the IT security team about the date and scope of testing. While it is usual for all stakeholders to be informed, there are sometimes specific requirements not to do so, for example, in the case of social engineering penetration testing. A red teaming exercise may use either approach. Borrowed from military terminology, the red team (penetration testing team) can attempt to exploit vulnerabilities either with the blue team’s (IT security team) prior knowledge and collaboration or without. Both methods provide valuable learning experiences for the blue team.

The decision of whether to inform the IT security team, in combination with the approaches and testing methodologies described above, make up the general range of strategies employed to conduct a penetration test.

We hope you’ve found this blog article useful. For more information about penetration testing, download A Guide for First-time Penetration Testing Buyers here >>  In this free guide we answer the questions commonly asked by first-time penetration testing buyers and provide guidance to help you achieve a successful penetration testing experience.

Penetration Testing Complete Guide

Questions & More Information 

Do you have a question about penetration testing? Contact Us today to speak to one of Shearwater’s certified Ethical Hackers. They have extensive experience in providing penetration testing services and assisting clients to achieve and maintain accreditation.


What is the difference between vulnerability assessment and penetration testing?

There is often confusion around the role of a vulnerability assessment versus a penetration test. This is compounded by unscrupulous security vendors presenting (and pricing) a vulnerability assessment as a penetration test. Aside from poor ROI, this can give an organisation a false sense of security, when in fact they have only received a basic level service. In the following blog article, we explain the difference, and how regular vulnerability assessments and penetration testing should work together to enhance an organisation’s security posture.

What is a Vulnerability Assessment?

A vulnerability assessment is the process of identifying if an organisation’s systems/applications have potential known security vulnerabilities. It is an automated scan(s) followed by the generation of a report containing a prioritised list of the vulnerabilities found, the severity and generic remediation advice. This is a useful auditing tool for the security team to remediate any errors that could allow a cybercriminal to gain access to the organisation’s systems and sensitive data. The quality of the results is dependent on the quality/recency of the vulnerability scanning software and the ability of the security professional interpreting the results.

How is it different from Penetration Testing?

Penetration testing has much greater potential breadth of scope (e.g. social engineering) and depth than a vulnerability assessment. It should only be conducted by certified cybersecurity professionals who use their experience and technical abilities to mimic multiple types of attack used by cybercriminals, targeting both known and unknown vulnerabilities. Vulnerability assessments are often used to scope a penetration test or as a research tool during the reconnaissance phase of a penetration test. Unlike a vulnerability scan, where identified vulnerabilities are not exploited, in a penetration test, the tester will modify their approach until they can provide proof of vulnerability through exploitation and gain access to the secure systems or stored sensitive information that a malicious attack could compromise.

A penetration test report is customised to the organisation and the scope of the engagement and provides the data that is critical to secure an organisation’s systems and stored sensitive information. It supplies the management team with a fast and proven benchmark of the organisation’s level of risk, at a given moment in time, and prioritises the vulnerabilities found, in order of severity, with detailed and customised advice to expediate remediation. This then provides the IT security team with the information they require to fast-track remediation work, demonstrates the ROI of existing security tools and facilitates the management team’s confident approval of security expenditure.

A penetration testing report supplies the management team with a fast and proven benchmark of the organisation’s level of risk, at a given moment in time, and prioritises the vulnerabilities found.

The Difference Between Vulnerability Assessment and Penetration Testing

The key characteristics of a vulnerability assessment and penetration test are compared in the table below.

Vulnerability Assessment

Penetration Test


To scan systems to identify potential ‘known’ vulnerabilities and provide generic remediation advice to improve the security of scanned target(s).


To identify and demonstrate proof of exploit and provide customised remediation advice to improve the security of the scoped target(s).


  • Automated process

  • Scanning software scans the entire target(s).

  • Scanning software includes networks, web applications, source code and ASV for PCI DSS

  • Scanning software has signatures to identify unpatched or out-of-date software updates, incomplete deployment of security software, bugs and open ports.

  • Scanning software is limited to identify only vulnerabilities it has signatures for. It cannot find vulnerabilities that are unknown.

  • Results may include false positives and negatives. Results identify potential vulnerabilities.


  • Largely a manual process – using a mix of penetration testing software and custom written exploits

  • The tester may use a vulnerability assessment in the reconnaissance phase of a penetration test and then go on to exploit chosen prioritised vulnerabilities.

  • Demonstrates actual risk by emulating a cybercriminal

  • Types of penetration testing include: networks (external, internal, mobile, wireless), applications (mobile, Web, Web service/API), physical security, social engineering and phishing, secure code reviews and red teaming.

  • Able to exploit known and unknown vulnerabilities

  • Testing is rarely exhaustive – tester focuses attention within the scope of the engagement


An automated report with a prioritised list of the vulnerabilities found, the severity and generic remediation advice.


A hand-written report listing the vulnerabilities and exploits, categorised according to risk level and recommendations for remediation based on key insights into the cyberthreat landscape.

Recommended frequency

Outside of meeting a specific compliance requirement, vulnerability scans should be performed externally to the network and from within at least quarterly, or more frequently for organisations with a high-risk profile.

Recommended frequency

Outside of meeting a specific compliance requirement, penetration tests should be performed at least annually, or more frequently for organisations with a high-risk profile.


Together, vulnerability assessments and penetration testing enhance an organisation’s security posture. Both are essential components for achieving a strong cybersecurity and information security program – and a requirement for achieving and maintaining compliance.

We hope you’ve found this blog article useful. For more information about penetration testing, download A Guide for First-time Penetration Testing Buyers here >>  In this free guide we answer the questions commonly asked by first-time penetration testing buyers and provide guidance to help you achieve a successful penetration testing experience.

Penetration Testing Complete Guide

Questions & More Information 

Do you have a question about penetration testing? Contact Us today to speak to one of Shearwater’s certified Ethical Hackers. They have extensive experience in providing penetration testing services and assisting clients to achieve and maintain accreditation. 

Why should I complete penetration testing if I don’t need to be compliant?

For an organisation, not yet, impacted by cybercrime, penetration testing outside of compliance may seem like an additional, unwelcome expense. In the following blog article, we explain how penetration testing is good for (and may even save) your business.

A Penetration Test (also known as ethical hacking) is an authorised hacking attempt, targeting all, or specified areas, of your organisation’s IT network infrastructure, applications and employees. The objective is to strengthen your organisation’s security defences by providing a report identifying and prioritising areas that are susceptible to compromise and advising on remediation. This allows you to understand your level of risk and focus time, effort and money into protecting the areas identified – providing a fast and cost-effective way to enhance your organisation’s security posture and defend against cyberattack.

A penetration test allows you to understand your level of risk and focus time, effort and money into protecting the areas identified.

We could give many reasons why you should conduct penetration testing outside of a compliance requirement, but here are our top 3.

1. Protection from the growing threat of cyberattacks

Cybercrime has risen exponentially, with cybersecurity breaches regularly making national (and even international) news, often the result of a targeted cyberattack. What is less well publicised are the more pervasive, lower profile breaches (often in-passing, opportunistic in nature) which are increasingly impacting small and medium-sized organisations.

For organisations that are yet to adopt a proactive approach to cybersecurity, complacency can be disastrous. Perhaps they are a mid-sized manufacturing, transport or construction business and think they’re not an attractive enough target for a cybercriminal. Think again. With the increase in automated cyberattacks (targeting all and any), and the prevalence of Business Email Compromise attacks which can gain a foothold into an organisation via a less well guarded supplier, you can no longer hope that cybercriminals won’t take an interest in your business.

The cost and inconvenience of recovering from a cyberattack is high (currently averaging US$3.86 million1). In addition to the cost and lost time fixing the damage to your systems and data, plus any potential fines, there is also damage to your organisation’s reputation that can set you back years. Many organisations simply cannot foot the bill and the business is bankrupt.

Penetration testing can markedly reduce the risk of a breach.

2. Your organisation already has a compliance requirement (that you didn’t know about)

It’s not uncommon for organisations seeking penetration testing services to discover that they already had a compliance requirement. For example, if your organisation processes, stores or transmits credit card data, you need to comply with the PCI DSS standard  or risk being fined if your organisation is hacked and customer credit card data is stolen.

And from February 2018, the amended Australian privacy act made the disclosure of cyber breaches to regulators and shareholders mandatory. The penalty for not doing so can be up to $1.8 million for organisations, plus additional fines of up to $360,000 for each board member.

Your trusted information security partner can inform you of any compliance requirements – and work with you to ensure you achieve and maintain compliance.

3. Business readiness

It’s likely that the requirement to meet a cybersecurity compliance standard will become more common in the future, as a result of ever-evolving compliance benchmarks. You may find that the tender you’d like to pitch for or the large client your organisation has just won may require you to meet an information security management compliance standard, such as PCI DSS  or ISO 27001  to be one of their preferred suppliers.

Penetration testing will help your organisation to plan and improve its cybersecurity and it may then be quicker, easier and less costly to achieve compliance, when required.



We recommend working with a certified cybersecurity provider to conduct a risk assessment to determine your organisation’s level of risk. You may be surprised at the level of risk your organisation is currently exposed to and may even discover a compliance requirement needing urgent attention.

You can then develop your cybersecurity program and employ an agile approach, using the tools at your IT department’s disposal and your provider’s (such as vulnerability assessments and penetration testing) to measure and evolve the security of your networks and applications to maintain a strong defence against cyberattacks.

We hope you’ve found this blog article useful. For more information about penetration testing, download A Guide for First-time Penetration Testing Buyers here >>  In this free guide we answer the questions commonly asked by first-time penetration testing buyers and provide guidance to help you achieve a successful penetration testing experience.

Penetration Testing Complete Guide

Questions & More Information 

Do you have a question about penetration testing? Contact Us today to speak to one of Shearwater’s certified Ethical Hackers. They have extensive experience in providing penetration testing services and assisting clients to achieve and maintain accreditation.


1. 2018 Cost of a Data Breach Study: Australia, Ponemon Institute LLC, July 2018

How do you determine the scope of a penetration test?

Guidance on best practice scoping and the key pitfalls to avoid

The objectives of penetration testing are to provide a level of assurance to match the risk profile (including any compliance requirements) for your organisation, whilst also providing a good ROI. How well your chosen penetration testing provider scopes your penetration test will determine the success of this balance. In this blog article, we describe 3 common variables affecting the scope and cost penetration testing services and the key pitfalls to avoid.

Scoping takes place during the (generally free) initial project scoping phase of a penetration testing engagement. During this phase, a penetration testing expert will ask questions to understand your organisation’s aims and objectives (e.g. achieving compliance) and research the attack surface to be tested to develop a customised test plan and quote. There is no universal price or timeframe for a penetration test, in fact, if you are presented with either it should serve as a red flag not to proceed with that provider.

Generally, scoping errors can go one of two ways, both of which are bad news for clients.

Underquoting: If the provider underquotes, they will be under pressure to make up time and may cut corners – or, perhaps, their pricing model relies heavily on automated scanning tools, resulting in a poorer quality service.

Overquoting: Inexperienced providers may overquote to incorporate scoping errors and the cost of testing tools or the provider’s standard rates may be aimed at large clients with complex testing needs, resulting in inflated costs.

What can affect the scope (and cost) of a penetration test?

The following common variables will affect the scope and cost of penetration testing services:

  1. Pricing methodology: Target count vs measuring the attack surface
  2. Size and complexity of the project
  3. Size and specialisation of the penetration testing provider


1. Pricing methodology: Target count vs measuring the attack surface

The most accurate methodology, offering the best Return on Investment (ROI) for clients, is to measure the attack surface – the sum of potential attack vectors (any parameter that can be attacked) in the environment/app to be tested. This approach ensures that sufficient time is allocated to focus on each attack vector and will deliver comprehensive results for the best value.

A target-count pricing methodology (price per IP address or price per page/click) can only provide a rough order of magnitude and shouldn’t be relied upon in isolation or it will likely result in a poorer ROI; with clients potentially overpaying on targets with no/a low attack surface and/or penetration testing providers relying heavily on automated vulnerability scanning on occasions where they find they have underquoted.

2. Size and complexity of the project

The size and complexity of the attack surface is calculated and translated into number of hours/days/weeks of work. The larger and more complex a project, the higher the cost. This takes into consideration any special requirements, e.g. testing outside of normal working hours, onsite, in a production environment and on third party infrastructure, e.g. cloud services. The approach and tools used will also impact the scope and cost. For example, a black box test would likely have a longer reconnaissance phase than a white box test and would be likely to cost more.

An experienced penetration test provider can help their client to develop a risk assessment to identify and focus on defending critical assets.

If the initial scope of a project appears too large and costly, an experienced penetration test provider can help their client to develop a risk assessment to identify and focus on defending critical assets. For example, for PCI DSS compliance – reducing the number of systems connected to, or within the same network segment as, the cardholder data environment will descope a large environment from compliance requirements and keep risk and the cost of achieving and maintaining compliance down.

3. Size and specialisation of the penetration testing provider

Clients may aim to ensure the quality of their penetration testing services by engaging large cybersecurity consultancies or their regular large IT outsourced partner, who has a penetration testing offering. This can be problematic. Large consultancies tend to predominantly work with enterprise clients on complex projects attracting higher daily rates. If your organisation does not meet this profile – e.g. a SME with straightforward testing requirements – it may be more cost effective to source a provider who also services smaller organisations; or it could be akin to hiring a barrister to challenge a parking fine. It is also best practice to engage a provider who is independent from your day-to-day IT operations who can look at your organisation’s IT environment from an outsider’s perspective.

At the other end of the scale, a markedly low quoted price may be indicative of a lack of industry accreditation and/or poor project scoping. The industry has defined minimum standards for providers who have the capability and skills to conduct penetration testing activities. The key requirement for assessing a providers’ capability is the CREST designation. If the provider is not a CREST accredited penetration testing firm, they have not demonstrated the knowledge, skills and understanding to be trusted with your testing activities.

A CREST certified provider that specialises in, and conducts numerous, penetration tests will have the most accurate scoping capabilities to provide you with the best balance of quality service at a competitive price. They will offer you a broad range of penetration testing services and have the latest tools and techniques, plus the ability to author their own custom tools – to give you the best value. They will have numerous multi-certified, experienced penetration testing consultants with preapproved security clearance and will have a process to deliver your penetration testing project as efficiently and cost effectively as possible. And this accumulated knowledge and experience will also provide you with a detailed penetration testing report with valuable insights into remediation actions.

It’s worth taking the time to research and select a proven, reputable penetration testing provider and then to commit to conducting regular testing. This will not only provide the best level of security for your organisation but also deliver the best ROI.

We hope you’ve found this blog article useful. For more information about penetration testing, download A Guide for First-time Penetration Testing Buyers here >>  In this free guide we answer the questions commonly asked by first-time penetration testing buyers and provide guidance to help you achieve a successful penetration testing experience.

Penetration Testing Complete Guide

Questions & More Information 

Do you have a question about penetration testing? Contact Us today to speak to one of Shearwater’s certified Ethical Hackers. They have extensive experience in providing penetration testing services and assisting clients to achieve and maintain accreditation.

How to Avoid Common Penetration Testing Pitfalls

Guidance for Penetration Testing Buyers

There are many pitfalls and mistakes that organisations using, or considering using, penetration testing services can easily avoid. In the following blog article, we discuss ‘what not to do’ to ensure you receive the best penetration testing outcomes.

There are many common penetration testing pitfalls and mistakes that you can easily avoid by:

  1. Researching and selecting the right provider
  2. Having an information security mindset
  3. Not becoming complacent.


1. Choose the right provider

Many pitfalls can be avoided by taking the time to research and select a solid provider.

Pitfalls relating to providers include:

  • Purchasing a penetration test that is a glorified vulnerability scan (you can run these yourself – for free!) and a report that is automated, contains many false positives and negatives and generic guidance.
  • Paying for a methodology that charges for testing areas that do not require testing. To ensure that you understand and receive a correctly scoped service, refer to our blog article How do you determine the scope of a penetration test? >>
  • The penetration tester does not have adequate security clearance – resulting in time lost while clearance is obtained.
  • Engaging a large provider who has a pricing model aimed at the needs of enterprise clients, resulting in potentially high costs.
  • Engaging your existing provider who is not a specialist in penetration testing, resulting in potentially higher costs and a poor quality service than could have be achieved by engaging a provider that specialises in penetration testing.
  • Engaging a ‘quick and low cost’ service to achieve basic compliance. You get what you pay for – your organisation may just meet compliance standards but have received a service that is insufficient for its level of risk.

For the 9 characteristics of proficient penetration testing providers and the research you should do before engaging a provider, read our blog article How do you select a penetration testing provider? >>

2. Have an information security mindset

Having an information security mindset is important, not only for the IT security team and management team, but also every employee.

The following pitfalls reflect how not having an information security mindset can be dangerous for your organisation.

  • “Cybercriminals only target large, well known organisations, SMEs are off their radar.”
    This reveals a lack of understanding of the threats posed by automated cyberattack and to the suppliers of a Business Email Compromise attack target. If you need to convince your management team about the benefits of penetration testing, have them read our blog article on the ROI of Penetration Testing.
  • “There is no need for a pen test – the IT department can find any holes in our security.”
    Your penetration tester should be an external, neutral party. The person finding the issues should not be the person responsible for fixing them as there will be blind spots and assumptions that will skew the results. Penetration testing can help validate your IT department’s efforts.
  • “Security was taken care of when the provider installed the system.”
    A set-and-forget approach cannot apply to cybersecurity and information security management. Cybersecurity threats are continually evolving and have multiple points of attack and if your organisation does not keep pace with the level of threat, it is at increased risk.
  • “The security team don’t collaborate with the development team (and vice versa) and neither will partner with the pen testing team.”
    To effectively remediate security issues and prevent future issues, there needs to be collaboration between IT teams throughout any development and penetration testing process. Egos aside, a collaborative approach is essential to achieve ongoing security.
  • “This cybersecurity training/policy doesn’t apply to me.”
    Providing cybersecurity training for your employees is only effective if they complete it and demonstrate the learning outcomes. This especially applies to system administrators and other privileged account holders.
  • “It’s my cloud provider’s responsibility.”
    In the case of a breach, regardless of whether it is a cloud provider’s ‘fault’, it is ultimately your organisation’s responsibility to undertake due diligence to ensure the protection of critical data and customer information. You can request permission to conduct a penetration test on a cloud-based application. If your provider refuses, you can request a letter of attestation stating that they conduct regular penetration testing and have met the security requirements. If they will not provide a letter of attestation, find a provider that will. For more information about roles and responsibilities and the critical activities and controls you need to put in place to reduce risk and utilise cloud computing with confidence, watch our webinar Securing your Cloud Data: Practical Advice to Mitigate Risk >>

3. Avoid becoming complacent

It’s important not to become complacent. Achieving best-practice cybersecurity and information security management is an ongoing and evolving process.

  • “My organisation has done a penetration test, therefore it’s secure.”
    The purpose of a penetration test is to help identify vulnerabilities and suggest remediation. It’s up to you to implement the remediation and commit to maintaining security – such as adding ongoing cybersecurity and information security activities to your organisation’s security management program. And unless the scope was for an end-to-end penetration test, covering the entire attack surface, the test may have focused on targeted areas only.
  • “My organisation is compliant, therefore it’s secure.”
    If your organisation takes a proactive approach to cybersecurity and information security threats and employs measures to meet your organisation’s level of risk, it’s likely that it is well protected – and compliant. If, however, your approach is to just meet the basic requirements to achieve compliance, your organisation may be compliant yet at a high risk of compromise.
  • “My organisation has so much testing that the network is bulletproof.”
    Investing in protecting your IT technology assets is meaningless if you do not also recognise the potential risk from social engineering and phishing. Education must include not only the security team (system admins, database admins, developers) but all employees. Regular penetration testing that includes social engineering will help to identify and benchmark risk, and an ongoing phishing training program can provide your organisation with an ongoing, cost-effective solution. 

We hope you’ve found this blog article useful. For more information about penetration testing, download A Guide for First-time Penetration Testing Buyers here >>  In this free guide we answer the questions commonly asked by first-time penetration testing buyers and provide guidance to help you achieve a successful penetration testing experience.

Penetration Testing Complete Guide

Questions & More Information 

Do you have a question about penetration testing? Contact Us today to speak to one of Shearwater’s certified Ethical Hackers. They have extensive experience in providing penetration testing services and assisting clients to achieve and maintain accreditation.

Demonstrating the ROI of Security Penetration Testing to Management

How do you demonstrate the ROI of Security Penetration testing ? From the management team’s point of view, making the decision to commit to an ongoing cybersecurity budget may be seen as adding yet another expense, with little visibility of a return on investment (ROI). This is particularly true for organisations who are not involved in the riskier areas of application development or ecommerce – perhaps they are a mid-sized manufacturing, transport or construction business – and think they’re not an attractive enough target for a cybercriminal. Think again!

High profile cybersecurity breaches regularly make national and even international news, and are often the result of a targeted attack. What is less well publicised are the more pervasive, lower profile breaches which are more opportunistic in nature and increasingly impact small and medium-sized organisations. This trend can be linked to the sophisticated way in which cyberattacks can now be automated and the introduction of new vulnerabilities resulting from the adoption of new technology and working practices (remote working and BYOD, such as laptops, tablets and phones).

Lower profile breaches which are more opportunistic in nature can impact small and medium-sized organisations.

In a rapidly changing technological landscape, organisations must not only keep pace with the speed of innovation, but also the resulting risks to information security.

Increasingly, organisations are incorporating cybersecurity into their overall risk management policy and business objectives into their security programs, with cybersecurity and information security management fast becoming the domain of management teams, not just the internal IT team. These organisations recognise that cybersecurity and information security are, ultimately, just like any other risk that they face in their business and therefore need to be managed like all those other risks, be they legal, operational, financial etc. They understand not only that they can’t afford a ‘head in the sand’ approach, but that good security practices (and compliance) is a competitive advantage.

For the organisations (predominantly SMEs), who are yet to adopt a more proactive approach to cybersecurity, complacency can be disastrous. With the increase in automated cyberattacks, you can no longer hope that cybercriminals won’t take an interest in your business.

From February 2018, the amended Australian privacy act made the disclosure of cyber breaches to regulators and shareholders mandatory. The penalty for not doing so can be up to $1.8 million for organisations and, with the inclusion of additional fines of up to $360,000 for each board member, the message is clear; take cybersecurity seriously.

Read how specialist web solutions provider The Reach Agency uses regular penetration testing to increase their competitive advantage >>

So what value does a penetration test provide?

A penetration test provides your management team with an extremely fast and proven benchmark of the organisation’s level of risk, at a given moment in time, and prioritises the vulnerabilities found, in order of severity, with advice to expedite remediation. This then provides your IT security team with the information they require to fast-track remediation work, demonstrates the ROI of existing security tools and facilitates the management team’s confident approval of security expenditure.

Explain to management that you can acquire this data in one of two ways, either proactively or via incident post-mortem and, put simply, investing in penetration testing is preferable to responding to a breach from a malicious hacker. The decision of whether to invest in penetration testing is as simple as asking: “Do you want to choose your hacker?”

The difference between an Ethical Hacker and Malicious Hacker

The below is a simple comparison between controlled expenditure on security penetration testing and the uncontrolled chaos that results from having your systems compromised by a malicious hacker. Download this infographic in PDF format here>>


Ethical Hacker

Malicious Hacker

 Intention is to help your organisation to succeed

Intention is to extort money or damage your organisation

 Known, proven, highly trained IT professional has access to your IT infrastructure in partnership with your IT department

 Unknown hacker has access to your IT infrastructure

 Careful with your IT infrastructure

 Careless with your IT infrastructure

  You control:

  • Cost (average cost of a pen test $7,000+)

  • Scope and methodology – non-disruptive

  • Timing – convenient

They control:

  • Cost (average cost of a breach US$3.86 million)

  • Scope and methodology – disruptive 

  • Timing – inconvenient

  At the conclusion of testing you are provided with:

  • A comprehensive report listing the vulnerabilities and exploits categorised according to risk level (or at time of discovery for critical/high risk vulnerabilities) and recommendations for remediation to improve your organisation’s IT security.

  • Debriefing for Executives and IT team.

Any data obtained during the test will be treated as confidential and will be returned or destroyed at the conclusion.

 At the conclusion of a malicious breach you could face:

  • A potential ransom

  • Exploited intellectual property

  • Exploited customer data

  • Potential fines and legal ramifications

  • Damaged IT infrastructure and code that takes time/money to investigate and remediate

The whereabouts of any data obtained during the breach is unknown.


Proactive and empowering experience, Improved IT security/compliance is achieved, maintain customer confidence and brand loyalty, security stakeholders have peace of mind.


Reactive and disempowering experience, damaged IT systems, lost customer confidence, damage to brand loyalty, loss of revenue, loss of share value, security stakeholders have sleepless nights/potential job losses. May bankrupt SMEs.



When compared in this way, the benefits of investing in penetration testing are self-evident.

We hope you’ve found this blog article useful. For more information about penetration testing, download A Guide for First-time Penetration Testing Buyers here >>  In this free guide we answer the questions commonly asked by first-time penetration buyers and provide guidance to help you achieve a successful penetration testing experience.

Penetration Testing Complete Guide

Questions & More Information 

Do you have a question about penetration testing? Contact Us today to speak to Shearwater’s certified Ethical Hacking Team. They have extensive experience in providing penetration testing services and assisting clients to achieve and maintain accreditation.