Policy: a principle of behavior, wise conduct, a tool of governance, overall intention and direction as formally expressed by management.
By adding a Content Security Policy (CSP) to a blog, we can specify resources a reader’s browser (Chrome, Firefox, Edge) is allowed to use on a site. We can specify from where a browser can load scripts, styles, images, media, and objects. Specify to where a form can post data. Enable or disable inline scripts and styles; even exactly specify the fingerprint of allowed scripts and styles. Require that each file must have a specified fingerprint to make sure it was not modified.
You may have heard of a recent British Airways hack, or how thousands of UK and Australian governments’ sites were hijacked to mine crypto-currency. Both were compromised via a modified script file. Also a fresh news story about scripts injected into shopping carts. Attacking WordPress sites en masse is nothing new, and in most cases malicious scripts are injected into sites through some weakness, completely out of site owners’ control. Something should be done. Fortunately some smart people figured out how to remedy the situation, at least reduce the risk, so all we have to do is implement few recommendations.
To see how a CSP on a WordPress site looks, check out the source of this site. Right-click anywhere on the page and select “View Page Source” or type Ctrl+U. Take a look at the first <meta> tag, just below the <head>.
What does this do? The policy:
- disables defaults for directives requiring sources (-src),
- specifies two sha256- integrity attributes of inline scripts allowed to run,
- allows loading of scripts from this domain and Cloudflare cdn,
- specifies one sha256- integrity attribute of an allowed inline style,
- allows loading of styles only from this domain,
- allows loading of images only from this domain,
- prevents loading of fonts,
- prevents loading of objects,
- allows forms to post only to this domain,
- requires integrity attributes (sri) to be specified for styles and scripts.
Mozilla has a good reference of policy directives. This is likely to change as new specifications are introduced, but it is a good start. Once the policy is in place it is easy to tinker with.
Continue reading “Add Content Security Policy to WordPress [1/4]”
Scott Helme has a detailed procedure of how to configure Raspberry PI to act as a DNS resolver with DNS-level “content-blocking” for a network. It is a great weekend project, fun and useful. The hardware cost is around 100 CAD on Amazon.
- Content filter on DNS level, including ads and known nasty sites.
- Reduced web traffic. Depends on sites you visit, but 40% is a reasonable expectation.
- Upstream DNS queries are directed over https, so you get some extra privacy.
- Pages load faster, take a look at the example.
- Pi-Hole has a nice admin interface, so you get insight into DNS chatter on the network.
Here are network requests for a home page of a popular news site using default (no filtering) DNS resolver. In total it took 395 requests, 5.3 MB and six minutes to load.
Now if I switch to the DNS resolver on Raspberry PI:
Total of 143 request, 2.7MB to load, and 20.75 seconds. Take a look at all the lines in red with failed status, this is where the domain got blocked by the pi-hole on the Raspberry.
That’s ~ 50% less data and 17 times faster.
Continue reading “Home Network DNS Resolver”
A challenge by Decision Management Community.
A zoo has four monkeys, during the monkey lunchtime each one ate a different fruit in their favourite resting place. Sam, who doesn’t like bananas, likes sitting on the grass. The monkey who sat on the rock ate the apple. The monkey who ate the pear didn’t sit on the tree branch. Anna sat by the stream but she didn’t eat the pear. Harriet didn’t sit on the tree branch. Mike doesn’t like oranges.
- What kind of fruit each monkey ate?
- Where their favourite resting place was?
So, how to solve this in SQL? It is easy to identify domains, predicates and rules; after that it is straightforward. Continue reading “Monkey Business”
This scenario has been designed to engage the entire cyber security incident response (IR) team and evolve the IR plan and capabilities as quickly as possible. It includes technical, managerial, financial, regulatory, legal, and public relation challenges.
Take a look at your current IR plan and see if it stands up to this test. An organisation that does not have a cyber security IR plan, or a program, must act as if it has already been breached. If you do not have an IR plan get one; NIST SP 800-61 r2 is a good start. Continue reading “Cyber Security Incident Scenario”