Mandatory data breach reporting: are your shields up?

As organisations strive to protect their IT infrastructure in a constantly evolving cyber threat landscape, the strategy of application shielding is rapidly gaining popularity around the world.

The approach involves protecting an IT infrastructure from exploits that take advantage of known software vulnerabilities. With a robust shield against attacks in place, organisations can then work to fix applications and further strengthen their defences – what’s more, they can do so as time and budget allows.

Taking this 'shield first, then remediate' approach also helps to ensure organisations will be less likely to suffer data losses or breaches, something that will soon have to be reported under Australia's new mandatory data breach notification legislation.

Yet, despite its significant value to organisations of all sizes, many are still unsure as to how application shielding works; and the key benefits it provides. This is what led Sam Pickles, CTO at RedShield, to put together a whitepaper that debunks ‘six common misconceptions about application shielding’. The key points are summarised below: 

Misconception 1: Fixing code is always more secure

When vulnerabilities are discovered, fixing the application code is often the ideal strategy, however according to RedShield there are a range of factors that can make this challenging.

The priority of the task needs to be recognised at a senior level and appropriate resources allocated to it. Developers may have to be moved from existing projects and focused instead on remediation work. The developers will also need access to the application code itself, which is not always possible, as well as have the necessary skill level to undertake the required changes.

Care also needs to be taken that making changes to one application won't have unintended flow-on implications for other components within the IT infrastructure. These, in turn, could cause outages and disruption to operations.

Most organisations that depend solely on fixing code to mitigate vulnerabilities continuously have a list of open flaws that are not yet fixed. Across the IT industry, the average time between discovering a vulnerability and fixing it is 893 days. This poses an unnecessary risk when application shielding can often mitigate vulnerabilities in just hours.

Misconception 2: Shields can simply be bypassed using special techniques

Application shielding uses a shield library to provide protection against known security threats. It's true that virtually all security controls have flaws discovered in them from time to time, and this is the case with shield libraries.

However discovered bypass techniques have been very rare and are addressed swiftly. Application shielding companies, such as RedShield, regularly offer bug bounties and encourage researchers to submit any weaknesses discovered within shield objects. This allows tools to be constantly strengthened to ensure they provide the most robust protection possible.

Misconception 3: Some vulnerabilities are too complex or unique for shielding

Application shielding is a form of software development and most shielding projects require customisation of an existing shield library or the creation of new objects. Shield objects can be programmed to transform application content, track application and session states, and detect illegal inputs or outputs. They can also flag illegal changes to client side contents, and a huge range of unwanted activity while also performing many other functional tasks.

While there are certainly some vulnerabilities that cannot yet be fully mitigated by application shielding, vendors are constantly working to find solutions and close the gaps.

Misconception 4: Shield layers could introduce new vulnerabilities

While it is true that any security layer could have unknown vulnerabilities, this also applies to any system components which include operating systems, databases and web app containers. The risk of leaving known, discoverable, exploitable vulnerabilities open is far worse and, in the imperfect world of IT security and risk management, it is best to choose the shortest path to the lowest measurable risk.

Misconception 5: Relying on shielding makes developers less motivated to improve security

The development of secure systems requires several key supporting factors. These include the size and seniority of the developer team together with its ability to deliver secure code. Other factors include having the time and tools available to find and fix vulnerabilities as they are discovered and whether security has been made a priority within an organisation's overall goals.

Taking a shielding strategy doesn’t have a negative impact on these factors. While it is a strategy to reduce overall risk, it should not cause standards to drop elsewhere.

Misconception 6: New vulnerabilities found in shielded apps means it has failed

This is not the case. Effective shielding depends on vulnerability intelligence and an ongoing partnership between the shield engineering team and penetration testers. Both testers and application teams must announce when new vulnerabilities are discovered and authorise changes to the policy as required. This can usually be done quickly which is one of the advantages of shielding over fixing code.

Some vulnerabilities are automatically detected by vulnerability scanning, however RedShield recommends working with a professional penetration tester for more advanced testing as this will lead to the best possible shield policy.

The security threats facing organisations are ever-evolving. This is why adopting a web-application shielding strategy can deliver clear security benefits to an organisation. Rather than remaining exposed until known software vulnerabilities are fixed, protection can be quickly put in place, thus giving security and development teams the time they need to remediate. Effective protection can be in place within hours, rather than days, weeks or even months.

Globally, application shielding is fast being recognised as a key part of a business’ security fabric and, with mandatory data breach reporting set to come into play, it’s time Australian organisations took a closer look at the benefits it provides.