Regulatory compliance is one of the biggest drivers in cyber security. When fines of up to £20 million are being cited, or the loss of ability to perform core financial business functions is threatened, any business will need to take notice.
The biggest risks for security teams are issues that affect compliance (due to these fines) and customer data (due to reputational damage and costs). This typically means that security flaws that affect customer data, especially personally identifiable information (PII), healthcare data, and financial data, become your biggest risks.
Organisations that have multiple software applications will typically also have many security flaws within those applications. We won’t mention names, but all of us have worked with large companies with thousands of known security issues on their vulnerability management systems and lists.
The challenge, within those many known security issues, or the new issues created with new code changes, is to ensure they don’t come back to bite you in the regulatory compliance. Therefore any security issue that affects PII, or healthcare data, is a much bigger risk than one that would only affect already public data.
Let’s think about it. We find two SQL injections. One that affects an internal software system, with only records of which rooms are going to be cleaned on which day - this isn’t going to be a big risk to the business bottom line. The other SQL injection affects an online system without authentication, with personal and financial data, and suddenly we have another Talk Talk breach on our hands, and the ICO is going to use GDPR to make an example out of us.
When security tools and penetration testing teams are reporting hundreds of issues, many tools, especially top grade commercial ones, can steer you towards how your systems are stacking up against popular regulations.
They can list numbers of issues against regulations like HIPAA, PCI DSS, GDPR, and others, verses the other issues that wouldn’t affect these regulations. This then leads to security and development teams prioritising those issues, over the rest, to be fixed first.
However those regulatory issues can only be true regulatory issues if the software system was holding or processing the regulated data types. Makes sense. It can only be a GDPR issue if PII data was at risk, right?
However you will often find that tools which suggest regulatory compliance issues, have no way for you to inform the tool if this software application being tested will actually hold any sensitive data. If the application doesn’t, and the security tool indicates GDPR, or PCI compliance issues, then that’s a regulatory false positive.
This leads to security issues being prioritised when they shouldn’t be. This then leads to real business risk not being effectively reduced. If you, for example, have 1000 GDPR cited issues to fix, that’s going to suck up your resources while you apply all the fixes to remove that GDPR fine risk. However if 500 of those were GDPR regulatory false positives, then you’ve just wasted 50% of your time and resources - time which was not effectively reducing your risk.
The Uleska Platform allows you to better know which security issues will affect the compliance related data. Uleska uniquely catagorises issues against true PII, financial, and other regulatory compliance using application analysis and configuration, reporting detailed Value-at-risk metrics to allow you to ensure the highest risks are addressed first.
Reduce your risk more efficiently, by managing genuine risk and seeing trends over weeks and months, allowing you to focus on actual issues affecting compliance, not regulatory false positives. Prioritise issues against real risk, not fake risk.