Thursday 12 September 2013

Cyber Threat Sharing Bill and Cyber Incident Response Scheme – Shouldn’t We Start with System Hardening and FIM?

Background: Defending the Nation’s Critical Infrastructure from Cyber Attacks

In the UK, HM Government’s ‘Cyber Incident Response Scheme’ is closely aligned in intent and purpose to the forthcoming US Cyber Threat Sharing Bill.

The driver for both mandates is that, in order to defend against truly targeted, stealthy cyber attacks (APTs, if you like), there will need to be a much greater level of awareness and collaboration. This becomes a government issue when the nation’s critical infrastructures (defense, air traffic control, health service, power and gas utilities etc.) are concerned. Stuxnet proved that cyber attacks against critical national infrastructure can succeed and there isn’t a government anywhere in the world who doesn’t have concerns that they could be next.

The issues are clear: a breach could happen, despite best efforts to prevent it. But in the event that a security breach is discovered, identifying the nature of the threat and then properly communicating this to others at risk is time-critical. The damage may already be done at one facility but heading it off before it effects other locations becomes the new priority: the impact of the breach can be isolated if swift and effective mitigating actions can be taken at other organizations subject to the same cyber threat.

As it stands, the US appear to be going further, legislating regulation via the Cyberthreat Sharing Bill. The UK Government have created the Cyber Incident Response Scheme but without this being a legislated and regulated requirement it may be suffer from slow adoption. Why wouldn’t the UK do likewise if they are taking national cyber security as seriously?

System Hardening and FIM

Prevention Better Than Cure?

One other observation, based on experience with other ‘top down’ mandated security standards such as PCI DSS, is that there is a temptation for the authorities to prioritize specific security best practices over others. Being able to give a ‘If you only do one thing for security, it’s this…’ message gets things moving in the right direction, however it is can also lead to a false sense of security amongst the community, that the mandated steps have been taken and so the organization is now ‘secure’.

In the case of the UK initiative, the collaboration with CREST is sound in that it provides a degree of ‘quality control’ over the resources recommended for usage. However, the concern is that the emphasis of the CREST scheme may be biased too heavily towards penetration testing. Whilst this is a good, basic security practice, pen testing is either too infrequent, or too automated (and therefore breeds complacency). Better than doing nothing? Absolutely – but the program should not be stopped there.

A truly secure environment is one where all security best practices are understood and embedded within the organization and operated constantly. Likewise, vulnerability monitoring and system integrity should be a non-stop process, not a quarterly or ad hoc pen test. Real-time file integrity monitoring, continuously assessing devices for compliance with a hardened build standard and identifying all system changes is the only way to truly guarantee security.

Wednesday 4 September 2013

PCI DSS Version 3 and File Integrity Monitoring – New Standard, Same Problems

PCI DSS Version 3.0

PCI DSS Version 3 will soon be with us. Such is the anticipation that the PCI Security Standards Council have released a sneak preview ‘Change Highlights’ document.
The updated Data Security Standard highlights include a wagging finger statement which may be aimed at you if you are a Merchant or Acquiring Bank.

“Cardholder data continues to be a target for criminals. Lack of education and awareness around payment security and poor implementation and maintenance of the PCI Standards leads to many of the security breaches happening today”

In other words, a big part of the drive for the new version of the standard is to give it some fresh impetus. Just because the PCI DSS isn’t new, it doesn’t make it any less relevant today.

pci dss v3

But What is the Benefit of the PCI DSS for Us?

To understand just how relevant cardholder data protection is, the hard facts are outlined in the recent Nilson report. Their findings are that global card fraud losses have now exceeded $11Billion. It’s not all bad news if you are a card brand or issuing bank – the losses are made slightly more bearable by the fact that the total of transactions now exceeds $21TRILLION.

http://www.nilsonreport.com/publication_the_current_issue.php?1=1

“Card issuer losses occur mainly at the point of sale from counterfeit cards. Issuers bear the fraud loss if they give merchants authorization to accept the payment. Merchant and acquirer losses occur mainly on card-not-present (CNP) transactions on the Web, at a call center, or through mail order”

This is why the PCI DSS exists and needs to be taken seriously with all requirements fully implemented, and practised daily. Card fraud is a very real problem and as with most crimes, if you think it won’t happen to you, think again. Ignorance, complacency and corner-cutting are still the major contributors to card data theft.

The changes are very much in line with NNT’s methodology of continuous, real-time security validation for all in scope systems – the PCI SSC state that the changes in version 3 of the standard include “Recommendations focus on helping organizations take a proactive approach to protect cardholder data that focuses on security, not compliance, and makes PCI DSS a business-as-usual practice”

So instead of this being a ‘Once a year, get some scans done, patch everything, get a report done from a QSA then relax for another 11 months’ exercise, the PCI SSC are trying to educate and encourage merchants and banks to embed or entrench security best practices within their everyday operations, and be PCI Compliant as a natural consequence of this.

Continuous FIM – The Foundation of PCI Compliance

In fact, taking a continuous FIM approach as the starting point for security and PCI compliance makes much sense. It doesn’t take long to set up, it will only tell you if you need to take action when you need to do so, will help to define a hardened build standard for your systems and will drive you to adopt the necessary discipline for change control, plus it will give you full peace of mind that systems are being actively protected at all times, 100% in line with PCI DSS requirements.