Security & Compliance – An Overview
There’s a systemic issue within the cybersecurity industry regarding compliance. While not universal, there is an incredibly pervasive attitude towards compliance. It’s all too often seen as an exercise in exploring the borders of minimum effective dosage, that is to say, how can we ‘check the compliance box’ in the most expedient, low-cost way, rather than in the manner most productive to effect improvements in overall security.
Looking locally, institutions like the Australian Signals Directorate are providing resources to bolster functional frameworks to help enhance the collective cybersecurity posture within Australia, extending to both the private and public sectors. The Information Security Manual (ISM), while not compliance focused by design (more a risk-guidance framework) there are certainly compliance implications we should examine in this and similar contemporary attempts to codify an approach to security.
In this article, we wish to understand how compliance can be used not just as a yard-stick for minimum acceptable levels of security, but as a basis for security excellence – an opportunity to periodically examine areas of security under a microscope and contemplate practical measures to raise the overall security stance individually, and hence en masse.
The Importance of Data Security
The most vital asset to most organisations is trust. Without it, government, health, and financial institutions as prime examples, suffer tremendously. In the digital era, this is most typically associated with Personally Identifiable Information (PII), and will be the primary example we use throughout this article.
Performing annual and regular penetration tests is now mandated by many industry and government bodies, most notably, the financial and healthcare industries. Failure to secure your client data, could result in being penalised by the Office of the Australian Information Commissioner (OAIC). This penalty is the result of the enforcement of the Notifiable Data Breach legislation that came into effect on February 22nd 2018. As this is mandatory legislation, this means that companies need to continuously audit, monitor, and detect any potential for data exfiltration. This will help ensure the security posture across all sectors is heightened and remains front of mind – the optimal outcome for compliance measures. This benefits users in terms of improved security, and as an ancillary benefit, such measures minimise the potential for brand damage that is caused when any compromise does go public.
So we are now seeing the requirement for security teams to continually update their internal policies to ensure alignment with governance of data security is controlled in line with legislation. Everything is linked. Because of this, it means that any internal deployment to prevent attacks from happening and maintaining the posture of the company's security needs to be understood in its entirety.
Practical Compliance
As a background, ‘compliance’ in the context we wish to examine, refers to legal or regulatory statutes against which a target organisation is measured. There are compliance standards common within security, like PCI-DSS, ISO-27001, HIPAA, HITRUST, and countless others, and they must, if applicable to your organisation, be met. Historically, as cybersecurity has really only been coming into a mature state over the past decade in particular, there has been a pronounced lag in terms of the validity to most compliance measures. The issues stems from most governing bodies having to write standards that cover myriad of organisations inside a myriad of industries. This lack of specificity directly translates to many measures being irrelevant and merely roadblock to productivity. This has given rise to this tick-in-the-box approach we’ve already alluded to, so organisation are compliant, even in the absence of any real desire of need to be as such.
As we’ve seen an increasing focus on security, so too has there been a concurrent rise in the complexity and vehemence of adherence to industry standards. Moreover, as we’ve seen recently, the expectations by both legislative and user-led entities have increased in terms of their expectations to privacy and transparent data controls relating to PII. Rest assured, this will lead directly to more stringent and regular auditing against compliance measures like the General Data Protection Regulation (GDPR) in the EU, and The Privacy Act in Australia.
Compliance is one of the most significant aspects an organisation needs to address as any failings can have enormous implications. Not only do government mandated regulations and industry standards’ bodies typically demand compliance in order for organisations to meet or retain certification, but commercially, client organisations may insist on verifiable compliance in order to conduct business. This has unfortunately led to a Pass/Fail approach to many areas within security as excellence has become victim to expediency. To this, penetration tests are often fallaciously seen as tick-in-the-box exercises to meet expectations. However, when conducted expertly, penetration tests provide opportunity to improve security posture.
Identify Gaps Within an Organisation
Much the same way as it’s advisable to submerge a tyre to find a leak rather than to examine each square centimetre of the whole tyre to ensure its integrity, an astute method to understand where your vulnerabilities are is to perform a thorough penetration test to find analogous leaks.
For clarity, this does not mean a mere Vulnerability Assessment (VA) using Nmap or Nessus or their like. These types of tools are just performing automated scans to find ‘low hanging fruit’ vulnerabilities, and are typically not enough to find the true scope of vulnerabilities that exist within your organisation. While useful in that they offer a level of automation to cover the breadth of potential vectors an organisation may have, it requires a human agent to truly explore the potential for compromise. Complications arise, however, as a VA may be sufficient to achieve compliance in some use cases for some standards. Hell, until relatively recently (3.0), VA’s were sufficient for PCI-DSS! So the problem is, despite meeting compliance, this often doesn’t unearth these true, deeper security issues – there’s potentially a chasm between best practice and mere compliance.
A Risk Management Approach
All companies want to reduce unnecessary risk. By performing regular penetration tests, risks will be identified within the organisation sooner. Regular risk management meetings with system owners helps evaluate and prioritise those risks accordingly, contextually, across security. By performing penetration tests, the result will be business units that are outside of security can be made aware of potential vulnerabilities within their unit. Security Risk Managers can then communicate such security challenges in a lexicon that will resonate with those specific teams to help them understand their risk profile, mitigate those risks, and help them better understand the risks that they are choosing to accept or deem not acceptable. Moreover, internal functions are not sufficient in satisfying requirements of partners wishing to connect, and therefore an external audit is typically mandated.
Conversely, accurately outlining all of the vulnerabilities in a pentest report, with, of course, the correct terminology, is critical for technology teams. However, when taking that report and communicating with a different audience, the language needs to change so teams understand what they need to do to remediate those risks. The fundamental element to approaching security-risk awareness successfully is then, to ensure the language with which it’s communicated has eliminated technical jargonism. This keeps topics relevant and thus prevents dilution where meaning gets lost in translation. This will result in a unified approach of a security team working alongside a business unit to ensure the best security posture for the company. The best way to distil this down for most business units is with a standard Risk Matrix, bullet pointing the critical issues and steps towards remediation in a supplemental document supplied by internal tech teams.
Avoid Conflicts of Interest
If an entity that implemented a technical solution (be they internal staff or external service providers) is called upon to audit that very solution, the findings are very likely going to be overwhelmingly positive. As there are few mandates within compliance requirements calling for an independent external audit function, a company could meet compliance standards by using internal testing, or more likely, the same external service providers that were responsible for the body of work being evaluated. Further, even when an independent external firm conducts a penetration test, it would not make sense from an audit point of view for that same firm to also be involved in the deployment of e.g. security infrastructure, or policy framework. This would create a conflict of interest analogous of school children marking their own homework and getting 100%.
There are also a (relatively) new standards and certifications being imposed on the security industry, claiming to raise the bar in terms of technical expertise required to perform penetration tests. The reality is, however, that certain organisations that are normalising this requirement are governed (at least in part) by senior members of the certifying body – a textbook Conflict of Interest.
Core Sentinel’s response is to recommend the use of different, thoroughly independent firms every time you have to perform any security auditing function, including penetration tests. This not only avoids such conflicts, but also facilitates a different approach and therefore potential identification of otherwise overlooked security issues. In terms of due diligence in finding appropriate firms to conduct pentests, Core Sentinel recommend looking for qualifications such as; OSCP (Offensive Security Certified Professional), OSCE (Offensive Security Certified Expert), and CISA (Certified Information Systems Auditor). These require demonstrative technical knowledge and ability, as well as demonstrable communicative skills to generate the types of reports you need, containing actionable intelligence in order to reduce risk and demonstrate an acceptable level of security to third parties.
Optimum App Security by Following OWASP Guidelines
OWASP (Open Web Application Security Project) Top 10 is a regularly updated report outlining security concerns for web application security and focusing on the 10 most critical risks. Companies performing web application penetration tests look to OWASP to assist in identification and classification of those risks, and use it as a guideline when performing testing. Although somewhat vague by necessity, the OWASP Top 10 is still the gold standard for approaching web app security.
You can read the full report here
Summary
Compliance does not (always) equate to best practice – especially for security. Though the terms are often used interchangeably, there are fundamental and important differences with implications well beyond the purely technical realms.
In terms of security compliance, when undertaking any measures, implementing controls that go beyond the minimum will not only make you more secure int terms of cybersecurity now, but also set-up an environment that fosters and values the pivotal importance of true security over lip-service. Instead of playing catch-up, you’ll be focused on setting the standard, and a reputation for security excellence will be appreciated internally, by clients, and your end-users.
If you'd like to understand more about how Core Sentinel can help you best address the gap between "compliant" and "secure" please get in contact.
We will be exploring a case study of a 'Conflict of Interest' in depth in our next article.
Other Articles You Might Like:
Healthcare Cybersecurity: An industry in the Cross Hairs
Penetration Testing for GDPR Compliance
Black Box vs. White Box Testing: Key Differences Every Organisation Should Know