Cookie Settings
Customize Consent Preferences

We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below.

The cookies that are categorized as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... 

Always Active

Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.

No cookies to display.

Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.

No cookies to display.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.

No cookies to display.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

No cookies to display.

Advertisement cookies are used to provide visitors with customized advertisements based on the pages you visited previously and to analyze the effectiveness of the ad campaigns.

No cookies to display.

Other cookies are those that are being identified and have not been classified into any category as yet.

No cookies to display.

eb97afee watering hole

SCADA, Zero-Trust, Content-Security-Policy


A Florida water treatment plant breached. People nearly poisoned. A SCADA device exposed via Windows & Team Viewer. Not where we want to be. How did it happen, how do we prevent systematically? Read On!

Earlier I wrote about the attack on a Florida water treatment plant. A remote site had an old Windows 7 PC with Team Viewer and shared passwords, and, well, the rest wrote itself.

A new blog post out gives some more details about a ‘watering hole’ attack that occurred just in advance. In a nutshell, a (legitimate) related industry site was compromised and served a wee bit of malicious JavaScript. Someone from the target opened a page there.

As we can see in the screen shot, a script is present that probably the original author did not wish. WordPress is particularly hard to secure for Content-Security-Policy, but, a script-src directive in the CSP would have prevented this issue. The browser would have rejected loading the malicious script.

877dc42b water site injected code source dragos
source: dragos

I’ve written a lot about Content-Security-Policy (and some videos!). In particular, I showed how it protected my personal site (well the users of it) from malicious content injected by some malware extension they had installed. Its a great seat belt. Head on over to the Mozilla Observatory and check your site.

Now, let’s assume that either a) we didn’t prevent with Content-Security-Policy, or b) the attacker worked around. What would be our next step (Defense In Depth!). Well, Zero-Trust. If we assume that we can’t fix human behaviour, that people are going to need remote access to things, we may as well make it safe and convenient. A simple single-sign on, Zero-Trust Network Access model, we could have made that SCADA device safely usable remotely, removing the value of the attack.