I have written the following article for IBM which was published on IBM's DeveloperWorks
Scan your app to find and fix OWASP Top 10 2013 vulnerabilities (website)
Scan your app to find and fix OWASP Top 10 2013 vulnerabilities (PDF)
Today's modern web applications are more than a match for most desktop PC applications and continue to push boundaries by taking advantage of limitless cloud services. But more powerful web applications means more complicated code, and the more complicated the code, the greater the risk of coding flaws — which can lead to serious security vulnerabilities within the application. Web application vulnerabilities face exploitation by relentless malicious actors, bent on profiteering from data theft, or gaining online notoriety by causing mischief. This article looks at securing web applications by adopting industry best application development practices, such as the OWASP Top 10 and using web application vulnerability scanning tools.
A UK view on Cybersecurity & Information Security, Everything Computer Security from the very basics to the advanced. A blog with a focus on the latest Cyber Security developments & issues in the UK, including Hacking, Privacy (GDPR), Data Breaches, security standards such as NIST, PCI DSS, Cyber Essentials & ISO27001, all will be simply explained.
Sunday, 22 June 2014
Friday, 13 June 2014
Forget Windows XP, Does Unsupported Java pose a Greater Risk to the Enterprise?
Recent research shows 76% of enterprises analysed by Cisco has Java version 6, which Oracle stopped supporting in February 2013, 14 months before the highly publicised end of Windows XP support by Microsoft. Running unsupported Java is arguably a far more risky affair than unsupported Windows XP in the enterprise, and according the Cisco 2014 Annual Security report, the Java problem is going under the security radar.
As most Cyber Security professional will tell you, you should avoid installing Java unless you really have to have it, as the exploitation of Java vulnerabilities is a typical culprit behind web-based desktop compromises. Recent data from Sourcefire shows that Java exploits make up a staggering 91% indicators of compromise.
The Java Applet Risk
Where Java is required for an application, verify if the application is web browser based. If not, disable Java from running within the web browser, preferably by enforcing it using enterprise management tools. This significantly reduces the risk, as it is the potential of users executing untrusted Java applets while visiting dodgy websites online which poses the greatest risk with unsupported Java versions.
Where applications are reliant on old Java versions, it can be just a question of raising the issue with developers and suppliers, and pushing them into making their applications and applets compatible with the latest versions of Java. Sometimes there are cost issues here, as developers tend to charge for software upgrades, however there really shouldn't be any excuse for applications not to be continually supported to be secure of vulnerabilities as part of their life-cycle of use. An application that doesn't work with any of Oracle's supported versions of Java, can be regarded as having its own security vulnerability. Continued patching of systems and applications is a fundamental enterprise security best practice, neglecting patching leaves doors of vulnerabilities open for cyber attackers to exploit.
As most Cyber Security professional will tell you, you should avoid installing Java unless you really have to have it, as the exploitation of Java vulnerabilities is a typical culprit behind web-based desktop compromises. Recent data from Sourcefire shows that Java exploits make up a staggering 91% indicators of compromise.
The Java Applet Risk
The highest area of risk with Java lies with Java applets (applications) which are executed within a web browser. The intent is for Java applets to operate in a safe sandbox within the confines of the web browser, so limiting the applet’s interaction with the operating system. But this intent does not matchup to reality, as hackers are able to write malicious website Java applets which exploit Java vulnerabilities, leading to compromise of the operating system hosting the web browser. Due to the compatible nature of Java, hackers are able to attack most web browsers and most operating systems.
Myth Busting: Java has nothing to do with Javascripts. Disabling Java in your web browser or removing Java from your system, will not break the vast majority of websites online.
Why old versions of Java are still Present in the Enterprise
The reasons why unsupported versions of Java are still present in the enterprise, can be often attributed to internal business applications and custom written Java apps, which simply do not work with the latest versions of Java. In other cases it is a lack of desktop application patch management and desktop application control which is to blame, this is often coupled with low awareness and understanding.
Managing and Mitigating the Enterprise Java Risk
The first course of action is to understand the extent of Java installations within the enterprise, this can be achieved by using application auditing tools to ascertain Java installations, including version numbers and patch level. Next is to review the business reason for each Java installation, ensuring there is a valid reason for its presence, namely to run a specific business application. Sometimes Java is a legacy presence for applications which are no longer used or exist. If there is no reason for Java to be there, remove it and then prevent users from installing it. It is surprising how many users are duped into installing Java on their desktops when visiting websites, when they don’t actually require it.
Myth Busting: Java has nothing to do with Javascripts. Disabling Java in your web browser or removing Java from your system, will not break the vast majority of websites online.
Why old versions of Java are still Present in the Enterprise
The reasons why unsupported versions of Java are still present in the enterprise, can be often attributed to internal business applications and custom written Java apps, which simply do not work with the latest versions of Java. In other cases it is a lack of desktop application patch management and desktop application control which is to blame, this is often coupled with low awareness and understanding.
Managing and Mitigating the Enterprise Java Risk
The first course of action is to understand the extent of Java installations within the enterprise, this can be achieved by using application auditing tools to ascertain Java installations, including version numbers and patch level. Next is to review the business reason for each Java installation, ensuring there is a valid reason for its presence, namely to run a specific business application. Sometimes Java is a legacy presence for applications which are no longer used or exist. If there is no reason for Java to be there, remove it and then prevent users from installing it. It is surprising how many users are duped into installing Java on their desktops when visiting websites, when they don’t actually require it.
Where Java is required for an application, verify if the application is web browser based. If not, disable Java from running within the web browser, preferably by enforcing it using enterprise management tools. This significantly reduces the risk, as it is the potential of users executing untrusted Java applets while visiting dodgy websites online which poses the greatest risk with unsupported Java versions.
Where applications are reliant on old Java versions, it can be just a question of raising the issue with developers and suppliers, and pushing them into making their applications and applets compatible with the latest versions of Java. Sometimes there are cost issues here, as developers tend to charge for software upgrades, however there really shouldn't be any excuse for applications not to be continually supported to be secure of vulnerabilities as part of their life-cycle of use. An application that doesn't work with any of Oracle's supported versions of Java, can be regarded as having its own security vulnerability. Continued patching of systems and applications is a fundamental enterprise security best practice, neglecting patching leaves doors of vulnerabilities open for cyber attackers to exploit.
The post is brought to you by Cisco
Sunday, 8 June 2014
You’re so hacked, you don’t even know it!
The standard information security management doctrine is to
consider the internal IT infrastructure as a secure trusted zone, free from any
malicious third party compromise. But the reality is different, as network
intrusions, malware infections, data thefts and other malicious activities are
not being detected within most UK business networks. According to the Cisco
2014 Annual Security Report, 100% of business networks analyzed by Cisco,
have traffic going to websites that host malware.
Sophisticated and expensive security monitoring may well
be implemented to detect malicious activity, but in my experience, monitoring
and alerting systems are often poorly configured and not correctly base-lined.
This results in the security staff being bombarded with a steady stream of false
positive alerts, which completely hampers their ability to spot actual attacks.
Security monitoring can also lure the business into a false sense of security, take
File Integrity Monitoring (FIM), an excellent tool for detecting malware on IT
systems, that is unless the malware operates in RAM, and uses unmonitored
temporary files, in which case FIM is never going to detected it. Anti-virus
(AV) is a security staple for detecting and preventing malware within nearly
all businesses. But anti-virus protection has become an endless losing game of
cat and mouse, with AV companies analysing over 150,000 pieces of new malware
every day, they are struggling to keep pace. While expert hackers that specifically
target businesses, will take the time to customise and fully test their tools
and malware, to ensure AV and monitoring systems do not detect their malicious activities.
Security Monitoring Alerts - Can't see the wood for the trees
Many of the recent high profile data breaches, have involved
hackers going unnoticed and freely operating inside company networks for months
on end. Networks which were assumed to be secure.
For instance Target’s IT systems were first compromised
by hackers on 12th November 2013. The intruders were able to test their credit
card stealing malware on a selection of Target’s Point-of-Sale (POS) systems
for several days, before deploying their malware onto POS systems within all of
Target’s 1800 stores, just in time for the busy black Friday shopping weekend. Over
the next few weeks the hackers stole 40 million credit card details and 70
million records of customer information, a whole month passed before the breach
was eventually detected. The breach wasn’t spotted by Target either, they were
informed by the US Department of Justice, after several banks had noticed a
massive spike in fraud involving over a million credit cards. All the credit
cards used in these fraudulent transactions had one thing in common; they all had
been used for purchases at Target stores.
The subsequent forensic investigation of Target,
discovered the hacker’s intrusion was detected and logged from the 12th
November onwards, however Target’s staff failed to notice and react to their security
monitoring system’s alerts. This failure in detection and response is exactly
what any hacker stealing information desires. In the case of the Target data
theft, the hackers are racing against a ticking clock to monetize the stolen credit
card data as much as possible, before the banks learn of the compromise. As
soon as the banks establish credit cards have been compromised, they cancel and
re-issue the stolen credit cards, which significantly devalues the credit card
data stolen.
Target’s failure to spot the breach has cost them dear,
if the breach was detected earlier, the amount of data stolen would be far more
limited, meaning fines, which are based on the cost incurred to replace the
stolen cards, would have been much less. But as it stands, Target has already
spent $61 million in dealing with the breach, with another $100 million planned.
This has resulted in Target’s like-for-like fourth quarter profits for 2013, to
be massively down, along with their share-price. When data breaches of this
scale and calamity significantly hit the business bottom line, the buck stops
with those ultimately responsible in the boardroom. Inevitably in Target’s case
heads rolled, not only did this breach cost the CISO his job, but it led to the
CEO being fired as well.
The same story of failing to detect malicious activity rings
true with many of the other recent big data breaches. A massive 145 million eBay
customer account records were stolen by hackers in February 2014, it was almost
3 months before eBay discovered the breach. 158 million records was stolen from
Adobe in September 2013, a whole month had passed before Adobe discovered this huge
data loss, but only after hackers had posted all their stolen data online.
There are many UK businesses right now, regardless of their
size, industry and security posture, have compromised IT systems and data
losses going unnoticed. Right now there are dark websites, forums and chat
rooms where global cyber criminals are trading access to, and use of, UK
business IT systems.
The lesson is to never to assume the internal networks are
secure, in fact the real lesson is to always assume the opposite. Thinking in
this way takes you down the road of a more proactive form of information
security management. For instance adopting more proactive security techniques like
cyber intelligence, by finding out what hackers already know about your organisation,
what they might be planning, and then counteracting, can help nip potential
serious security incidents in the bud.
The cyber threat landscape is growing at an alarming rate,
fuelled by the continued business adoption of mobility and cloud services. These
increasing attack surfaces present the hackers with a new world of opportunities
to steal information for self-profit. Information technological change presents
new challenges for cyber security, a more proactive approach is required to keep
up with the highly agile cyber criminals.
The post is brought to you by Cisco
Tuesday, 3 June 2014
SC Congress: POS Breaches, Target & PCI DSS Compliance
I was privileged to speak at the SC
Congress in London today. I was asked to talk about my views on Point of Sale
(POS) credit card data breaches which had recently occurred stateside, the role
of PCI DSS compliance with such breaches, and whether the UK could expect
similar breaches despite widespread adoption of Chip & Pin (EMV), and what
are the lessons to be learnt.
The following is a summary of what I said.
In the United States there has been a number
of high profile Point of Sale (POS) credit card data breaches, occurring at
around seven shopping chains towards the end of last year. The most provident
of these breaches was at Target, where hackers stole an estimated 40 million
credit card details. The hackers managed
to load credit card data stealing malware onto Target’s POS systems, in each of
Target’s 1800 stores. It is one of the largest and most sophisticated data breaches
the payment card industry has ever seen.
As Target cashiers swiped customer’s credit
cards on a POS, which is essentially a workstation with a magnetic swipe card
reader, the credit card data, which is in clear text on the magnetic stripe on
the back of the card, is loaded into the POS RAM. At this point the malware on
the POS would copy the contents of the RAM, this is known as RAM scrapping. The
malware then moves the credit card data out of the Target network into the hands
of the attackers, who sell them on to card fraudsters at a profit.
But there is much more to this breach than the
POS malware, to better understand this, we need to rollback the timeline of start
the breach process, to see how the attackers got the malware onto the POS
systems in the first place.
It all starts with Fazio Heating &
Cooling LCC, a company providing Heating, Ventilation and Air Condition (HVAC) services
to Target. Target have provided Fazio with remote access into their network, to
allow Fazio to perform ebilling and exchange project management information. It
is understood this network access was a basic remote access system, it is
suggested it could be as simple as an RDP connection, with Fazio remote
accessing into a Target server using a username and password. At some point in 2013, Fazio was subjected to
a cyber attack, its employees were sent phishing emails laced with malware.
This attack resulted in the theft of the Target remote access credentials. It
is likely these remote access credentials were offered for sale online and then
bought by the would-be card hackers, this is my assumption.
In mid November 2013 the attackers supposedly
used the Fazio credentials to access the Target network. It is not clear
whether Target had a flat network or had their payment systems network
segmented from their corporate systems, my assumption would be the payment
environment and store POS systems would have been network segmented, but we
can’t be certain. Either way the attackers managed to gain access to Target’s
payment network and POS systems within all 1800 stores. The attackers likely spent the first few days
customizing and testing their POS malware. The POS malware itself was probably
purchased from a third party, there are suggestions it was a malware kit known
as Black POS, which was written and sold by Russian teenager for couple thousand
dollars.
Once the attackers had finished testing and
had the POS malware successfully performing, they then used Target’s own
systems to deploy the malware onto POS systems within all of Target’s 1800
stores. At this point it is getting on
to late November 2013, the busiest time of year for shopping in the US, think
Black Friday. The POS malware lifted credit card details in the millions over
the next few weeks. Meanwhile it is believed Target’s IT system’s logged and alerted
this network intrusion, but there was no monitoring and reaction to these alerts
by Target staff. Which is very good news for the attackers, as the clock is
ticking for them to monetize credit card data before card issuers and banks
learn of the data theft, which leads to the cancelation of stolen cards and the
enabling of additional anti-fraud monitoring against possible compromised
credit cards, all would significantly devalue the payment card data stolen.
The POS malware deposits the vast amount of
card data onto compromised systems located around world, the hackers collate
the data, and put them up for sale on ‘carding’ forums, chatrooms and websites
in chunks, with individual cards sold for between $18 and $38, after which card
details are used fraudulently.
After a couple of weeks of selling card
data to fraudsters, the likes of Visa, Mastercard and banks spot a spike in
fraud, since over million of the stolen cards are now being used in fraudulent
transactions. They spot a common source with the fraud spike, in that the cards
were all used at Target stores. In mid December
2013, Target are contacted and told their payment systems have been compromised. Target have no choice but to bring in forensic
investigators, together with the involvement of law enforcement and the US
secret service, go onto discover the POS malware, and also uncover that more than
70 million Target customer records (personal information) had also been stolen.
The PCI Compliance Factor
In September 2013, Target completed a
Payment Card Industry Data Security Standard (PCI DSS) assessment by one of the
largest PCI Qualified Security Assessor (QSA) companies. A PCI assessment, even
by a seasoned QSA, is a sampling exercise, it doesn’t prove the entity being
assessed is actually operating in a continued PCI DSS state, 24-7-365. A PCI DSS
assessment boils down to a judgment of compliance, determined by interview
questions, and the QSA reviewing sample from the environment. Nether–the-less
Target tried to sue their QSA company due to the breach, but the lawsuit was
quietly dropped a few weeks later.
It is highly doubtful that Target where
operating in a PCI DSS compliance state at the time of the breach, given;
remote access appeared not to use two factor authentication, there was poor
third party management, poor network segmentation, poor system monitoring and reaction,
etc. all are standout PCI DSS requirements. So you really can’t point the finger
at the PCI DSS, so what of the QSA assessing compliance? All QSAs have a ‘get out of jail free’ zero
responsibility card when comes to PCI DSS assessments, perhaps you could
question how thorough the PCI DSS assessment was, but without reviewing the
actual documentation and Report on Compliance (RoC), there no way we can know.
The breach has really hit Target hard in
terms of costs, the like for like Q4 profits was down significantly, with the
company already shelling out $61million in dealing with the breach, and a
further $100 million allocated for the upgrade of their POS systems to Chip and
Pin. With the breach hurting the profits, it is little surprise to see CEO
shown the door last month.
Could a POS breach happen in the UK?
Yes, and No. Skimming debit/credit card
data from POS system is more difficult in the UK, given most POS systems use a
dedicated separate chip and pin device, which is more often than not, is
PCI-PTS security accredited. However if hackers gain access to the payment
network of a company, then there are a multitude of attack methods that can be
attempted to harvest credit card data on mass, they don’t need to attack the
POS.
PCI DSS isn’t a broken standard, however we
see in the new version, PCI DSS V3.0, released at the start of the year, that
there is already a greater emphasis of third party management and penetration
testing of network segmentation (from Jul 2015), two of the biggest areas of security
weakness with Target.
I also spoke about my views on lack of
plastic security evolution, pretty much as per my blog post – How the PaymentCard Industry could kill PCI DSS
My Closing Remarks
Debit/Credit card data should be regarded
as toxic data by your business. The data
does not belong to the business and it does not belong to your clients. PCI DSS
and the authorities around it, are only concerned with protection of their
payment card data while in your business possession. Worst still, if you drop
the security ball in protecting the payment card data, you pick up the tab in
clearing up the mess. PCI DSS is mostly made up of best practice information
security, but it is highly prescriptive in nature, and so isn’t an easy standard
to fully comply with. PCI DSS compliance can be very costly to continually achieve,
diverting your security budget away from protecting other forms of confidential
data within the business. The best course
of action is to remove and/or reduce all payment card data within the business,
using card scheme accredited payment service providers, can allow you to transfer
risk over to them, while technologies like tokenization and end-to-end
encryption, can help to keep the toxic payment card data and the required PCI DSS
controls which go with it, at a bare minimum.
I was quoted in the media as saying:
“The best approach is to find ways of
outsourcing all payment processes so that no payment card data is held or
processed by the retailer"
"Alternatively, if payment card data cannot
be avoided, ensure that it is encrypted from end to end so that even if systems
are breached, attackers cannot use the data to commit fraud”
Subscribe to:
Posts (Atom)